期待了很久的DDD和微服务终于在上一周开始讲了。

但其实也只是抱着增长见识的心态来听的，毕竟微服务这些东西；仔细思考下，这两块内容归根结底还是和业务息息相关的，市面上应该没任何人能保证可以说出一个放之四海皆准的，可以直接生搬硬套落地的框架。多多少少还是有些心得的：

1.其实为服务这个概念好早就有了，WebService就是其中之一，但以前的类微服务规范之所以未能火起来，与其所在历史阶段有一定的联系，它所采用的的序列化手段，以及通信消耗相较于当代；都显得十分臃肿以及开销巨大；而其臃肿的注册发现机制和复杂的部署和维护手段也使得它门槛非常高（没经历过，不太能体会到，只能照搬老师的原话...）。

2.微服务框架需要：

1、规范的服务注册与发

2、远程服务调用

3、失效转移

4、负载均衡

5、高效的远程通信（更好的序列化手段和消耗小的网络通信协议）

6、应用侵入少

7、版本管理。

Service Mesh：don't call me ,I will call you，感觉这样设计对应用程序非常友好。将查找服务以及负载均衡等复杂的操作交给一个中间层Service Mesh来处理。

断路器：类似壁虎断尾，防止一个服务的故障导致整个系统的不可用，但其实有些需要依赖返回的情况下，即使有断路器，但也是有问题的，所以感觉最好fall-fast。

微服务架构落地：

1.业务先行，只有理顺了业务的边界和依赖，才能更好地分割服务的范围。技术是手段，而不是目的。

2.现有独立的模块，后有分布式的服务。（感觉意思和上面有些重复）

3.业务耦合严重，逻辑负责多变的系统进行微服务重构需要谨慎（因为业务已经耦合在一起了,那么肯定是有些比较复杂的逻辑在其中交织的，不能简单粗暴的将其切割开来；不然很容易出现分割不明晰、或者分割以后调用复杂；加大调试难度。）

4.搞清楚为什么要去做微服务，复用、清晰开发边界、集群提升性能还是仅仅是为了微服务而微服务。

学到一个新名词：

CQRS!(将读操作和写操作分为不同的服务，用不同的API进行调用)

Tips：上游调用者的超时时间要大于下游调用者超时时间之和；这个逻辑上很清晰，感觉很多余，但仔细想想真正在开发中这样的小事情应该很容易被忽略的。老师应该是以前踩过这方面坑所以才特意把这个拎出来曝光的吧~

偷老师一幅图~：

DDD:

战略设计：

1.领域

2.子域

3.限界上下文

4.上下文映射图

战术设计：

1.实体

2.值对象

3.聚合

4.CQRS

5.事件溯源

战略实际划分模块和服务的边界及依赖关系，来支撑微服务的架构设计。

沟通前，统一业务术语很重要！（沟通能解决一切问题，出问题的原因多数是因为没沟通好。）



程序员的真正核心竞争力不在于奇技淫巧，而是在于一个领域多年的积累，对业务领域有深刻的理解和认知。这才是程序员在职业生涯中真正的价值所在。