软件架构模式之微服务架构

1、微服务架构介绍

微服务架构（Microservice Architecture）是一种架构概念，旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。你可以将其看作是在架构层次而非获取服务的类上应用很多SOLID原则。微服务架构是个很有趣的概念，它的主要作用是将功能分解到离散的各个服务当中，从而降低系统的耦合性，并提供更加灵活的服务支持。

概念：把一个大型的单个应用程序和服务拆分为数个甚至数十个的支持微服务，它可扩展单个组件而不是整个的应用程序堆栈，从而满足服务等级协议。

定义：围绕业务领域组件来创建应用，这些应用可独立地进行开发、管理和迭代。在分散的组件中使用云架构和平台式部署、管理和服务功能，使产品交付变得更加简单。

本质：用一些功能比较明确、业务比较精练的服务去解决更大、更实际的问题。

2、模式描述

不管你使用何种实现风格和拓扑，有几个通用的核心概念应用在这种架构模式上。首先是分隔发布单元（separately deployed units）。

如图所示，每一个微内核的组件都被分隔成一个独立的单元。

微服务包含服务组件（service component）。不要考虑微内核的单个服务，而是最好考虑服务组件，从粒度上讲它可以是单一的模块或者一个一个大的应用程序，代表单一功能（提供天气预报或者图片存储）。

正确设计服务组件的粒度是一个很大的挑战。

另一个关键概念是微内核是分布式的。这意味着服务组件可能是远程方法（通过JMS, AMQP, REST, SOAP, RMI......等等）。分布式意味着这种模式可以建立大规模的应用。

另一个值得兴奋的特性是它可以从其它有问题的架构模式中演化出来，而不是直接创建出来等待问题发生。当你遇到一些无法解决的问题，特别是互联网企业的规模扩大时，是很好的引入微服务架构的时机。

一般会从两个模式中演化：

一种就是一开始就是整体的应用，所有的模块都是紧耦合的；
另外一种是面向服务的架构模式(SOA，service-oriented architecture pattern)。SOA不是不好，但是太昂贵了，不好理解和实现。

3、模式拓扑

有很多实现微服务的方式。最通用最流行的三个方式是: API REST-based, applicaiton REST-based 和中心化的消息。API REST-based 适合网站提供小规模的，自包含的服务。很多互联网网站都提供这样的服务，比如OAuth2服务。

application REST-based不同于上面的架构，客户端看到的是web界面或者富客户端程序，而不是调用API。UI层独立发布，可以访问服务组件。

中心消息模式，它类似前面的模式，但是使用一个轻量级的消息broker取代RESTful的服务调用。这个轻量级的broker不会执行服务的编排，传输和路由，这和SOA不同，不要把它看作SOA的简化版。

4、架构考量

微服务架构解决了无架构的整体编码的应用的问题以及SOA的问题。同时它还可以提供实时的产品发布。它是一个分布式架构，也会有上面分布式的问题。

微服务模式优劣分析：

总体灵活性：高
发布易用性：高
可测试性：高
性能：低
规模扩展性：高
开发容易度：高

5、总结

微服务作为单一整体的程序和面向服务架构的替代者，微服务架构模式在工业界很快赢得了地位。这种模式还在进化之中，在业界对于它的特性和实现还有些困惑。对于我们的思考，更多的是思维上的转变。对于微服务架构：技术上不是问题，意识比工具重要。