《微服务设计》阅读笔记一

《微服务设计》，Building Microservices，作者Sam Newman，译者崔力强、张骏，人民邮电出版社，2016年。

笔记中有些内容直接引用原书。

====================================================

第一章微服务

微服务强调内聚性，根据Robert C. Martin对单一职责的论述：“把因相同原因而变化的东西放在一起，而把因不同原因而变化的东西分离开来”强调了内聚性。

微服务是独立的服务，并且根据业务边界来确定服务的边界。注意，这里强调的是服务边界，而不是技术边界。传统的如N层架构，MVC架构都是基于技术边界来划分，这种分法看来是不适合划分微服务的。

微服务强调微，微即是小，多小的代码量能称为微服务。按澳大利亚RealEstate.com.au的John Eaves认为，一个微服务应该可以在两周内完全重写。作者给出的回答太含糊：“足够小即可，不要过小。”相比之下，前者的定义更好度量。后者的定义颇为主观。另外，一个微服务对应一个小团队，团队大的话就说明微服务不够微。这又归结到团队大小的度量问题，那么团队多少人算大，多少人算小呢。有一个两个Pizza的论断。一个小团队点的外卖应该两个Pizza就够了。

微服务的自治性。确保微服务的隔离性：

1.服务之间只通过网络通信。这样能够使得服务可以独立修改，不会因为修改一个服务内部的实现而导致另外的服务不可用或跟着修改（这里指的是修改内部实现，而不是对外部接口的修改）。

2.服务对外提供的API形式保持技术独立性。这是为了不限制其它服务的实现技术，如编程语言，操作系统等，无需与服务提供方的实现保持一致。

微服务带来的益处：

1.技术异构性。根据微服务所对应的业务选择技术，而不必受限于其依赖的服务所实现的技术。容易保持系统中的异构架构。而且由于架构的异构性，并且服务的修改或重构对其它服务没有影响（在保证服务接口不变的情况下），因此可以对其中的一个或部分服务尝试新技术。

当然，异构架构和新技术的尝试都是有限制的，无节制的过多的使用太多不同的技术会带来更多的复杂性。过多的操作系统种类，过多的语言，过多的运行环境与应用框架等等。

2.弹性。这里的弹性指的是单点故障不会导致整个系统故障。单块系统中某组件故障后，很容易导致级联故障，从而使得系统不可用，解决方法可以通过多个机器节点上同时部署相同实例避免单点故障。而微服务本身就是通过网络隔离，不会像在一个机器中的单块系统那样产生连锁反应。由于微服务在每次进行外部调用时，应该会自然地考虑到外部服务不可用的情况处理。而单块系统中API调用时则很难对每次调用考虑周全，并且经常会引发级联故障。

3.扩展。微服务对单块系统进行了切分，使得可以对相应的瓶颈微服务进行多实例部署来扩展，而不必整个单块系统扩展。对整个单块系统的扩展显然要比只对其中的一部分进行扩展要消耗更多的机器资源，因为好钢并不是全部用在刀刃上。

4.简化部署。由于微服务功能单一，隔离性好，更改后部署如果出现问题很容易定位，也容易快速回滚。单块系统中牵一发动全身，害怕局部改动对全局产生重大负面影响，因此部署需要做足充分的准备工作。

5.与组织结构相匹配。分布式的大团队由于沟通、组织等问题，没有小团队的效率高。因此微服务的设计理念和小团队的理念很匹配，可以提高生产率和质量。

6.可组合性。单块系统由于内部耦合比微服务之间耦合紧密的多，因此想通过组合内部功能完成其它系统功能，比微服务的组合性要差很多。

7.对可替代性的优化。单块系统想要重写以改进性能，比微服务改写某个服务提升性能要复杂困难许多。

面向服务架构（SOA，Service-Oriented Architecture）是一种方法，在现实中实施并不好。面临通信协议选择，服务粒度确定，第三方中间件选择等问题。可以把微服务架构认为是SOA的一种特定方法。

其它分解技术还有共享库和模块，

1.共享库：要使用共享库必须得选择相同的实现语言或者至少在同一个平台，丧失了技术独立性。如果是静态库，则每次静态库发生变化，使用的软件又需要重新编译和部署，影响关联颇大。而且，由于进程内调用API，使得级联故障发生的可能性大增。当然，共享库即使在微服务中，也是有生存空间的。例如，很多不同领域的业务都使用该功能，就可以将该功能作为共享库给各个微服务使用。

2.模块：一些语言提供了模块分解技术如Erlang，它的模块化能力非常牛，支持对模块进行停止、重启或热升级等。但你只能使用Erlang，并且也存在故障级联的问题。语言之外就是OSGI（Open Source Gateway Initiative）了，它过于强调模块生命周期管理了，而生命周期管理在实际项目中用处并不大。而且，一个进程内也导致模块耦合度太高。OSGI带来的复杂度远大于带来的好处。

微服务不是银弹，它天然是分布式系统架构，因此会伴随着分布式系统的复杂性。需要考虑部署、测试、监控、扩展、保持弹性、分布式事务、CAP问题等等。