【架构】微服务实战：从发布到架构——上篇

“微服务”是当前软件架构领域很是热门的词汇，能找到不少关于微服务的定义、准则，以及如何从微服务中获益的文章，在企业的实践中去应用“微服务”的资源却不多。本篇文章中，会介绍微服务架构（Microservices Architecture）的基础概念，以及如何在实践中具体应用。android

单体架构(Monolithic Architecture )web

企业级的应用通常都会面临各类各样的业务需求，而常见的方式是把大量功能堆积到同一个单体架构中去。好比：常见的ERP、CRM等系统都以单体架构的方式运行，同时因为提供了大量的业务功能，随着功能的升级，整个研发、发布、定位问题，扩展，升级这样一个“怪物”系统会变得愈来愈困难。数据库

单体架构的初期效率很高，应用会随着时间推移逐渐变大。在每次的迭代中，开发团队都会面对新功能，而后开发许多新代码，随着时间推移，这个简单的应用会变成了一个巨大的怪物。设计模式

图1：单体架构安全

大部分企业经过SOA来解决上述问题，SOA的思路是把应用中相近的功能聚合到一块儿，以服务的形式提供出去。所以基于SOA架构的应用能够理解为一批服务的组合。SOA带来的问题是，引入了大量的服务、消息格式定义和规范。服务器

多数状况下，SOA的服务直接相互独立，可是部署在同一个运行环境中（相似于一个Tomcat实例下，运行了不少web应用）。和单体架构相似，随着业务功能的增多SOA的服务会变得愈来愈复杂，本质上看没有由于使用SOA而变的更好。图1，是一个包含多种服务的在线零售网站，全部的服务部署在一个运行环境中，是一个典型的单体架构。微信

单体架构的应用通常有如下特色：架构

设计、开发、部署为一个单独的单元。并发
会变得愈来愈复杂，最后致使维护、升级、新增功能变得异常困难app
很难以敏捷研发模式进行开发和发布
部分更新，都须要从新部署整个应用
水平扩展：必须以应用为单位进行扩展，在资源需求有冲突时扩展变得比较困难（部分服务须要更多的计算资源，部分须要更多内存资源）
可用性：一个服务的不稳定会致使整个应用出问题
创新困难：很难引入新的技术和框架，全部的功能都构建在同质的框架之上

微服务架构（Microservices Architecture）

微服务架构的核心思想是，一个应用是由多个小的、相互独立的、微服务组成，这些服务运行在本身的进程中，开发和发布都没有依赖。

多数人对于微服务的定义是，把原本运行在单体架构中的服务拆分红相互独立的服务，并运行在各自的进程中。在我看来，不只如此。最关键的地方在于，不一样的服务能依据不一样的业务需求，构建的不一样的技术架构之上，而且聚焦在有限的业务功能之上。

所以，在线零售网站能够用图2的微服务架构来简单归纳。基于业务需求，须要增长一个帐户服务微服务，所以构建微服务毫不是在单体架构中把服务拆分开这么简单。

图2：微服务架构

微服务设计：规模、范围、业务功能

你可能从零开始用微服务来构建应用，也可能重构现有系统，肯定微服务的规模，范围和功能都特别重要。让咱们讨论一些有关微服务设计的关键问题和对它的误解：

“微”很容易被误解：不少开发者会倾向于把服务往尽可能小的颗粒度去作
在SOA方式下，服务都仍是以单体架构在运行，用于支持不一样的功能。若是依旧采用SAO相似的服务，仅仅是名义上叫作微服务，并不能带来任何微服务的优点。

那咱们在微服务中应该怎样设计呢。如下是微服务的设计指南：

职责单一原则（Single Responsibility Principle）：把某一个微服务的功能聚焦在特定业务或者有限的范围内会有助于敏捷开发和服务的发布。
设计阶段就须要把业务范围进行界定。
须要关心微服务的业务范围，而不是服务的数量和规模尽可能小。数量和规模须要依照业务功能而定。
于SOA不一样，某个微服务的功能、操做和消息协议尽可能简单。
项目初期把服务的范围制定相对宽泛，随着深刻，进一步重构服务，细分微服务是个很好的作法。

微服务消息

在单体架构中，不一样功能之间通讯经过方法调用，或者跨语言通讯。SOA下降了这种语言直接的耦合度，采用基于SOAP协议的web服务。这种web服务的功能和消息体定义都十分复杂，微服务须要更轻量的机制。

同步消息 - REST, Thrift

同步消息就是客户端须要保持等待，直到服务器返回应答。REST是微服务中默认的同步消息方式，它提供了基于HTTP协议和资源API风格的简单消息格式，多数微服务都采用这种方式（每一个功能表明了一个资源和对应的操做）。

Thrift是另一个可选的方案。它采用接口描述语言定义并建立服务，支持可扩展的跨语言服务开发，所包含的代码生成引擎能够在多种语言中，如 C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, Smalltalk 等建立高效的、无缝的服务，其传输数据采用二进制格式，相对 XML 和 JSON 体积更小，对于高并发、大数据量和多语言的环境更有优点。

图3：REST接口，对外微服务

异步消息 - AMQP, STOMP, MQTT

异步消息就是客户端不须要一直等待服务应答，有应到后会获得通知。某些微服务须要用到异步消息，通常采用AMQP, STOMP, MQTT。

消息格式 - JSON, XML, Thrift, ProtoBuf, Avro

消息格式是微服务中另一个很重要的因素。SOA的web服务通常采用文本消息，基于复杂的消息格式（SOAP）和消息定义（xsd）。微服务采用简单的文本协议JSON和XML，基于HTTP的资源API风格。若是须要二进制，经过用到Thrift, ProtoBuf, Avro。

服务约定 - 定义接口 - Swagger, RAML, Thrift IDL

若是把功能实现为服务，并发布，须要定义一套约定。单体架构中，SOA采用WSDL，WSDL过于复杂而且和SOAP紧耦合，不适合微服务。

REST设计的微服务，一般采用Swagger和RAML定义约定。

对于不是基于REST设计的微服务，好比Thrift，一般采用IDL（Interface Definition Languages），好比Thrift IDL。

微服务集成 (服务间通讯)

微服务架构下，应用的服务直接相互独立。在一个具体的商业应用中，须要有些机制支持微服务之间通讯。所以服务间的通讯机制特别重要。

SOA体系下，服务之间经过企业服务总线（Enterprise Service Bus）通讯，许多业务逻辑在中间层（消息的路由、转换和组织）。微服务架构倾向于下降中心消息总线（相似于ESB）的依赖，将业务逻辑分布在每一个具体的服务终端。

大部分微服务基于HTTP、JSON这样的标准协议，集成不一样标准和格式变的再也不重要。另一个选择是采用轻量级的消息总线或者网关，有路由功能，没有复杂的业务逻辑。下面就介绍几种常见的架构方式。

点对点方式 - 直接调用服务

点对点方式中，服务之间直接用。每一个微服务都开放REST API，而且调用其它微服务的接口。

图4：经过点对点方式通讯

很明显，在比较简单的微服务应用场景下，这种方式还可行，随着应用复杂度的提高，会变得愈来愈不可维护。这点有些相似SOA的ESB，尽可能不采用点对点的集成方式。

点对点有下面几个缺点:

非功能的需求，好比用户受权、限制、监控，须要在每一个微服务中进行实现
随着功能的演进，服务会变得愈来愈复杂。
不一样的服务直接，客户端和服务直接没有控制功能（监控、跟踪、过滤）
直接通讯在大型系统设计中，通常是反面典型。

所以，若是设计一个大型的微服务系统，尽可能避免点对点的通讯方式，也不能像ESB这样重量级的总线。而是一个轻量级的总线，可以提供非业务功能的抽象。这就是API网关方式。

API-网关方式

API网关方式的核心要点是，全部的客户端和消费端都经过统一的网关接入微服务，在网关层处理全部的非业务功能个。一般，网关也是提供REST/HTTP的访问API。服务端经过API-GW注册和管理服务。

图5：经过API-网关暴露微服务

用咱们网上商店的例子，在图5中，全部的业务接口经过API网关暴露，是全部客户端接口的惟一入口。微服务之间的通讯也经过API网关。

采用网关方式有以下优点：

有能力为微服务接口提供网关层次的抽象。好比：微服务的接口能够各类各样，在网关层，能够对外暴露统一的规范接口。
轻量的消息路由、格式转换。
统一控制安全、监控、限流等非业务功能。
每一个微服务会变得更加轻量，非业务功能个都在网关层统一处理，微服务只须要关注业务逻辑

目前，API网关方式应该是微服务架构中应用最普遍的设计模式。

消息代理方式

微服务也能够集成在异步的场景下，经过队列和订阅主题，实现消息的发布和订阅。一个微服务能够是消息的发布者，把消息经过异步的方式发送到队列或者订阅主题下。做为消费者的微服务能够从队列或者主题共获取消息。经过消息中间件把服务之间的直接调用解耦。

图6：异步通讯方式

一般异步的生产者/消费者模式，经过AMQP、MQTT等异步消息规范。

数据的去中心化

单体架构中，不一样功能的服务模块都把数据存储在某个中心数据库中。

图7：单体架构，用一个数据库存储全部数据

微服务方式，多个服务之间的设计相互独立，数据也应该相互独立（好比，某个微服务的数据库结构定义方式改变，可能会中断其它服务）。所以，每一个微服务都应该有本身的数据库。

图8：每一个微服务有本身私有的数据库，其它微服务不能直接访问。

数据去中心话的核心要点：

每一个微服务有本身私有的数据库持久化业务数据
每一个微服务只能访问本身的数据库，而不能访问其它服务的数据库
某些业务场景下，须要在一个事务中更新多个数据库。这种状况也不能直接访问其它微服务的数据库，而是经过对于微服务进行操做。

数据的去中心化，进一步下降了微服务之间的耦合度，不一样服务能够采用不一样的数据库技术（SQL、NoSQL等）。在复杂的业务场景下，若是包含多个微服务，一般在客户端或者中间层（网关）处理。

下篇文章会介绍微服务实战的其它内容：管理去中心化、服务的注册和发现、安全、事务、失败的设计、其它。

原文做者：Kasun Indrasiri，软件架构师，WSO2

原文连接：https://dzone.com/articles/microservices-in-practice-1

翻译自MaxLeap团队_云服务研发成员：Frank Qin

关于MaxLeap

MaxLeap移动云服务平台为企业提供一站式的移动研发和运营云服务，帮助企业快速研发和上线移动应用，平台提供数据云存储，云引擎，支付管理，IM，数据分析和营销自动化等服务。

官网连接：https://maxleap.cn

若是您正在学习移动研发和云服务等方面的讯息，不妨关注咱们的微信服务号MaxLeapSvc，咱们将不按期推送相关干货。敬请期待！