【实践篇】教你玩转微服务——根据DDD的微服务架构落地实践之路

　　现在关于一个后端开发工程师来说，微服务，DDD都是挂在嘴边的东西，感觉咱们接触到多，也了解的多。但笔者个人的感受是，对微服务架构的了解就像我小时分读三国，在不同年纪读的时分感受都不相同。微服务关于开发人员来说亦是如此，一千个人有一千种解读，而跟着每个人自己的事务经历和架构才能的提高，每个人看到的景色也会不相同的。今日笔者想结合一下自己的事务实践，共享一下自己根据微服务架构实践后的心路历程。

　　在笔者看来，微服务架构并没有一个精确的界说，但他会有许多特征，经过描绘他的特征用来把控它是什么。

　　这是一个哲学出题，标明单个和一般的联系。我以为，任何的技能和架构都不是凭空呈现的，必定是开展而来，而微服务架构的前身便是SOA，面向服务的编程。SOA是一种架构规划形式，也是一种思维。所以微服务理应承继了SOA的这种架构思维，所以我以为微服务便是那个白马，他将一个杂乱体系，以事务的视角，分红独立的模块，每个模块都有供给服务的才能，根据这些才能，去构建一个杂乱的体系架构，在此根底上，再演化出去中心化，和分布式思维。

　　以上说的是思维层级，在战术层级，微服务架构的中心诉求和才能是服务办理，包含服务寻址，流量办理，可观测性等。

　　Heroku创始人Adam Wiggins 提出的微服务十二要素，下面，我贴出我对微服务十二要素的解读：

　　这十二要素能够说是微服务架构的方法论，有了思维，方法论和战术维度，我觉得就能够完好的描绘出一个微服务架构的全景图。然后，我将我了解的微服务架构总结成一句话：

　　微服务架构是 ： 一种去中心化的分布式服务架构，架构具有服务寻址，毛病容错，流量调度，操控拜访和可观测性的服务办理才能，然后完结服务的阻隔性，可移植性，可扩展性，稳定性。

　　关于这个难点，现阶段已经有了很好的处理，由于服务办理和流量办理是去事务场景化的，所以有许多前人经过他们的尽力，以及奉献的开源结构，让咱们能够直接能够拿来落地的，而且能够做到很好的兼容。下图是一个比较规范的微服务办理架构图：

　　怎么根据DDD方法论落地服务的分化。该处规划许多中心才能，包含子域区分，限界上下文界说，实体，聚合根的笼统，根据范畴事情的事情驱动规划，除此之外，还有工厂形式，战略等等规划形式的运用。

　　这第二个难点是很难做到直接的搬迁，由于咱们面临的事务场景千差万别，前人的经历只能总结成思维来辅导咱们，但详细的落地就会检测每个架构师自己的过往经历和了解。 就像一为画家，对与同一片景色的了解不同，画出的画面也是不同的，所以，就会呈现有的人是梵高，有的人是毕加索。而关于笔者现阶段来说，或许仅仅一个刚入门的素描者，不过我乐意在此抛砖引玉，介绍一下我采灵通项目关于微服务落地的经历，供咱们做一个简略参阅。

　　笔者担任的采灵通事务是一个相对杂乱的体系，带领了20人的开发团队一共历时5个月，完结从0到1的规划，开发和上线。该体系根本涵盖了一个ToB全供应链数字化相关的全场景事务。笔者将经过 事务场景剖析， 技能架构解析，和服务落地几个方面临该体系的落地实践进行解读。

　　了解DDD的条件是先要了解事务场景，笔者的事务场景是采灵通SAAS体系，在此简略做一个事务介绍：

　　采灵通是一个规范的供给B商城触达的，一起处理企业数字化收购供应链的SAAS渠道，中心才能包含多供货商协同，订单办理，产品办理，客户办理，及B商城的搭建和办理，详细如下图所示：

　　1.事务前端层：前端根于事务场景，有多个触达端，最主要的端有供货商办理端，同伴办理端，PC商城端，H5商城端， 页面装饰体系。前端封装有一致的组件库，确保了整个体系的前端交互风格一致性。

　　2.网关层：进口网关为nginx反向署理，主要功能是对不同域名的SSL解析和途径映射，部分前端静态资源的直接映射。进口网关下为事务网关，包含COP网关和通用事务域网关。

　　通用事务域网关：主要功能是将前端有状况的HTTP恳求（header:jwt信息加密和域名信息过滤），进行鉴权，过滤，路由。一起解析为明文上下文Map,存于header中，可供事务层服务运用。其间针对不同域名的路由信息是采用了nacos的装备中心进行一致办理，并下发至gateway，完结一个动态的域名路由办理。

　　a. COP：主要是封装对外开发接口一致认证服。经过COP，SAAS体系能够完结对下流来说，对接第三方供应链的接口渠道；对上游来说，对接同伴的客户ERP体系，政采渠道，OMS体系等。

　　范畴服务层是根据DDD范畴驱动规划思维，对现有事务进行笼统，依照不同的子域区分不同的服务，每个范畴服务内都有针对该子域的聚合根的笼统封装。而聚合服务是针对不同的事务场景，对范畴服务调用进行一层聚合，使其能够更好的为前端供给接口服务。

　　适配器层是针对不具有范畴概念的但又有必定含义的服务封装，比方根据CQRS的规划理念下的查询服务；其次是一些后台异步使命服务，如数据导入导出，数据同步等等。

　　c. 数据渠道层：针对SAAS体系的发生中心数据，例如订单，产品，根据CQRS理念，将数据进行整合和同步，完结多场景下单数据杂乱查询和BI数据剖析。

　　TPAAS： 包含k8s,容器化编列， Istio流量办理 ,日志收集和检查，链路追寻监控，中间件（数据存储，MQ），CI/CD等

　　BPAAS：包含一些根底jar包，如低代码结构，安全组件。还有一些根底服务，工作流服务，使命调度服务，分布式ID生成器服务等。

　　笔者经过采灵通事务场景的落地实践，最大的感受是在前期子域拆分时分的纠结，在此，给咱们讲个比方：

　　比方产品模块，前期会考虑到底是拆成一个产品子域呢，仍是拆成两个子域：同伴产品子域和供货商产品子域。假如是一个产品子域，事务完结上会简略一些，但未来事务场景拓展会受限。假如拆成两个子域，前期体系规划会添加杂乱度，包含产品池的同步问题，数据一致性问题，等等。但后期来说，会更适配事务场景，所以终究笔者的挑选是跟产品司理充沛沟经过事务需求后，挑选了拆成两个子域。

　　所以，作为一个事务架构师，榜首要务是要有充沛了解事务的才能，所以怎么跟产品司理紧密配合，其实是一个事务架构师的中心才能。其次才是技能维度的才能，包含对六边形架构的把控，对多种规划形式的运用，对体系高并发和高可用性的应对经历等。后边所说的这些才能，关于一个技能宅来说是很好提高的，但关于前面的这个才能，或许就因人而异了。