下载掌阅APP，畅读海量书库
立即打开
微服务 （microservice）是基于业务领域建模的、可独立发布的服务。它会把业务内聚的功能封装起来，并通过网络供其他服务访问。将这样的服务进行组合就可以构建出更复杂的系统。例如，3个不同的微服务分别负责库存、订单管理、物流，这三者组合便能构成一个完整的电子商务系统。微服务致力于解决架构中可能遇到的各种问题，是可供选择的架构设计方式之一。
微服务是一种面向服务的架构，尤其看重如何划分服务边界，且强调独立部署。此外，微服务与特定技术（如开发语言、开发框架）无关，这也是它的优势之一。
从外部看，单个微服务被看作一个黑盒。它通过适配协议在一个或多个网络端点（例如，消息队列或 REST 接口，如图1-1所示）提供业务功能。无论是其他微服务还是其他类型服务的消费者，都可以通过这些网络端点访问相关业务功能，而需要隐藏的内部实现细节（例如，服务所使用的技术或数据存储方式）可以对外界完全不可见。因为微服务架构在大多数情况下避免采用共享数据库，而是尽可能封装自己的数据库。
图1-1：微服务通过 REST 接口和消息主题开放其功能
微服务提倡 信息隐藏 [1] 。信息隐藏是指最大程度地隐藏组件内的信息，对外部的接口尽可能减少信息的暴露。这样可以清楚地将容易变更的（内部实现）部分和较难变更的（外部集成）部分分离开。只要对外暴露的接口保持向后兼容，对外部隐藏的内部实现就可以自由变更。微服务能够独立演进和按需发布的关键在于，微服务边界内（图1-1）的变更不应该影响上游消费者，能够确保功能可独立发布。拥有清晰和稳定的服务边界，不随内部实现的变更而变更的服务边界能够实现系统的高内聚低耦合。
论及隐藏内部的实现细节，就不得不提到
六边形架构理论
（由 Alistair Cockburn 首次提出）
。六边形架构理论描述了保持内部实现和外部接口分离的重要性，其理念是考虑到不同的外部系统可以通过不同类型的接口与同一功能进行交互，将外部（如第三方服务、数据库、外部应用等）的不可控变化隔离开。本书将微服务绘制成六边形，一方面可以将它们与“普通”服务区分开，另一方面也是向六边形架构理论致敬。
SOA （service-oriented architecture，面向服务的架构）是一种设计方法，该方法通过多个服务的协作提供一系列特定的功能。（这里的服务通常部署在完全独立的进程中。）这些服务之间的通信是通过网络调用而不是进程边界内的方法调用进行的。
SOA 为了应对大型单体应用系统的挑战而出现。这种方法旨在提高软件的可复用性，例如，两个甚至更多的终端用户应用程序可使用同一个后端服务。SOA 致力于使软件的维护和重写变得更容易，因为理论上，只要服务对外暴露接口的语义变化不大，我们就可以在用户觉察不到的情况下将服务进行更新或者替换。
SOA 的核心理念非常好。问题是尽管实践诸多，但在如何高效实施 SOA 上大家存在分歧。在我看来，业内大部分人未能从整体上充分思考这个问题，也没有为该领域的不同供应商的现有方案提供令人信服的替代方案。
实际上，SOA 的许多问题与通信协议（如 SOAP）、供应商中间件、缺乏服务颗粒度的指导，或在做系统边界划分时接受了错误指导相关。有些人可能会说，是供应商参与（有时是推动）了 SOA 运动，并将其作为销售更多产品的方式，而这些雷同的产品最终破坏了 SOA 的目标。
我见过很多 SOA 的例子，这些团队努力尝试将服务变得更小，但他们还是将一切耦合在了数据库中，随之而来的就是只能将所有服务部署在一起。是的，这确实是面向服务，但不是微服务。
微服务脱胎于实际应用，它是基于我们对系统和架构更好的理解以更好地实现 SOA。就像认为 XP（extreme programming，极限编程）或 Scrum 是敏捷开发的一种特定方法一样，你也可以将微服务作为实现 SOA 的一种特定方法。
[1] 信息隐藏的概念由 David Parnas 首次提出，参见其在 Information Processing: Proceedings of the IFIP Congress 1971 中发表的文章“Information Distribution Aspects of Design Methodology”。