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

这是我参与8月更文挑战的第4天，活动详情查看：8月更文挑战”

一、微服务架构介绍

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

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

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

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

二、模式描述

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

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

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

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

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

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

通常会从两个模式中演化：

• 一种就是一开始就是总体的应用，全部的模块都是紧耦合的；

• 另一种是面向服务的架构模式(SOA，service-oriented architecture pattern)。SOA 不是很差，可是太昂贵了，很差理解和实现。

三、模式拓扑

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

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

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

四、架构考量

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

微服务模式优劣分析：

• 整体灵活性：高

• 发布易用性：高

• 可测试性：高

• 性能：低

• 规模扩展性：高

• 开发容易度：高

五、总结

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

做者：架构精进之路，十年研发风雨路，大厂架构师，CSDN 博客专家，专一架构技术沉淀学习及分享，职业与认知升级，坚持分享接地气儿的干货文章，期待与你一块儿成长。

关注「架构精进之路」同名公众号并回复“01”，送你一份程序员成长进阶大礼包，另外面试宝典、大量技术电子书免费领取。

Thanks for reading!