【架构师训练营第 1 期 10 周】 学习总结

【架构师训练营第 1 期 10 周】 学习总结



这周学习了近几年后端架构最火热的知识点：微服务。微服务来源于单体服务难以快速开发迭代满足业务创新，所以将一个大型系统拆分成多个微服务，各自负责自己领域的业务。微服务架构在解决了数据内部传输的延时问题之后，大规模发展。各种组件如雨后春笋冒出来，基本现在后段开发大部分都是按微服务架构开发。

近期开发后觉得微服务在划分业务领域和一些设计思路上也是有很多要注意的地方，一定要在划分业务时清晰准确，避免后面迭代混乱，回到同样的困境。

展望未来，“微服务”已经是主流，下一步发展很可能是“云原生”，由云服务商提供各种成熟组件，开发直接调用数据库、队列、分布式管理系统就可以。每个微服务都部署在容器内便于管理。



下面的是这周学习的笔记，记录感觉重要的知识点。还需多琢磨细节。



====================分割线=============================

10.1 微服务：服务本身的设计、维护以及治理

困难点：代码太多打包慢，代码分支管理困难，数据库连接耗尽，新增业务困难；

解决方案：拆分成独立模块部署，降低系统耦合性。



soap没有整理好，大量无用的数据，http协议比较低；



微服务框架需求：

规范的服务注册与发现，服务调用等标准功能，还需要微服务框架能够支持；

负载均衡

失效转移

高效的远程通信

对应用最少入侵

版本管理



====================分割线=============================

10.2 微服务：落地实践的策略和思路



Service Mesh 服务网络



边车模式 Sidecar



微服务架构落地

业务先行，先理顺业务边界和依赖，技术是手段而不是目的。

先有独立的模块，后有分布式的服务。

业务耦合严重，逻辑复杂多变的系统进行微服务重构要谨慎

要搞清楚实施微服务的目的是什么，业务复用？开发边界清晰？分布式集群提升性能？



命令与查询职责隔离CQRS：分成读服务和写服务

时间溯源：状态变更记录到实践日志，并按时间进行持久化存储

利用时间溯源，可以精确复现任何用户状态，进行复核审计。可以有效监控用户状态变化，并在此基础上实现分布式事务。（因为分太细需要最终跳转溯源）

断路器：当服务器出现故障，阻断对故障服务器的调用。断路器的三种状态：关闭，打开，半开

服务重试及调用超时：上游调用者超时时间必须大于下游超时时间



最重要的需求：根据现有需求再技术选型，把重心放到需求上。



====================分割线=============================

10.3 微服务网关的技术架构



基于网关的微服务架构，网关作用：统一接入、流量管控与容错、安全防护、协议适配。

网关管道技术：责任链设计模式



Flower异步网关与异步微服务框架：发出请求就不管了，处理能力更加强大。全靠服务编排。

Servlet3 contex = req.startAsync();



开放平台网关

开放授权协议OAuth2.0：四种授权方式授权码、隐式授权、资源所有者密码凭据和客户端凭证。



====================分割线=============================

10.4 领域驱动设计DDD



事务脚本



贫血模型（事务脚本模式）VS充血模型（领域模型）



战略设计

子域：一个领域拆分成多个子域，根据业务划分子域，而不是根据页面。（逻辑上的）

限界上下文：确定边界（物理上的）

上下文映射图：上下文之间交互合作

得到微服务交互架构图



战术设计

实体：一个订单就是一个实体。实体设计是DDD的核心所在，首先通过业务分析，识别出实体对象，然后通过相关的业务逻辑设计实体的属性和方法。最重要的，是要把握住实体的特征是什么，实体应该承担什么职责，不应该承担什么职责，分析的时候要放在业务场景和界限上下文中，而不是想当然地认为这样的实体就应该承担这样的角色。

值对象：尽可能将对象设计为值对象。

聚合：关联对象的集合



DDD分层架构

用户接口层->应用层->领域层

DDD六边形：通过适配器去交互。



DDD战略设计与战术设计

领域、子域、界限上下文、上下文映射图，这些都是DDD的战略设计。

实体、值对象、聚合、CQRS、时间溯源，这些都是DDD战术设计。

通过战略设计，划分模块和服务的边界及依赖关系，对微服务架构的设计至关重要。



====================分割线=============================

10.5 软件组件设计原则



软件的复杂度和它的规模成指数关系，复杂度100单个，拆分成2个一样的，每个系统复杂度是25，而不是50。



组件内聚原则

主要讨论哪些类应该聚合在同一个组件中，以便组件能够提供相对完整的功能，又不至于太过庞大。

复用发布等同原则：你希望别人以怎样的粒度复用你的软件，你就应该以怎样的粒度发布你的软件。定义了最小粒度软件单元。

共同封闭原则：我们应该将哪些会同时修改，而且为了相同目的而修改的类放到同一个组件中。而将不会同时修改，并且不会为了相同目的而修改的类放到不同的组件中。

共同复用原则：不要强迫一个组件的用户依赖他们不需要的东西。



版本号例子：1.3.12，主版本号1，次版本号3，修订号12.

主版本号：不向前兼容重大修订；

次版本号：向前兼容，修订重要功能

修订版本号：向前兼容，修订不重要功能



组件耦合原则

组件内聚原则讨论的是组件应该包含哪些功能和类，而组件耦合原则讨论组件之间的耦合关系应该如何设计。



无循环依赖原则：组件依赖关系中不应该出现环，比如A依赖B，B依赖C，C依赖A。一般是迭代MVP过程中出现。把组件依赖关系图画出来。

稳定依赖原则：组件依赖关系必须指向更稳定的方向。缺少变更的组件是稳定的。

稳定抽象原则：一个组件的抽象化程度应该与其稳定性程度一致。



组件的边界与依赖关系，不仅仅是技术问题。

组织架构决定系统架构



====================分割线=============================

10.6 案例：用领域驱动设计驱动系统重构



泳道区分业务场景



对常用的值转化为值对象，添加校验代码。

String phone - > PhoneNumber phone



重构过程总结：

1.当前系统设计与问题汇总讨论：架构与代码混乱，需求迭代困难，部署麻烦，bug率逐渐提升

2.针对问题分析具体原因：微服务A太庞大，微服务B和C职责不清，团队内业务理解不一致，内部代码设计不良，硬编码和耦合太多。

3.重新梳理业务流程图，明确业务术语，进行DDD战略设计：（泳道）活动图、子域分解、限界上下文设计

4.针对当前系统实现和DDD设计不匹配的地方设计微服务重构方案

5.DDD战术设计与技术验证：聚合、实体、值对象设计，打样代码开发

6.任务分解和持续重构：在不影响业务开发的前提下，按照战略与战术设计，将重构开发和业务迭代有机融合。