作为单体应用（monolithic application）和面向服务架构模式（service-oriented architectures，SOA）的替代方案，微服务架构模式（microservices architecture pattern）在业界迅速普及。本文介绍微服务架构的核心概念，以及选择该架构需要考虑的取舍问题。

模式介绍

尽管由于业务场景不同，微服务架构的拓扑结构和实现方式都不同，但是一些核心概念是相同的。在这些概念中，首先要说明的就是独立部署单元（separately deployed units）。如下图说是，微服务架构中，每个服务组件都是作为独立单元单独部署。独立部署单元之间彼此解耦，可以方便集成持续部署流水线（continuous deployment pipeline）,并且扩展性也很高。

在这些概念中，最重要的就是服务组件（service component）了。不像面向服务架构中的服务，服务组件的颗粒度可以非常灵活。服务组件可以仅仅是实现了一个具体功能的一到两个模块，也可以是应用中比较独立的一整块业务。因此，服务组件的颗粒度设计是整个微服务架构模式中最具挑战性的部分。

微服务架构是分布式的，架构中的所有组成部分都是彼此独立、解耦的，彼此间需要通过远程访问协议（remote access protocol）来通信，比如 JMS、AMQP、REST、SOAP、RMI 等。

微服务架构模式是由解决其他架构模式的问题而不断演化而来，主要来自于两方面：采用分层架构模式开发的单体应用和采用面向服务架构模式开发的分布式应用。

采用分层架构模式开发的单体应用，通常因为包含了很多彼此强耦合的单元而难以拆分，从而给变更、测试和持续部署带来的很多麻烦。某一个小问题可能导致整个应用宕机。微服务架构模式将应用拆分成很多个可以独立部署的单元（服务组件），从而可以方便的进行变更、测试和支持部署。

面向服务的架构模式（SOA）非常强大，并提供了无与伦比的抽象级别、异构连接、服务编排等能力，但是该模式太复杂，难以理解和实施，而且对于大多数应用来说通常是矫枉过正的。微服务架构模式通过简化服务的概念、消除编排需求以及简化对服务组件的连接和访问来解决这种复杂性。

拓扑结构

微服务有三种主要的拓扑结构：基于 API REST （API REST-based topology）的拓扑、基于应用 REST 的拓扑（application REST-based topology）和基于集中式消息传递的拓扑（centralized messaging topology）。

基于 API REST 的拓扑

如上图所示，基于 API REST 的拓扑包含很多细粒度的服务组件，每个服务组件仅仅包含一到两个模块，实现了与其他服务彼此独立的某一项具体的业务动作。这些服务组件通常由一个独立部署的基于 REST 的 Web API 来访问。

这种拓扑结构通常被用于那些提供单一功能的 RESTful web 服务中，这些 web 服务在 Google、Amazon 等云服务厂商中非常常见。

基于应用 REST 的拓扑

上图展示了基于应用 REST 的拓扑结构。与基于 API REST 的拓扑结构不同的是，通常用户请求不是简单的访问一个 Web API 就可以实现，而是需要通过一个具体的 UI 层。

基于应用 REST 的拓扑结构中的服务组件，也比基于 API REST 拓扑中的服务组件更大，颗粒度更粗，通常包含整个应用中某一块业务功能。

基于应用 REST 的拓扑结构通常被用于规模较小、或者中等规模的应用中。

基于集中式消息传递的拓扑

上图展示了基于集中式消息传递的拓扑结构。与基于应用 REST 的拓扑结构类似，但是基于集中式消息传递的拓扑结构不再使用 REST 来访问服务，而是通过一些轻量级的集中式消息代理（比如 ActiveMQ、HornetQ 等）来访问服务。

集中式消息传递拓扑通常被用于较大的业务应用，或者那些需要对用户 UI 和服务组件之间的数据传输进行复杂控制的应用中。与前面讨论的拓扑结构相比，这种拓扑结构的好处是有先进的排队机制、异步消息传递、监控、错误处理以及更好的整体负载平衡和可扩展性。

避免服务间的依赖和编排

微服务架构模式的一大挑战是服务颗粒度的设计。颗粒度太粗无法享受到快速变更、 持续部署、低耦合、高扩展性等优势，颗粒度太小有不得不引起服务之间的编排需求，从而不得不面对成面向服务架构的问题。

如果发现我们不得不引入服务编排时，说明服务组件的颗粒度太细了。类似的，如果发现我们需要建立服务组件间的通信，而这些通信仅仅是为了满足简单的用户请求，那么说明服务组件的颗粒度太细了，或者说当前的业务场景不适合微服务架构模式。

有时候服务组件之间有一些公共的功能需要共享（比如工具函数等），在微服务架构模式中，我们建议允许一定的代码重复。这样可以保持服务之间相互独立，避免产生依赖，从而保证变更、持续部署方便。

其他说明

微服务架构解决了单体应用和面向服务架构的应用的很多共性问题。大的应用被拆分成多个小的、可独立部署的服务。应用的健壮性、可扩展性都得到了极大的提高，同时可以更方便的与持续部署系统集成。

由于变更产生在相互独立的服务中，单个服务的变更不影响其他服务，我们可以在生产环境做实时部署，而不需要在周末或非工作时间做发布。同时，我们可以启用多个服务实例，实现滚动发布，做到用户无感。

微服务架构是分布式的，因此有着与事件驱动的架构模式相同的问题。比如协议设计、服务的管理、系统可用性、访问控制等问题。

小结

由于整个应用被划分成多个独立部署单元，彼此之间相互独立，因此整个应用可以快速的响应变化。在测试、快速部署等方面优势明显，同时还具备了很高的可扩展性。也正是由于应用被划分成了多个独立单元，开发人员心智负担也更小，开发也更加便利了。

与大部分的分布式系统相同，尽管应用本身可以实现不错的性能，但是微服务架构模式并不是为了解决性能问题而设计的，在性能方面会相对弱势一些。

关注微信公众号，获取最新推送~

加微信，深入交流~