第十周 模块分解 总结

微服务框架需求：服务注册与发现、失效转移、负载均衡、高效的远程通信、对应用最少侵入、版本管理



Dubbo架构：服务注册中心、服务提供者、服务消费者



Service Mesh服务网格：Service Mesh是一个基础设施层，用于处理服务间通信，通常表现为一组轻量级网络代理，他们与应用程序部署在一起，而对应用程序透明

Service Mesh的sidecar模式



微服务架构落地：

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

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

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

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



CQRS：命令与查询职责隔离，读写分离

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



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

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



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



最重要的是需求



微服务网关：统一接入、安全防护、流量管控与容错、协议适配



开放授权协议Oauth2.0：目前互联网上使用最多的是授权码方式授权



领域驱动设计：贫血模型 VS 充血模型

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

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

子域：通常一个领域拆分成多个子域

限界上下文：在一个子域中，会创建一个概念上的领域边界，在这个边界中，任何领域对象都只表示特定于该边界内部的确切含义，这样的边界便称为限界上下文

上下文映射图：不同的限界上下文，也就是不同的子系统或者模块之间会有各种的交互合作。DDD使用上下文映射图来设计这种交互。

实体：领域模型对象。每个实体都是唯一的，具有一个唯一标识

值对象：值对象是不变的，没有行为和状态，仅仅用来作为度量或描述的对象。

聚合：关联对象的集合

聚合根：将多个实体和值对象聚合在一起的实体



DDD分层架构：用户接口层、应用层、领域层

领域实体的组合调用和事务控制在应用层

DDD六边形架构



DDD战略设计与战术设计

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

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

通过战略设计，划分模块和服务的边界及依赖关系