分布式系统实战：什么是微服务架构？微服务架构与SOA架构的区别

微服务架构

自2014年业界提出“微服务（Microservices）”的概念以来，微服务架构就不断演进，并且日趋火爆。越来越多的企业拥抱微服务，期望通过微服务的架构来解决大型项目的管理与运维。

那么什么是微服务？微服务架构与传统的SOA架构有什么区别？何时应该采用微服务架构？如何构建微服务？本章就针对上述提到的问题，来简单介绍下微服务架构。

什么是微服务架构

微服务架构（Microservices Architecture，MSA）的出现并非偶然，而是与这个时代的软件思想、技术工具的发展有着密切的联系。比如，将业务功能服务化，是SOA的延续；RESTful等架构的兴起，让我们可以考虑更多轻量化的通信机制；领域驱动设计指导我们如何分析并模型化复杂的业务；敏捷方法论帮助我们拥抱变化，快速反应；持续集成和持续交付（CI/CD）促使我们构建更快、更可靠、更频繁的软件部署和交付能力；虚拟化和容器技术的发展，使我们简化了部署环境的创建、安装；DevOps文化的流行以及全栈自治团队的出现，使得小团队更加全功能化。这些都是推动微服务架构诞生和发展的重要因素。

实际上，业界对于微服务本身并没有一个严格的定义。James Lewis和Martin Fowler对微服务架构做了如下定义。

简言之，微服务架构风格就像是把小的服务开发成单一应用的形式，运行在其自己的进程中，并采用轻量级的机制进行通信（一般是HTTP资源API）。这些服务都是围绕业务能力来构建的，通过全自动部署工具来实现独立部署。这些服务可以使用不同的编程语言和不同的数据存储技术，并保持最小化集中管理。

MSA包含以下特征。

·组件以服务形式来提供。正如其名，微服务也是面向服务的。

·围绕业务功能进行组织。微服务更倾向围绕业务功能对服务结构进行划分、拆解。这样的服务，是针对业务领域有着相关完整实现的软件，它包含使用接口、持久存储以及对应的交互。因此团队应该是跨职能的，包含完整的开发技术——用户体验、数据库以及项目管理。

·产品不是项目。传统的开发模式致力于提供一些被认为是完整的软件。一旦开发完成，软件将移交给维护或者实施部门，然后开发组就可以解散了。而微服务要求开发团队对软件产品的整个生命周期负责。

这要求开发者每天都关注软件产品的运行情况，并与用户联系更紧密，同时承担一些售后支持。越小的服务粒度越容易促进用户与服务提供商之间的关系。

·强化终端及弱化通道。微服务的应用致力于松耦合和高内聚，它们更喜欢简单的REST风格，而不是复杂的协议（如WS或者BPEL或者集中式框架），或者采用轻量级消息总线（如RabbitMQ或ZeroMQ等）来发布消息。

·分散治理。这是与传统的集中式管理有很大区别的地方。微服务把整体式框架中的组件拆分成不同的服务，在构建它们时将会有更多的选择。

·分散数据管理。当整体式的应用使用单一逻辑数据库对数据持久化时，企业通常选择在应用的范围内使用一个数据库。微服务让每个服务管理自己的数据库：无论是相同数据库的不同实例，或者是不同的数据库系统。

·基础设施自动化。云计算，特别是AWS的发展，降低了构建、发布、运维微服务的复杂性。微服务的团队更加依赖于基础设施的自动化，毕竟发布工作相当无趣。近些年开始火爆的容器技术，诸如Docker也是一个不错的选择（有关容器技术以及Docker的内容在后面章节会涉及）。