3.1.3 微服务的本质特征
微服务是一种细粒度的分布式架构，从整体架构的角度来看，微服务的本质特征主要体现在如下几个方面。
1. 将服务作为插件
传统的实现组件的方式是隔离独立的部分或抽取公用的部分构建共享库，从而实现解耦合复用的效果。基本上，所有的语言都支持将整个代码库分解成多个库，这是一种非常标准的分解技术。不同的团队和服务可以通过库的形式共享功能。团队可以围绕库来进行组织，而库本身可以被重用。但这种方式存在一些缺点：首先，其无法选择异构的技术，一般来讲，这些库只能在同一种语言中，或者至少在同一个平台上使用；其次，系统某一部分会失去独立扩展的能力；再次，每次当库有更新的时候，都需要重新部署整个进程，以至于无法独立地部署变更；更重要的是，该方式缺乏一个比较明显的接口来建立架构的安全性保护措施，从而无法确保系统的弹性。
而微服务架构的一个显著优势是，其能以松散的服务方式，采用集成的技术手段构建可独立部署的模块化应用。其服务粒度小，而每个服务是对单一职责的业务能力的封装，使得其可以选择异构的技术；微服务通过使用较小的多个服务，就可以只对需要扩展的服务进行扩展；每个服务能够被独立部署并运行在一个进程内。这种运行和部署方式能够赋予系统灵活的代码组织方式和发布节奏，使得快速交付和应对变化成为可能；服务之间均通过网络API的调用进行通信，从而加大了服务之间的隔离性，避免紧耦合。
2. 利用限界上下文形成组合边界
在微服务中，引入了一个名词——“限界上下文”，该词是由《领域驱动设计》的作者Eric Evans提出的。他认为任何一个给定的领域都包含多个限界上下文，每个限界上下文所包含的内容分为两部分，一部分不需要与外界通信，另一部分则需要，这就像细胞膜一样，定义了什么在细胞里，什么在细胞外，并且确定了什么物质可以通过细胞膜。
每个限界上下文都有明确的接口，该接口决定了其会暴露哪些模型给其他上下文。当要从一个限界上下文中获取信息，或者向其发起请求时，需要使用模型和显式边界来进行通信。在微服务中，业务采用围绕限界上下文的方式来定义可能的领域边界，这比围绕技术概念来定义更加稳定。例如，在一个仓储管理的业务中，财务部门和仓库就可以是两个独立的限界上下文。他们都有明确的对外接口，也都有只需要自己知道的一些细节。财务部门不需要知道仓库的内部细节，但需要知道库存水平等相关信息以便于更新账户。那么，对仓库模型来说，存在内部和外部两种表示方式，而库存水平则成为仓库模型和财务模型两个上下文之间的共享模型。共享特定的模型，而不是共享内部细节，就可以避免潜在的紧耦合风险，可将相关性较高的业务功能放在同一边界内部，从而实现高内聚。总体来说，这些限界上下文可以很好地形成组合边界，使得微服务框架向高内聚、低耦合迈进了一步。
3. 基础设施自动化
微服务架构将应用程序本身分成多个小的服务，每个服务都是一个独立的部署单元。在传统方法中，只需要部署一次就能上线的单体架构应用，采用微服务架构后，将需要分别对每个部分进行部署，从而产生很多管理开销，这也意味着部署与运维的成本会随着服务的增多呈指数级增长。如果将主机控制、服务部署等工作自动化，那么工作量肯定就不会随着主机数量的增加而线性增长。但即使控制了主机的数量，还是会有很多服务，这也意味着有更多的部署要处理、更多的服务要监控、更多的日志要收集，所以自动化是关键。
因此，微服务的实践将促使企业或者团队不断寻找更高效的方式来完成基础设施的自动化及DevOps（一组过程、方法与系统的统称，用于促进开发、技术运营和质量保障部门之间的沟通、协作与整合）运维能力的提升。例如，创建于2007年的在线时尚品零售商Gilt，在2009年发现自己的单块Rails应用开始变得难以扩展，于是公司决定开始把系统分解成微服务。自动化，尤其是给开发人员使用的自动化工具，成为Gilt能够大量采用微服务的关键驱动力。一年后，Gilt大约有10个微服务上线；2012年，微服务数量超过100个；2014年，微服务数量超过450个。在Gilt，平均每个开发人员拥有3个微服务。
4. 独立部署
微服务涉及一个名词——“持续集成”（CI）。持续集成能够保证将新提交的代码与已有的代码进行集成，从而让所有人保持同步。持续集成服务器可以检测代码是否已提交并签出，然后检测代码是否通过编译及测试能否通过，其经常会生成一些构建物以供后续验证使用。在理想情况下，这些构建物只生成一次，随后在本次提交所对应的所有部署环境中使用。持续集成有很多好处，通过持续集成，能够在某种程度上得到关于代码质量的快速反馈，也能够从已部署的构建物回溯到相应的代码区域。
从最简单的部署开始，将服务、持续集成构建及源代码三者放在一起产生一个构建，如图3-1所示。该种模式从表面上看比其他方法要简单得多，但却存在很大弊端。当修改图3-1中用户服务中的一行代码时，所有其他服务都需要进行验证和构建，从而花费大量不必要的时间，这会影响持续集成的周期，也会影响单个修改的上线速度。
图3-1 由一个CI构建且共享一个代码库的微服务部署
而微服务促使人员将持续集成映射到每个微服务器上，从而使其能够实现独立部署。其让每个服务都拥有一个自己的持续集成，这样就可以使微服务在部署到生产环境之前做一个快速验证，如图3-2所示。这里的每个微服务都有自己的代码库，分别与相应的持续集成绑定，当对代码库进行修改时，可以只运行相关的构建及其中的测试，从而达到独立部署的目的。
图3-2 由一个源代码库和CI构建的微服务部署
5. 相互隔离
微服务架构是根据产品的业务功能模块来进行服务种类划分的，其分为两个部分，一是“垂直划分”，二是“水平划分”。“垂直划分”是指按照业务功能进行划分；“水平划分”是指在代码层面进行划分。通过“垂直划分”和“水平划分”，使得微服务在不同业务级别和不同的数据存储介质中完成服务隔离。这会保证在某个服务出现故障时，不会影响其他服务的正常运行。也就是说，服务之间没有任何干扰，进程之间是完全隔离的。
6. 去中心化
单个应用的一个主要缺点是将所有的事物集中在单个（或少量）的软件组件和数据库中。这样做多半会产生超大的数据存储及对工作流的集中式控制，而该数据存储是需要根据公司业务成长的需求不断复制与扩容的。微服务通过将软件模块和数据去中心化，或者说将原来“单体”模式进化为更小、更易于改变的模式，使这些小模块部署到网络上，从而避免产生超大的数据存储及对工作流的集中式控制现象。
微服务采用康威定律，将决策权下放到底层，让工作人员更加自由和自治，让团队与组织更加保持一致，让他们成为其构建的业务领域的专家，从而正确引导微服务组织的去中心化。其中，康威定律是指“任何组织在设计一套系统（广义概念上的系统）时，所交付的设计方案在结构上都与该组织的沟通结构保持一致”。例如，Netfix是一个在创新领域去中心化的示范企业，他们采用的“赋给员工决策自己工作时间的权力”的策略将以往需要封闭控制的决策实现了去中心化。
7. 关注产品而非项目
微服务提倡产品模式构建，一个团队负责整个服务的生命周期。这种模式可以较好地避免项目模式中出现的团队成员缺乏主人翁精神、难以制定有效的奖惩机制、团队成员缺乏产品成就感等问题。微服务还提倡针对不同的业务特征选择合适的技术方案，有针对性地解决具体的业务问题。对应单体架构系统，初始的技术选型严重限制其将来采用不同语言或框架的能力。微服务架构使开发者更容易在系统上尝试新的技术或解决方案。
8. 业务数据独立
传统的数据库大多是关系型数据库，存储的数据以结构化信息为主。但随着互联网的快速发展，数据的结构并不具有确定性，或者说结构发生变化的频率非常高，如何有效维护业务数据成为亟须解决的问题。微服务架构提倡服务自主管理相关业务数据，并采用共享数据库的方式，使数据库成为一个很大的共享API，想要获取其他信息的服务可以访问其他服务的数据库API进行获取。这样做不仅能够随着业务的发展，提供业务数据接口集成（而不是以数据库的方式和其他服务集成），还能够随着业务的发展，选择更合适的工具管理或迁移业务数据。