作者：京东物流 赵勇萍
一. 前言
当初对于一个后端开发工程师来说，微服务，DDD 都是挂在嘴边的货色，感觉大家接触到多，也理解的多。但笔者集体的感触是，对微服务架构的了解就像我小时候读三国，在不同年龄读的时候感触都不一样。微服务对于开发人员来说亦是如此，一千个人有一千种解读，而随着每个人本人的业务教训和架构能力的晋升，每个人看到的风光也会不一样的。明天笔者想联合一下本人的业务实际，分享一下本人基于微服务架构实际后的心路历程。
二. 首先，咱们须要思考一下：什么是微服务架构？
在笔者看来，微服务架构并没有一个精确的定义，但他会有很多特色，通过形容他的特色用来把控它是什么。
a. 白马是马。
这是一个哲学命题，表明个别和个别的关系。我认为，任何的技术和架构都不是凭空出现的，肯定是倒退而来，而微服务架构的前身就是 SOA，面向服务的编程。SOA 是一种架构设计模式，也是一种思维。所以微服务理当继承了 SOA 的这种架构思维，所以我认为微服务就是那个白马，他将一个简单零碎，以业务的视角，分成独立的模块，每个模块都有提供服务的能力，基于这些能力，去构建一个简单的零碎架构，在此基础上，再演变进来中心化，和分布式思维。
b. 服务治理
以上说的是思维层级，在战术层级，微服务架构的外围诉求和能力是服务治理，包含服务寻址，流量治理，可观测性等。
c. 十二因素
Heroku 创始人 Adam Wiggins 提出的微服务十二因素，上面，我贴出我对微服务十二因素的解读：
这十二因素能够说是微服务架构的方法论，有了思维，方法论和战术维度，我感觉就能够残缺的描绘出一个微服务架构的全景图。而后，我将我了解的微服务架构总结成一句话：
微服务架构是：一种去中心化的分布式服务架构，架构领有服务寻址，故障容错，流量调度，管制拜访和可观测性的服务治理能力，从而实现服务的隔离性，可移植性，可扩展性，稳定性。
三. 其次，咱们的问题焦点：微服务架构的难点是什么？
笔者认为，微服务的两个外围点闲事他的难点：
第一个难点，微服务的服务治理和流量治理。
对于这个难点，现阶段曾经有了很好的解决，因为服务治理和流量治理是去业务场景化的，所以有很多前人通过他们的致力，以及奉献的开源框架，让咱们能够间接能够拿来落地的，并且能够做到很好的兼容。下图是一个比拟规范的微服务治理架构图：
第二个难点，微服务拆分的架构思维.
如何基于 DDD 方法论落地服务的合成。该处设计很多外围能力，包含子域划分，限界上下文定义，实体，聚合根的形象，基于畛域事件的事件驱动设计，除此之外，还有工厂模式，策略等等设计模式的利用。
这第二个难点是很难做到间接的迁徙，因为咱们面对的业务场景千差万别，前人的教训只能总结成思维来领导咱们，但具体的落地就会考验每个架构师本人的过往教训和了解。就像一为画家，对与同一片风光的了解不同，画出的画面也是不同的，所以，就会呈现有的人是梵高，有的人是毕加索。而对于笔者现阶段来说，可能只是一个刚入门的素描者，不过我违心在此抛砖引玉，介绍一下我采灵通我的项目对于微服务落地的教训，供大家做一个简略参考。
四. 最初，来点干货：采灵通零碎 – 微服务架构落地实际
笔者负责的采灵通业务是一个绝对简单的零碎，率领了 20 人的开发团队总共历时 5 个月，实现从 0 到 1 的设计，开发和上线。该零碎根本涵盖了一个 ToB 全供应链数字化相干的全场景业务。笔者将通过 业务场景剖析，技术架构解析，和服务落地几个方面对该零碎的落地实际进行解读。
1. 业务场景解析
了解 DDD 的前提是先要了解业务场景，笔者的业务场景是采灵通 SAAS 零碎，在此简略做一个业务介绍：
采灵通是一个规范的提供 B 商城触达的，同时解决企业数字化洽购供应链的 SAAS 平台 ，外围能力包含多供应商协同，订单治理，商品治理，客户治理，及 B 商城的搭建和治理，具体如下图所示：
2. 技术架构解析
基于以上业务场景，咱们构建出咱们的技术架构计划，如下图所示：
在技术架构上，整体分为四层，自上而下为：业务前端层，网关层，业务服务层，技术底座层。
1. 业务前端层 ：前端根于业务场景，有多个触达端，最次要的端有供应商治理端，搭档治理端，PC 商城端，H5 商城端，页面装修零碎。前端封装有对立的组件库，保障了整个零碎的前端交互格调一致性。
2. 网关层 ：入口网关为 nginx 反向代理，次要性能是对不同域名的 SSL 解析和门路映射，局部前端动态资源的间接映射。入口网关下为业务网关，包含 COP 网关和通用业务域网关。
通用业务域网关：次要性能是将前端有状态的 HTTP 申请（header:jwt 信息加密和域名信息过滤），进行鉴权，过滤，路由。同时解析为明文上下文 Map, 存于 header 中，可供业务层服务应用。其中针对不同域名的路由信息是采纳了 nacos 的配置核心进行对立治理，并下发至 gateway，实现一个动静的域名路由治理。
COP 网关：负责零碎对外开放平台的 API 接口鉴权和路由代理。
3. 业务服务层 。
该层又有细分，分为 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. 畛域服务进行人造分库解决。
五. 总结
笔者通过采灵通业务场景的落地实际，最大的感触是在后期子域拆分时候的纠结，在此，给大家讲个例子：
比方商品模块，后期会思考到底是拆成一个商品子域呢，还是拆成两个子域：搭档商品子域和供应商商品子域。如果是一个商品子域，业务实现上会简略一些，但将来业务场景拓展会受限。如果拆成两个子域，后期零碎设计会减少复杂度，包含商品池的同步问题，数据一致性问题，等等。但前期来说，会更适配业务场景，所以最终笔者的抉择是跟产品经理充沛沟通过业务需要后，抉择了拆成两个子域。
所以，作为一个业务架构师，第一要务是要有充沛了解业务的能力，所以如何跟产品经理紧密配合，其实是一个业务架构师的外围能力。其次才是技术维度的能力，包含对六边形架构的把控，对多种设计模式的利用，对系统高并发和高可用性的应答教训等。前面所说的这些能力，对于一个技术宅来说是很好晋升的，但对于后面的这个能力，可能就因人而异了。