本文正在参与「金石计划」
作者：京东物流 赵勇萍
一. 前语
现在关于一个后端开发工程师来说，微服务，DDD都是挂在嘴边的东西，感觉咱们接触到多，也了解的多。但笔者个人的感受是，对微服务架构的了解就像我小时分读三国，在不同年龄读的时分感触都不相同。微服务关于开发人员来说亦是如此，一千个人有一千种解读，而随着每个人自己的事务经历和架构才能的提升，每个人看到的风景也会不相同的。今天笔者想结合一下自己的事务实践，分享一下自己根据微服务架构实践后的心路历程。
二. 首要，咱们需求考虑一下： 什么是微服务架构？
在笔者看来，微服务架构并没有一个精确的定义，但他会有许多特征，经过描述他的特征用来把控它是什么。
a. 白马是马。
这是一个哲学出题，标明单个和一般的关系。我以为，任何的技能和架构都不是凭空呈现的，必定是发展而来，而微服务架构的前身便是SOA，面向服务的编程。SOA是一种架构规划形式，也是一种思维。所以微服务理应继承了SOA的这种架构思维，所以我以为微服务便是那个白马，他将一个杂乱体系，以事务的视角，分成独立的模块，每个模块都有供给服务的才能，根据这些才能，去构建一个杂乱的体系架构，在此根底上，再演化出去中心化，和分布式思维。
b. 服务办理
以上说的是思维层级，在战术层级，微服务架构的中心诉求和才能是服务办理，包含服务寻址，流量办理，可观测性等。
c. 十二要素
Heroku创始人Adam Wiggins 提出的微服务十二要素，下面，我贴出我对微服务十二要素的解读：
这十二要素能够说是微服务架构的方法论，有了思维，方法论和战术维度，我觉得就能够完整的描绘出一个微服务架构的全景图。然后，我将我了解的微服务架构总结成一句话：
微服务架构是 ： 一种去中心化的分布式服务架构，架构拥有服务寻址，故障容错，流量调度，操控拜访和可观测性的服务办理才能，从而完成服务的阻隔性，可移植性，可扩展性，稳定性。
三. 其次，咱们的问题焦点：微服务架构的难点是什么？
笔者以为，微服务的两个中心点正事他的难点：
榜首个难点， 微服务的服务办理和流量办理。
关于这个难点，现阶段已经有了很好的处理，由于服务办理和流量办理是去事务场景化的，所以有许多前人经过他们的努力，以及奉献的开源结构，让咱们能够直接能够拿来落地的，并且能够做到很好的兼容。下图是一个比较规范的微服务办理架构图：
第二个难点， 微服务拆分的架构思维.
怎么根据DDD方法论落地服务的分化。该处规划许多中心才能，包含子域划分，限界上下文定义，实体，聚合根的笼统，根据范畴事情的事情驱动规划，除此之外，还有工厂形式，策略等等规划形式的应用。
这第二个难点是很难做到直接的搬迁，由于咱们面对的事务场景千差万别，前人的经历只能总结成思维来辅导咱们，但具体的落地就会检测每个架构师自己的过往经历和了解。 就像一为画家，对与同一片风景的了解不同，画出的画面也是不同的，所以，就会呈现有的人是梵高，有的人是毕加索。而关于笔者现阶段来说，或许只是一个刚入门的素描者，不过我愿意在此抛砖引玉，介绍一下我采灵通项目关于微服务落地的经历，供咱们做一个简略参阅。
四. 最后，来点干货： 采灵通体系–微服务架构落地实践
笔者负责的采灵通事务是一个相对杂乱的体系，带领了20人的开发团队总共历时5个月，完成从0到1的规划，开发和上线。该体系根本涵盖了一个ToB全供应链数字化相关的全场景事务。笔者将经过 事务场景分析， 技能架构解析，和服务落地几个方面对该体系的落地实践进行解读。
1. 事务场景解析
了解DDD的条件是先要了解事务场景，笔者的事务场景是采灵通SAAS体系，在此简略做一个事务介绍：
采灵通是一个规范的供给B商城触达的，同时处理企业数字化收购供应链的SAAS渠道，中心才能包含多供货商协同，订单办理，产品办理，客户办理，及B商城的搭建和办理，具体如下图所示：
2. 技能架构解析
根据以上事务场景，咱们构建出咱们的技能架构计划，如下图所示：
在技能架构上，整体分为四层，自上而下为： 事务前端层， 网关层， 事务服务层，技能底座层。
-
事务前端层：前端根于事务场景，有多个触达端，最主要的端有供货商办理端，同伴办理端，PC商城端，H5商城端， 页面装饰体系。前端封装有一致的组件库，保证了整个体系的前端交互风格一致性。
-
网关层：进口网关为nginx反向署理，主要功能是对不同域名的SSL解析和路径映射，部分前端静态资源的直接映射。进口网关下为事务网关，包含COP网关和通用事务域网关。
通用事务域网关：主要功能是将前端有状况的HTTP请求（header:jwt信息加密和域名信息过滤），进行鉴权，过滤，路由。同时解析为明文上下文Map,存于header中，可供事务层服务使用。其中针对不同域名的路由信息是采用了nacos的配置中心进行一致办理，并下发至gateway，完成一个动态的域名路由办理。
COP网关：负责体系对外开放渠道的API接口鉴权和路由署理。
- 事务服务层。
该层又有细分，分为COP服务，事务渠道服务，数据渠道服务。
a. COP：主要是封装对外开发接口一致认证服。经过COP，SAAS体系能够完成对下流来说，对接第三方供应链的接口渠道；对上游来说，对接同伴的客户ERP体系，政采渠道，OMS体系等。
b. 事务渠道：分为中心的范畴服务层和聚合/适配器服务层。
范畴服务层是根据DDD范畴驱动规划思维，对现有事务进行笼统，依照不同的子域划分不同的服务，每个范畴服务内都有针对该子域的聚合根的笼统封装。而聚合服务是针对不同的事务场景，对范畴服务调用进行一层聚合，使其能够更好的为前端供给接口服务。
应用聚合层主要是针对事务场景进行封装和聚合。
适配器层是针对不具有范畴概念的但又有必定意义的服务封装，比方根据CQRS的规划理念下的查询服务；其次是一些后台异步任务服务，如数据导入导出，数据同步等等。
以上这几层能够看成是对六边形架构的一个很好的分化和落地。
c. 数据渠道层：针对SAAS体系的产生中心数据，例如订单，产品，根据CQRS理念，将数据进行整合和同步，完成多场景下单数据杂乱查询和BI数据分析。
4. 技能底座层
该层细分的话，能够分为TPAAS服务和BPAAS服务两部分。
TPAAS： 包含k8s,容器化编排， Istio流量办理 ,日志收集和检查，链路追寻监控，中间件（数据存储，MQ），CI/CD等
BPAAS：包含一些根底jar包，如低代码结构，安全组件。还有一些根底服务，工作流服务，任务调度服务，分布式ID生成器服务等。
3. 终究服务落地
采灵通体系总计服务65个，依照服务分类分层的概念，结合DDD的六边形架构思维，能够分为：
前端服务，BFF服务，组合服务，适配器服务，范畴服务，根底服务，网关服务。
其中这些服务有一些规划规约：
1. 范畴服务不行依靠组合/聚合服务、适配器服务和BFF服务。
2. 组合/聚合服务和适配器服务不行依靠BFF服务
3. 范畴服务进行天然分库处理。
五. 总结
笔者经过采灵通事务场景的落地实践，最大的感触是在前期子域拆分时分的纠结，在此，给咱们讲个例子：
比方产品模块，前期会考虑到底是拆成一个产品子域呢，仍是拆成两个子域：同伴产品子域和供货商产品子域。假如是一个产品子域，事务完成上会简略一些，但未来事务场景拓展会受限。假如拆成两个子域，前期体系规划会添加杂乱度，包含产品池的同步问题，数据一致性问题，等等。但后期来说，会更适配事务场景，所以终究笔者的挑选是跟产品司理充沛沟经过事务需求后，挑选了拆成两个子域。
所以，作为一个事务架构师，榜首要务是要有充沛了解事务的才能，所以怎么跟产品司理紧密配合，其实是一个事务架构师的中心才能。其次才是技能维度的才能，包含对六边形架构的把控，对多种规划形式的应用，对体系高并发和高可用性的应对经历等。后面所说的这些才能，关于一个技能宅来说是很好提升的，但关于前面的这个才能，或许就因人而异了。
