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