.Net微服务实战之技术架构分层篇 (2)

  从以上两点的描述可以看出,战略设计从业务视角出发,而架构服务于业务,两者都需要从业务出发,DDD战略设计微服务都有同样的设计思想:分而治之、化繁为简,那么战略设计的思想完全可以作为微服务架构设计的指导思想,此时此刻此场景不谋而合。

分层架构

  也可以叫N层架构(N>=2),其实本质在于划分职责、隔离关注点,保证各层之间的差异足够清晰,边界足够明显,其特点自顶向下依赖,逐层传递。

.Net微服务实战之技术架构分层篇

纵向拆分

  首先我按照分层架构的思想以纵向维度拆分,主要共分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,这次我拿了部分业务项目作为示例并上传了。

  https://github.com/SkyChenSky/Sikiro 

  首先想说明几点:

  1.这个不是标准,只是针对我们公司情况取舍后的结果,每个公司的业务有复杂有简单大家视情况完善自己的项目。

  2.为了保护公司原有的业务隐私,我做了部分逻辑的删除,所以大家如果看到不完整的逻辑是正常现象。

  3.希望大家把思维放高,不要死抠细节,求同存异。

  4.代码在原有的基础上修改了名称和引用路径会有变化,如果有问题随时在评论和github反馈给我。

.Net微服务实战之技术架构分层篇

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/wpgdwy.html