回顾上周作业：

1. JVM 垃圾回收

算法：可达性算法，三种清理算法，分代回收算法

垃圾回收器：四种 串行，并行，并发，G1，ZGC

2.秒杀挑战

对现有系统的影响，短时间大量并发请求，网络带宽，直接下单

独立系统 动态内容静态化 CDN 动态生成随机下单页面 Url

重点：脱颖而出的一定不是大路货，一定要找到问题的关键，一定不在大多数的方案里；靠学习只能维持不能淘汰，一定要找新的关键点，方案的关键点

老师分享的自己的案例：缩减 app 大小，通过分析最近半年提交的源码，按从大到小排序，找到相关部门处理

微服务

阿里早期微服务架构重构

多个模块，单体应用，一个大的 war 包

编译部署困难，一个包 3.2G；各个模块的依赖配置项复杂

代码分支管理困难：复用代码模块多个团队共同维护修改，解决代码冲突，纠结在一起，故此失彼

数据库连接耗尽：每个模块都需要连接数据库

新增业务困难：在一个关系乱麻般的系统中增加新业务

解决方案： 拆分

web service 方案：wsdl uddi soap

效率底下：http, xml

微服务：服务发现，协议转换，api 网关，其他 失效转移 负载均衡 加权轮询等（框架内解决不用 lvs）

高效的远程通信：对应用最小的侵入，服务的使用者感觉不到微服务的存在（服务代理，基于接口实现）

版本管理：快速变化的需求，版本升级，多版本同时运行（调用时带上版本号）

微服务框架：Dubbo；框架并不重要

消费者 注册中心， 提供者

容器启动-》注册服务

服务接口-》接口代理-》框架客户端

查找服务提供者列表 如果没有，则到注册中心里查找

负载均衡模块，算出一台服务器 -》 远程通讯调用

提供者：查找接口类，调用类方法（传参数），调用完成后，返回 class 保证成响应，返回

拿到响应，反序列化 class，返回接口应用程序

失效转移：很少访问的也需要集群

高效通信：长连接，二进制序列号协议

最少侵入：依赖一个接口包

支持版本管理：一个服务升级后，原来的版本保留半年

service mash

服务网格 消费者依赖的 sdk 包分离成一个独立组件，应用程序和 service mash 通信

client：

注册，查找，调用

client-》service mash ：查找，调用

sidecar 模式：

架构如何落地：

1. 业务先行， 理顺边界和依赖，发现真正的需求

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

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

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

不要用战术上的勤奋掩盖战略上的懒惰

相关概念：

CQRS，读写操作分离，实现服务层的读写分离。

更清晰的领域模型，针对读写分别优化，实现更好的性能

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

读：缓存；写：消息队列

事件溯源：所有写操作都记录到日志中，并按照时间序列进行持久化存储。可精确复现任何用户状态，进行复核审计

可以监控状态变化，并在此基础上实现分布式事务（记录全部正确完成的事务）

断路器：某个服务出问题时，响应延迟，失败率增加等，可以断路处理，半开，或全闭

最重要的需求：

needs，values，principles，practices，tools

rpc：协议原理，远程过程调用，是一个底层协议及框架

形形色色的架构师：

mbta 测试-》n 值，s 值

宏观的，抽象的，整体的；具体的，

按作用：设计型；救火型；布道型；Geek 型架构师

DDD

领域模型：

各种概念和细节

真正的关键点是什么

不断变更

各处代码实现，修修补补

有些越来越大，有些越来越小

只有需求分析，没有设计，没有一个统一的领域模型维持其内在的逻辑一致性

代码应该放在哪里

有哪些模块，模块之间的关系如何

需求不断延期，线上 bug 不断，不断延期；

举例遥控器：密密麻麻的按键，堆功能。

事务脚本：

控制层，服务层，DAO 没有对象，没有模型，

通过业务自己完成，合同类

事务脚本里合同是没有任何方法的，只是一个数据集

领域模型里每个对象本身要完成本相关的计算

有几种策略，就有几种策略类。

计算合同：

让对象处理自己的相关业务，拥有自己的成员变量

而不是脚本方式的把方法和对象进行分离

本质上就是面向对象设计

贫血模型《》充血模型

事务脚本方式为贫血模型

领域模型包含了对象的数据和计算逻辑，是真正的对象

设计不好无法落地

DDD 的出现是用来解决这个问题的

战略设计

核心是领域，就是组织包含的一切，也是软件开发的目标范围

拆分成多个子域：通过内聚性，低耦合

如何划分子域

跟财务相关？

子域就是微服务：子域分析清楚了，边界清楚了，

那么服务的边界就划分清楚了

限界上下文：任何领域对象都只表示特定与该

边界内部的确切含义。限界上下文和子域具有一对一的关系，用来控制子域的边界，保证子域内的概念统一性

不同的限界上下文，也就是不同的子系统，模块之间会有各种交互

可以只使用战略设计，用来划分微服务

战术设计：

实体：唯一的，有行为的。识别对象，承担的职责

值对象：没有行为，特定是不变性

聚合：关联对象的集合

这个节奏，关键点需要把控。

DDD 战略设计：领域建模

DDD 战术设计：样例代码

按照战略与战术设计，将重构开发和迭代像结合