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的业务模块