首页 > 代码库 > Web服务端开发需要考虑的问题(续)

Web服务端开发需要考虑的问题(续)

方案汇总
API设计
应用架构
代码库管理
工具链
工作计划
目标
预期
关键过程
service-driver接口定义及实现
web样例

方案汇总

API设计

基于https。
只提供纯数据。
基于一开始提出的restful方案外,提出了读写分离方案如下。

  • 相比restful,url可以表示动作,如下的url是允许的。
    /accounts/1/update

  • http GET表示读操作,POST表示写操作

  • 响应状态与restful方案相同
应用架构

技术分享

  • API网关
    一旦API规模扩大,再加上微服务的使用,路由分发、管理、监控马上就会变得繁琐、复杂,需要有相应工具来解决这个问题,参考工具orange。
    在前期API规模还小的时候,可以直接使用nginx管理。

  • 微服务
    微服务解决快速小规模迭代、水平扩展方面的问题。
    诸如“服务间相互调用”,属于系统架构方面的问题,是SOA的目标,此“服务”并不等同于微服务的“服务”。

  • 工程模块划分

    1. framework。基础框架、工具库,业务无关,基于spring boot。(包含全部service接口定义,及部分默认驱动实现)
    2. service-driver(s)。基础service驱动。(例如cache的redis驱动、filesystem的mongodb驱动等)
    3. common-biz。通用业务逻辑。
    4. common-web。web相关的通用业务逻辑。
    5. module(s)。具体业务模块,web类型的模块基于spring webmvc。
  • 业务模块内层次划分,以web模块为例

    • request interceptor(filter)
    • controller(action)
    • view resolver
    • model
    • biz。跨controller、model的业务逻辑。
    • actuator。内部管理和监控接口。
代码库管理
  • 工程划分

    • 框架库
      包含的模块有:framework、service-driver、common-biz、common-web、web样例
    • 业务库
      自身模块划分如前文。同时依赖框架库输出的framework、service-driver、common-biz模块。
  • 业务库分支方案

    约定current的意思是当前最大版本号

    • 常设分支包括多个线上分支,master、dev分支。
    • 线上分支均为版本分支,如v1、v2。
    • 版本分支的生成。

      • v(current) <= master < v(current + 1)
      • 当api有不兼容改变时,在master的head上新建v(current + 1)分支,然后current += 1。
    • 以v1分支为例,当current>1且需要在v1分支上新增commit时,在v1的head上新建v1-release分支,开发过程中产生的commit提交到v1-release,测试通过后合并到v1,上线后删除v1-release。

    • 线上分支不会合并,当某个commit涉及多个线上分支时,使用cherry-pick的方式同步到多个分支。
    • 版本分支自身会分出子服务分支以适应微服务部署,如v1可以分出v1-account、v1-order等。
      子服务分支的新增commit用独立的release分支完成。
  • 代码复用

    • 有私有maven仓库,按通常的依赖管理复用
    • 无私有maven仓库,业务工程库使用git subtree引入框架工程库
工具链

只提供基于默认工具的工程指导,使用其他工具的成员,如eclipse,需要有能力自行解决工具问题。

  • idea
  • gradle
    -sourcetree

工作计划

需要完成框架库、搭建业务库。

目标

项目可满足基本的业务需求,并可投入实际使用。
完成框架库、搭建业务库。

预期

  • 所有应带默认实现的service-driver已完成local类型的实现。
  • web样例中演示带默认实现的service的使用,关系数据库工具的使用。

关键过程

service-driver接口定义及实现

自上而下优先级由高到低,自左至右优先级不分先后。
低优先级的service可能会依赖高优先级service。
default标签表示framework模块会有默认实现,不需要driver(s)模块。
大部分driver都需要考虑local、global两种类型的实现。
不好抽象出接口或者工作量大且已有成熟第三方定义及实现的service,例如关系数据库工具、httpclient工具等,不在framework中定义,直接在业务模块中引用,避免抽象得不好的service出现在上游以至于污染下游模块。

  1. filesystem default
  2. session default、log default
  3. auth default
  4. cache default
  5. queue
  6. event
  7. mail
  8. sms
web样例

基于web的业务模块

Web服务端开发需要考虑的问题(续)