1.3 微服务的特点

简单地说，微服务架构是一种以一些微服务来替代开发单个的大而全的应用的方法，每一个小服务都运行在自己的进程里，并以轻量级的机制（通常是HTTP RESTful API）来通信。微服务强调“小快灵”，任何一个相对独立的功能服务不再是一个模块，而是一个独立的服务。

举个例子，就是将以前的大兵团全功能的部队拆分成一个个专业化的小分队，各司其职，各自为战，彼此之间用清晰的接口通信。

类似于真实世界，以前推崇金字塔结构：从上到下，分层管理，都在一个大的系统（进程）里以内部事件或函数调用的方法进行分工协作。而当前更倾向于扁平化管理，分成若干个独立运作的事业部或小组，各自为战，却又以API/RPC的方式紧密合作，为一个或一些用户提供所需的产品和服务。

有一利就有一弊，以往一个程序有几十个组件，现在可能就变成了几十个微服务。那么这么多微服务该如何管理呢？

类似于真实世界，若干个小分队联合作战得由总参谋部协调，彼此之间职责明确、分工协作。在软件世界中就可以前端应用及API gateway来调用和协调所依赖的微服务，再加上服务注册（service registry）、服务发现（service discovery）等服务治理功能，依靠强大的度量和监控将多个微服务整合在一起。

就如《人月神话》的作者布鲁克斯所提到的“没有银弹”，从来就没有包治百病的灵丹妙药，如果有人声称有，那他一定是个骗子。微服务的问题也不少，小分队多了，沟通成本就增加了，性能也可能会有所下降。

1.3.1 微服务架构的特点

Martin Fowler在他的文章中总结了微服务的特点。

（1）围绕业务功能进行组织（organized around business capability）

不再是以前的纵向切分，而改为按业务功能横向划分，一个微服务最好由一个小团队针对一个业务单元来构建。

（2）做产品而非做项目（product not project）

不再是做完一个个项目，交付后就完工了，而是做产品，从设计编码到产品运维，做到全过程掌控和负责，即自己构建，自己运维（you build it, you run it）。

（3）智能终端加简单通道（smart endpoints and dumb pipe）

使用基于资源的API，将大量逻辑放在客户端，而服务器端则着重于提供资源，推荐基于Web而不是在Web之后做复杂逻辑（be of the Web, not behind the Web）。

（4）去中心化管理（decentralized governance）

自行其是，自我管理，不必在局限在一个系统里，不必围绕着一个中心。

（5）去中心化数据管理（decentralized data management）

只管理和维护自己的数据，相互之间互不直接访问彼此的数据，只通过API来存取数据。

（6）基础设施自动化（infrastructure automation）

每个微服务应该关注于自己的业务功能实现，基础设施应该尽量自动化——构建自动化、测试自动化、部署自动化、监控自动化。

（7）为应对失败而设计（design for failure）

设计之初就要考虑高可靠性（high reliability）和灾难恢复（disaster recover），并考虑如何着手进行错误监测和错误诊断。

（8）演进式设计（evolutionary design）

没有完美的架构，唯一不变的是变化。要善于应对变化，容易改变其设计和实现，因为其小，故而易变。

以上即为微服务的主要特点，除此之外，其他的一些非特征化的特点不再赘述。

1.3.2 微服务架构的特征

一个微服务的架构应该具有以下特征：

❑ 容易被替换和升级。比如以前用Ruby快速开发的原型可以由用Java实现的微服务代替，因为服务接口没变，所以也没有什么影响。

❑ 职责独立完整。按功能单元组织服务，职责最好相对独立和完整，以避免对其他服务有过多的依赖和交互。

❑ 可选择最适合自己的技术方案。服务性质不同会影响技术选型，比如账户的注册和登录完全可以由Ruby on Rails、Python Django这些脚本框架来实现。但是，对于音/视频流的编解码和处理，最好用C/C++甚至汇编语言来写。其他的诸如数据库的选型、ORM或MVC框架的选择，都可以随机应变，按照业务和技术的具体需求，根据团队的技术栈和人员现状选择最适合的方案。

❑ 架构由层次化转向扁平化。服务内部可以进行适当的分层，服务之间尽量扁平化，不要引入过多的层次。

1.3.3 微服务架构的风格

微服务可以采用多种风格，但是一个“生态系统”内存最好遵从统一的风格和要求。微服务基本上都具有以下风格：

❑ 短小精悍、独立自治：只做一个业务并专注地做好它。

❑ 自动化部署和测试：相比大而全的单个服务，微服务会有更多的进程，更多的服务接口，更多不同的配置，如果不能将部署和测试自动化，微服务所带来的好处将会大大逊色。

❑ 尽量减少运维的负担：微服务的增多可能会导致运维成本增加，监控和诊断故障也可能更困难，所以要未雨绸缪，在一开始的设计阶段，就要充分考虑如何及时地发现问题和解决问题。

❑ 拥抱失效与故障：微服务的高可靠性设计和防错性设计是与生俱来的，分布在不同的机器、地域上的服务所用到的硬件和网络等随时可能出问题，而这些问题要对服务质量没有任何影响。

❑ 每个服务都是灵活易变、可伸缩、可扩展、可组合的：微服务为应对变化提供了更多的可能，就像乐高积木，可以随意增减组合，拼出不同的产品。

1.3.4 微服务的分类

微服务的分类方法有很多，可以参考表1-2进行多个维度的划分。

1.3.5 多小的服务才是微服务

微服务是比较小的服务，到底可以有多小，我们团队的前CTO Jonathan Rosenberg就曾经提出过一个“两周原则”：一个新的服务如果可以在两周内上线，那么就可称它是一个微服务。这个要求有点高，需要满足3个前提：

❑ 有一套完整的微服务框架。

❑ 有一套成熟的构建与部署流水线。

❑ 有一个稳定的PaaS云平台。