前言
该系列笔记的内容主要来源于人邮出版的《微服务设计》一书。
第一章 微服务
微服务的由来
微服务不是发明出来的，而是随着领域驱动设计、持续交付、按需虚拟化、基础设施自动化、小型自治团队、大型集群系统这些实践的流行，从现实世界总结出来的。
拓展知识点：Eric Evans的《领域驱动设计》、Alistair Cookburn的六边形架构理论、Netflix的构建大型反脆弱系统
什么是微服务
微服务很小
在考虑微服务时，内聚性这一原则很重要，具体可以联想到单一职责原则(Single Responsibility Principle)。
微服务的边界如何划分？答案是根据业务的边界来确定服务的边界。
至于很小，多小算是小？这个事情仁者见仁智者见智，有的人说花2周的时间能够构建完就可以，有的人说你认为已经够小了就行，我的理解是：只要边界小到能够提供独立的服务就行了。微服务是自治的
一个微服务就是一个独立的实体，一个微服务的部署或修改应该尽量避免对消费方的修改，一个很典型的例子就是有人在设计接口返回值的时候用枚举，这其实很坑的。
微服务的好处
1.技术异构性
服务端和消费端可以采用不同的技术。如果把dubbo看做一个微服务框架，那么它在技术异构性方面做得并不好。当然也有人对dubbo进行了改良，比如当当的dubbox，它在dubbo协议基础上增加了REST接口，这样消费方就可以使用其他协议与dubbo进行交互了。
2.弹性
弹性工程学的一个关键概念就是“舱壁”，比如轮船的水密舱。当一个舱进水时，通过关闭该舱来确保其它舱不进水，进而保证整条船的安全。在微服务中，一个服务A可能会消费下游的很多服务，如果下游的某个服务有问题，那么它不能影响A服务自身的运行的。
3.扩展
对于单块服务来讲，即便是系统中某一个服务存在性能问题，那么也需要对整个系统进行扩展。如果使用较多的小服务，那么你只需要对存在性能问题的服务进行扩展就行了。
4.简化部署
对于线上服务来说，相对于代码量巨大的单块系统，微服务具有灵活的部署优势和更小的部署风险。这里引申出一个比较重要的部署原则就是：每次部署应尽量少地修改代码，这样才能减少两次部署之间的差异。
5.与组织机构更加匹配
说到系统与组织机构的关系，就不能不提康威定律。梅尔.康威在1968年4月的Datamation杂志上发表的一篇名为“How Do Committees Invent”的论文中提出：任何组织在设计一套系统时，所交付的设计方案在结构上都与该组织的沟通结构保持一致。
这里暂时不对康威定律做过多描述，但最起码有一点是肯定的，相比于单体应用，为服务能够更好地在团队之间交接，尤其那些业务、团队频繁变动的公司。
6.可组合性
相比单体应用，为服务能够更方便地组合成新的微服务，这一点的思路跟乐高倒是有点相像。
7.可替代性
一个规模比较大的单体应用，相信很少有人敢替代它。但对于一个规模比较小的微服务来讲，重新实现或者删除这个服务的可行性就大大增加了。
微服务的不足
《微服务设计》这本书里面只是提到了微服务的好处，但是并没有提到微服务有哪些不足和挑战，这里自己做一些总结。
1.维护压力
首先从服务部署的角度，无论是单机多服务，还是单机单服务，都会运维量的增加。单机多服务意味着服务维护复杂性的增加。比如服务器load高了，那到底是哪个服务引起的呢？单机单服务意味着服务器数量的增加。
另外，微服务之间存在着很强的关联关系，当系统出现异常时，很有可能是因为下游的系统异常导致的，这就需要我们做好服务的监控和治理，甚至问题排查。因此，一旦你开始引入微服务，那么你就要在最开始的时候好好规划服务的治理。
2.重复性劳动
重复性劳动是指你可能无法更多地像单体应用那样引用部分代码，毕竟服务之间是隔离的。当然你也可以通过抽取lib包这样的方式在微服务之间做到代码复用，但是那样就需要微服务的团队之间具有有效的沟通机制。
3.系统运行效率
微服务之间的交互是通过网络进行的，因此网络的效率、稳定性就变得更加重要。在单体应用中，我们不必担心模块之间交互的数据量、效率，但是在微服务中，服务与服务之间的效率将至关重要。
4.资源浪费
一般来说，微服务推荐的部署方式是单机单服务，这也意味着更多的资源浪费。毕竟我们需要为操作系统、其他基础设施预留一些内存。在一个单体应用中，这些内存就可以共用。
图片描述：人间净土-喀纳斯
