模块分解

本周是跟随李智慧老师学习架构师训练营的第十周，现将本周的主要内容总结如下：

传统代码模式（巨无霸系统）带来的问题：

编译、部署困难

代码分支管理困难

数据库连接耗尽

新增业务困难

解决方案就是业务拆分：

1.纵向拆分：业务独立

2.横向拆分：业务复用

Web Service服务

WSDL：Web Service Description Language Web服务描述语言

UDDI：Universal Description Discovery and Integration 同一发布描述和集成

SOAP：Simple Object Access Protocol 简单对象访问协议

缺点：

臃肿的注册与发现机制

低效的XML序列化手段

开销相对较高的HTTP通信通道

复杂的部署与维护



微服务框架应提供的基本支持：

失效转移

负载均衡

对应用最少侵入

版本管理



Service Mesh 服务网格：基础设施层，用于处理服务间通信，通常表现为一组轻量级网络代理，与应用程序部署在一起，对应用程序透明。一般用于复杂的系统



微服务实践

业务现行，

命令与查询职责隔离（CQRS）：服务层读写分离，将查询（读）与命令（写）隔离

事件溯源：记录状态日志

断路器：状态：关闭、打开、半开

服务重试与调用超时：上游超时要大于下游超时时间之和

倒三角模型：Need(需求)-->Values(价值)-->Principles(原则)-->Practices(最佳实践)-->Tools(工具)



微服务网关

1.统一接入：高性能、高并发、高可靠、负载均衡

2.流控与容错：限流、降级、熔断

3.协议适配：http、dubbo

4.安全防护：防刷控制、黑白名单

网关管道技术-->责任链模式

开放平台网关（供第三方调用）：

1.API接口

2.协议转换

3.安全：权限、网络带宽限制

4.审计：监控、计费

5.路由

6.流程：提供接口，隐藏细节

开放授权协议OAuth2.0：授权码（应用最多，最安全）、隐式授权、资源所有者密码凭据、客户端凭据



领域模型

传统的事务脚本模型，也叫贫血模型，Service Dao Controller

领域模型：合并了行为与数据的领域对象模型，领域对象包含了对象的数据和计算逻辑，充血模型

子域

限界上下文：与子域一对一，控制子域边界

上下文映射图：描述子系统之间的交互和合作

实体：领域模型对象，根据业务需求结合限界上下文分清实体的职责，唯一标识 状态

值对象：不变性，仅用来做度量或描述的对象，例如地址，建在地址上的房子可以被看作一个实体，实体状态可变，地址不变

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

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

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



组件设计原则：

1.组件内聚原则

复用发布等同原则

共同封闭原则

共同复用原则：不要强迫用户依赖他们不需要的类

2.组件耦合原则

无循环依赖原则

稳定依赖原则：一个组件不应该依赖一个比自己还不稳定的组件

稳定抽象原则：一个稳定的组件是抽象的，不稳定的组件是具体的



作业一：

（至少完成一个）

根据微服务框架 Dubbo 的架构图，画出 Dubbo 进行一次微服务调用的时序图。





关于微服务架构（中台架构、领域驱动设计、组件设计原则），你有什么样的思考和认识？