互联网|.Net 微服务实战之技术架构分层篇( 二 )
战略设计
主要从业务视角出发 ， 建立业务领域模型 ， 划分领域边界 ， 建立通用语言的界限上下文 ， 界限上下文可以作为微服务设计的参考边界 。
战术设计 主要从技术视角出发 ， 侧重于领域模型的技术实现 ， 完成软件开发和落地 ， 例如我们常讨论的聚合根、实体、值对象、领域服务等代码逻辑的设计与实现 。
从以上两点的描述可以看出 ， 战略设计从业务视角出发 ， 而架构服务于业务 ， 两者都需要从业务出发 ， DDD战略设计与微服务都有同样的设计思想：分而治之、化繁为简 ， 那么战略设计的思想完全可以作为微服务架构设计的指导思想 ， 此时此刻此场景不谋而合 。
分层架构 也可以叫N层架构（N>=2） ， 其实本质在于划分职责、隔离关注点 ， 保证各层之间的差异足够清晰 ， 边界足够明显 ， 其特点自顶向下依赖 ， 逐层传递 。
本文插图
纵向拆分 首先我按照分层架构的思想以纵向维度拆分 ， 主要共分5层 ， UI层、聚合API服务层、基础业务API服务层、基础设施层、数据库层 。
调用链路自顶往下 ， 用户-->UI-->API网关-->聚合API服务-->Consul+Consul Template+Nginx-->业务API服务-->数据库
UI层
依赖于聚合API服务层 ， 操作与接口11对应 ， 主要负责可见即可得的工作：数据展示、交互动画等 。
入站API网关 主要负责聚合API服务层内外网隔离、入站规则控制 ， 防止外部大流量冲垮内部服务 。
聚合API服务层 被UI层依赖 ， 依赖于基础业务API服务层 ， 主要负责基础业务API服务层的接口的逻辑组合 ， 不直连数据库 ， 可通过API网关暴露给UI层调用 。
注册服务中心 记录基础业务API服务层的服务IP列表 ， 内网使用 ， 衔接聚合API服务层与基础业务API服务层 。
基础业务API服务层 被聚合API服务层依赖 ， 依赖于数据库层 ， 可做具体的数据库读写处理 ， 内网使用 ， 同层服务之间不互相依赖引用 。
数据库层 包括非关系型数据库与关系型数据库 。
基础设施服务层 可被所有层都依赖 ， 如果被UI层依赖则通过API网关暴露 ， 如果被内网服务依赖则通过注册发现 ， 可直连数据库 。
出站API网关 主要负责基础设施服务层内外网隔离 ， 转发第三方开放API请求 ， 出站规则控制 ， 防止被无法把控的第三方服务而拖垮内部服务 。
横向拆分 接下来 ， 我们可以通过DDD划分领域的方式进行服务的横向维度的拆分 。 举个例子：
我们平台拥有三种不同业务领域的系统：客户中心、企业管理系统、内部管理系统 。
那么 ， 聚合API服务层则拥有客户系统API服务、企业管理系统API服务 ， 内部管理系统API服务 。
客户中心的拥有客户信息管理、支付、订单管理等业务模块 。
企业管理系统拥有订单管理、权限管理、支付、仓储等业务模块 。
内部管理系统拥有权限管理、报表、账户管理等业务模块 。
所有系统涉及到自定义订单号、消息推送等业务 。
从以上得知 ， 核心域包括仓储、订单业务、客户信息 。 通用域包括权限管理、账户认证、支付模块、消息推送等 。 支撑域包括自定义订单号 。
因此基础业务API层可以划分：仓储API服务、订单API服务、客户API服务、权限API服务、认证API服务 ， 支付API服务 。
基础设施API层可以划分：ID发号API服务 ， 消息推送API服务 。
如果随着业务继续扩大 ， 团队人数增多 ， 则可以更加的细分 ， 例如仓储拆分成快运、集运等 。 支付拆分成微信支付、支付宝等 。
项目示例 上一篇《.Net微服务实战之技术选型篇》我整理了我们公司使用的框架开源到了github ， 这次我拿了部分业务项目作为示例并上传了 。
推荐阅读
- 互联网|上线半年收获6700万用户，这款聚焦下沉用户的陌生人社交APP是怎么做到的？
- 互联网|5G商用一周年，华为云向互联网企业大抛绣球
- 互联网|中台产品经理实战(14)：中台与SaaS、微服务关系
- 互联网|行业观察 | 你所不知道的5G消息
- 互联网|多名知名人物推特被黑，拜登奥巴马都“中招”，比尔盖茨也在其内
- 互联网|发放高利贷，还要窃取用户信息？这些金融APP在秀“道德底线”
- 互联网|东莞先知：数字智能，先觉“先知”
- 云计算|从互联网到AI崛起，上海能弯道超车吗？
- 行业互联网,5G|江苏有线顺利完成园区5G信号开通测试
- 行业互联网,AI人工智能|城市教育大脑以“ AI+ 大数据”为核心 , 引领教育变革