阿里P8十年总结的Boot+Cloud微服务开发实战全栈笔记

1、什么是微服务

作为一名有经验的技术人员，相信我们在日常的开发过程中、或者是技术交流的过程中，是很容易听见微服务这个名词的，但是什么是微服务呢？这个概念如果不清楚，对于我们后面使用 DDD 来做服务拆分也是很有难度的。

1.1、职责单一

单体系统中我们所有的业务代码都是在一起的，就会导致一个项目下面的代码膨胀，哪个地方一旦出现了 BUG 可能会导致很多地方的一个业务错误，而这个时候如果我们想要进行代码的修复，也是一件很闹心的事情，因为代码之间的耦合程度太高了。
在学习设计模式的时候会介绍几大原则，而其中的一条就是单一职责原则（讲究模块功能要尽可能的独立），微服务就很好的践行这个原则，根据业务的边界来确定服务的边界，这样就很容易的确定某个功能代码应该放在哪里。
而想要保证一个服务的内聚高，那么所有的代码都会为当前模块服务，这也就意味着代码量不会很大，要将一些不太相关的量剔出来成为三方。但是什么样的代码量叫做小呢，多小才合适呢，可能没有一个标准答案，但和扇入扇出要平衡一样，不能太小功能不齐全，不能太大内聚降低。

1.2、自治性

之前我们讲到微服务就是一个小型的独立系统，可以单独的部署出来，一个服务内部的变动是可以独立修改的。相对于外界而言使用 API 接口进行通信，以实现技术和消费方之间的解耦合。
也可以这样的来理解，就是一个功能单一的服务提供者，保持高度的内聚为其他服务提供访问能力，自身对外界的依赖较小，在发生变化时对外界是屏蔽的，即使是更新出现 BUG 也能快速的回滚到之前版本而不影响其他服务的正常工作。
而对于一个系统的耦合程度有一个黄金法则：

你能否修改一个服务并对其进行部署，而不影响其他的任何服务？
而要达到上面的这个目的，需要正确的进行建模服务和 API 搭建。