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

（课程笔记及总结）



一、单体应用（对比微服务）：

编译、部署困难，导致工作效率极低；

代码分支管理困难；

数据库创建的连接太多（甚至耗尽）；

新增业务困难、维护难度巨大。

二、解决单体应用的问题：

拆分，将模块独立部署，降低系统耦合性。

纵向拆分：将一个大应用拆分成多个小应用，每个小应用独立部署。

横向拆分：将复用的业务拆分出来独立部署为微服务。

三、WebService的缺点：

臃肿的注册与发现机制；

低效的XML序列化手段；

开销相对较高的HTTP远程通信；

复杂的部署与维护手段；

所以难以满足大型网站对系统高性能、高可用、易部署、易维护的要求。

四、微服务框架的需求：

1、（对于服务提供者）负载均衡。

2、失效转移，以实现高可用。

3、高效的远程通信。

4、对应用最少侵入，支持渐进式演化和反复（服务模块需支持可集中式部署，也可分布式部署）。

5、版本管理，当服务升级时对应用的接口兼容性更好（多版本同时运行）。

五、学习微服务框架（Dubbo）架构（调用时序图见第十周作业）





六、Service Mesh服务网格

用于处理服务间的通信，通常表现为一组轻量级网络代理，他们与应用程序部署在一起，而对应用程序透明。

七、Service Mesh的Sidecar模式







八、微服务架构落地

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

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

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

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

九、命令与查询职责隔离（CQRS）

把查询读服务和命令写服务设计成两个不同的服务，分别部署。实现服务层地读写分离。

其优势：

1、更清晰的领域模型。

2、针对读写分别优化，实现更好的性能。

3、查询服务不会修改数据，更好地保护数据。





十、事件溯源

将用户请求处理过程种地每次状态变化都记录到事件日志中，并按时间序列进行持久化存储。

好处：

1、利用事件溯源，可以精确复现任何用户状态，进行复核审计。

2、利用事件溯源，可以有效监控用户状态变化，并在此基础上实现分布式事务。

十一、断路器

当某个服务出现故障（响应延迟或失败率增加），继续调用则会导致调用者请求阻塞，资源消耗增加，进而出现服务级联失效。这种情况下使用断路器阻断对故障服务的调用。





十二、服务重试及调用超时





十三、最重要的是需求

应该从上到下思考问题，去选择技术方案。先知道想要什么，以业务为重心





十四、以网关做为唯一入口（基于网关的架构）





 十五、网关的作用







十六、网关管道技术

网关本身不涉及业务，主要职责是做各种校验与拦截，这些职责可以通过管道技术连接起来。





 十七、实现管道技术的责任链设计模式





了解Flower异步网关



十八、开放平台网关





十九、授权码授权

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

（目前互联网上使用最多也最安全的方式是授权码方式）





二十、领域：

一个组织所做的事情以及其包含的一切，通俗的说，就是组织的业务范围和做事方式（也是软件开放的目标范围）

二十一、领域驱动设计：从领域出发，分析领域内模型及其关系，进而设计软件系统的方法。

需要对领域进一步分解，对领域分析的第一步就是子域拆分，业务就清晰了。

限界上下文：在一个子域种，会创建一个概念上的领域边界，在此边界中，任何领域对象都只表示特定于该边界内部的确切含义。限界上下文和子域具有一对一的关系，用来控制子域的边界，保证子域内的概念统一性（通常限界上下文对应一个组件或一个模块，或一个微服务，或一个子系统）。

上下文映射图：设计不同子系统或模块之间的关联和交互。

二十二、DDD六边形架构

领域模型通过应用程序封装成一个相对比较独立的模块，而不同的外部系统则通过不同的适配器和领域模型交互，比如可以通过HTTP接口访问领域模型，也可以通过WebService或消息队列访问领域模型，只需要为这些不同的访问接口提供不同的适配器就可以了。





二十三、DDD战略设计与战术设计

DDD战略设计：领域、子域、界限上下文、上下文映射图

DDD战术设计：实体、值对象、聚合、CQRS、时间溯源

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

二十四、组件内聚原则

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

1、复用发布等同原则。

2、共同封闭原则。

3、共同复用原则。

二十五、组件耦合原则

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

1、无循环依赖原则。

2、稳定依赖原则。

3、稳定抽象原则。