0 背景

什么是复杂业务

这几年一直在喊互联网+ ,其实就是互联网与已有行业(传统行业)结合,提升行业效率。相比于流量分发时代的大流量,互联网+时代面对的是传统行业的复杂逻辑,并且能够以高效率支持业务发展。

为什么要做这个原则

现在手上的业务面临以下问题:

  • 团队成员工作经验普遍较少,基本工作经验都在3年以下
    • 技术水平不高,在实际做研发时,难以从架构层面思考问题,能做倒支持好每个需求已经是超过预期
  • 系统可扩展性强
    • 现在业务还处于初级发展期,正要进入大规模扩展阶段,会面临爆发式增长需求,因此需要在架构上支持这种扩展性
    • 可扩展性不仅体现在系统上,更重要是团队、业务上
  • 团队调整
    • 业务的发展必定会导致技术团队的不断调整,出现较多的业务系统交接

1、水平分层原则

基本原则:

  • 上层服务依赖下层服务,下层服务不会依赖上层
  • 同一层次的服务可以相互调用,但绝对避免一个调用链路上服务环形依赖
  • 领域服务层才会依赖DB(mysql、redis、tair等存储),其他层次的服务不与存储打交道
    • 如果流程服务需要依赖DB,特殊需求特殊分析
  • 领域服务内部会有更为细分的层次
  • 业务演化同时,服务也在演化,演化方向是功能逐步下沉
  • 服务层次由上到下,领域服务数量逐渐减少。服务变动频率由上到下逐渐变小。
    • 上层所解决的领域更精确,支持业务场景会更灵活多变。

1.1 网关层

网关层不涉及到业务逻辑,实现了API Gateway的功能。公司技术服务层以及在开发API Gateway,因此我们采用这种方案

1.1.1 Web API
业务范围
  • 提供多端API(微信、app、pc等)
  • 多数据格式支持(mapi byte,json等,需要根据实际情况分步骤实现)
  • 数据校验(代码配置化)
  • 权限校验(代码配置化,或全局)
  • 无业务逻辑
说明
  • web api不再区分应用端(PC、app、微信等),而是面向前端提供api,前端可以使用这些api应用在各个端不受限制
1.1.2 交互逻辑服务
业务范围
  • 业务逻辑组装层
    • API Gateway中的服务编排(A->B->C)和格式转换(DTO转换为更适应web api的数据结构)
  • 取代之前web中的biz层
说明
  • 为什么要多出这一层服务?
    • 取代之前web中biz层服务,面向特定web api的服务
    • 将web中的逻辑全部下沉,web内没有任何逻辑,只有简单的校验和数据格式转换
    • 使用服务方式,在业务发展期调整更为灵活
    • 负责人的调整,负责团队调整等

1.2 流程层

承上启下的作用

1.2.1 聚合服务(aggregate service)

业务范围:
  • 数据和逻辑聚合服务,完成多领域服务数据具备共性的聚合及逻辑控制
  • 聚合服务会跨越多个领域模型
    • 比如会员信息,将会包含会员基础信息、会员卡信息、消费信息等
说明:
  • 聚合服务与交互服务的区别
    • 聚合服务是多个领域数据和逻辑聚合,而交互逻辑服务是服务编排及格式转换,里面会有简单的逻辑处理(判空、调用方式变化等)
    • 交互逻辑服务更面向web api,与web api绑定较为紧密
    • 聚合服务有完整的业务领域,不面向web api,可以提供多个web api使用
1.2.2 流程控制服务(controll service)
业务范围
  • 主要用于控制流程性较强的业务逻辑,保证数据一致性,流程规则的统一
说明
  • 聚合服务与流程控制服务的区别
    • 聚合服务是多种数据逻辑的聚合
    • 流程控制服务是控制业务流程,是流程的编排,会根据不同流程意义不同而作出不同的转换,具有完整的业务领域
    • 例如预订中的预订流程服务,退款流程服务等
    • 两者面向业务问题不同
  • 流程控制与交互逻辑服务
    • 流程控制有完整的业务领域
    • 交互逻辑服务面向web api

1.3 领域层

  • 原则上只有领域服务才会与DB打交道
  • 领域层内均为领域服务
    • 部分业务领域在开始阶段会base在特定的业务领域,比如会员档案 可能在不同的垂直行业下会有不同的业务形态,但这种都是领域服务,只是在名称上会有所不同
    • 领域服务在设计过程中均为面向全部垂直业务
  • 领域服务是一个完整的业务
    • 如会员领域、会员卡领域、商品项目领域等
  • 领域服务内部会有一定的层次划分,各领域之间会有相互依赖
  • 领域服务之间不共享数据表

领域层与流程层的区别

  • 领域层偏向基础业务领域
  • 流程层是多个业务领域按照一定规则组合
    • 流程层在一定情况下可以独立成为业务领域服务
1.3.1 业务领域服务
业务范围
  • 完整业务领域
1.3.2 数据领域服务
业务范围
  • 不依赖其他业务领域服务,提供本领域内的数据读写服务
说明
  • 数据领域服务在业务发展过程中不做强调,如果很多业务依赖,可以单独拆分出来

2、垂直划分原则

面向领域的服务拆分。

面向领域现在几乎成了微服务垂直划分的标准,领域划分是一个宏大的话题,详细可以参见领域驱动设计 ,以后也会有文章专门再来讨论。

3、部署原则

通过水平+垂直划分,能够确定服务的边界大小,基本呈现以下形态:

服务部署原则:

  • 服务独立应用部署
    • 特殊情况下可以2个业务领域集中在一个应用部署,但需要按照jar包方式隔离,便于之后拆分服务。【不建议这种方式】
    • 之所以可以采用服务独立应用部署是因为公司已经使用HULK(公司基于Kubernetes 开发的容器管理平台),能够实现应用服务编排,提升物理机的利用率。
  • DB最粗粒度按照Team独立,需要时按照业务领域独立
    • 推荐使用大业务领域来划分DB,比如营销领域(营销配置,营销执行等)、供应链领域(商品/项目等)
    • 实际执行时参考迁表成本