微服务操做模型

这里并非介绍微服务概念，如须要了解微服务，能够阅读Fowler-Microservices文章。本博客假定咱们已开始使用微服务解耦单体应用，用来提高可部署性和可扩展性。

当咱们在系统范围内部署大量的微服务时，一个新的挑战产生了，单体应用部署时不会发生。这篇文章将针对这些新的挑战，在系统范围内部署大量微服务时定义一套操做模型（operations model）。

这篇文章分为以下几个部分：

1. 前提条件；
2. 扩展；
3. 问题；
4. 须要的组件；
5. 参考模型；
6. 下一步；

 

1. 前提条件

当在系统范围内须要部署大量微服务时，须要什么条件呢？

根据Flower的文章，以下是咱们想要获得的：

 (Source:http://martinfowler.com/articles/microservices.html)

 

然而，在开始发布大量微服务替换单体应用以前，咱们须要实现以下这些前置条件：

• 目标架构；
• 持续交付工具；
• 合适的组件结构；

下面简要描述每个前置条件。

1.1   目标架构

首先，咱们须要分区微服务。例如，咱们能够垂直分解微服务。

• 核心服务（Core services）-处理业务数据的持久化和实施业务逻辑和其余规则；
• 组合服务（Composite services）-组合服务指编排一组核心服务实现一个特定任务，或者从一组核心服务中聚合信息；
• API services – 向外暴露功能，例如容许第三方使用底层功能建立新的应用；

 

也能够水平上应用领域驱动分解。以下是一个目标架构：

备注：这仅仅是一个范例目标架构，你可使用彻底不一样的架构。核心时在开始部署微服务以前，须要有简历一个目标架构。不然，你最终的架构有可能像一团面条同样，甚至比现有的单体应用更加糟糕。

 

1.2 持续交付

咱们假定已经有了一套可持续交付的发布工具，以便咱们能够高效地反复发布微服务。

 

(Source: http://www.infoq.com/minibooks/emag-devops-toolchain)

 

1.3合适的组织

最后，咱们须要采用合适的组织结构，避免和Conway法则相冲突。Conway法则以下：

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.

 

(Source: http://martinfowler.com/articles/microservices.html)

 

2. 扩展

接下来是本文关注的要点：

当咱们分解单体应用，并使用大量的微服务替换时，在系统范围内会发生什么呢？

(1)   大量的部署单元

将产生须要的小的微服务，而不是以前的一个大的单体应用，这将须要管理和跟踪大量的部署单元。

(2)   微服务将同时暴露和调用服务

在系统范围内，大部分的微服务彼此是互相链接的。

(3)   一些微服务暴露外部API

这些微服务将负责包含其余的微服务不容许外部访问。

(4)   系统根据动态

新的微服务部署，替换老的服务。现有的微服务新增实例，知足增加的负荷。这意味着微服务将比之前更高的频率增长和下线。

(5)   平均故障时间(MTBF)将降低

在系统范围内，故障发生频率将更频繁。软件组件将不时发生问题。大量部署的微服务将比以前部署的单体应用出现问题的可能更高。

 

3. 问题

微服务模型将致使一些重要的运行时相关的问题：

(1)   微服务如何配置以及是否正确？

针对少许的应用程序，处理配置不是主要的问题，如使用配置文件或者在数据库中的配置表。在大量的微服务部署到大量的服务器上时，这一配置访问将变得很是复杂。这将致使大量的小的配置文件或者数据配置表遍及整个系统，使得难以高效可靠地维护。

(2)   什么微服务部署了，部署在哪里了？

在只有少许服务部署时，管理部署的主机和端口仍是比较简单的。可是当有大量的微服务部署时，这些服务或多或少须要持续变动，如手工维护将变得很是麻烦。

(3)   如何维护路由信息？

在动态系统范围中，服务消费方也是一个挑战。尤为是路由表或者消费配置文件，须要手工更新。在微服务不断新增新的主机/端口时，将没有时间手工维护。交付时间将会延长，而且手工维护出错的风险也会增长。

(4)   如何防止失败链？

因为微服务之间是相互链接的，须要关注系统范围内的失败链。例如，一个被其余众多微服务依赖的微服务失败了，其余依赖的微服务也可能开始失败。若是没有合适处理，大量微服务将受到这个单一失败的微服务所影响，致使一个脆弱的系统。

(5)   如何验证全部的微服务已上线且在运行中？

跟踪少许应用的运行状态是比较简单的，可是如何验证全部的微服务是健康的，且准备好接收请求？

(6)   如何跟踪服务之间的消息？

如何应对组织开始接到关于一些流程执行失败？什么微服务到致使这一问题的根本缘由？例如，订单12345卡住了，咱们如何知道是由于微服务A没法访问，仍是由于微服务B在发送一个订单确认消息以前，须要手工批准。

(7)   如何确保仅仅API服务暴露给外部？

例如咱们如何避免外部未受权的请求，对内部微服务的访问？

(8)   如何保证API服务的安全？

这不是针对微服务的特定问题，可是保护对外暴露的微服务仍然是很是重要的。

 

4. 须要的组件

为了解决上述的一些问题，新的操做和管理功能是必须的。针对上述问题，建议的解决方案包括以下组件：

(1)   中心配置服务Central Configuration Server

咱们须要一个中心配置管理，而不是针对每个部署单元（微服务）有一个本地配置。此外，咱们还需一个配置API，微服务用来获取配置信息。

(2)   服务发现服务 Service Discovery Server

咱们须要服务发现功能，微服务在启动时，经过API本身注册，而不是手工跟踪微服务部署的主机和端口。

(3)   动态路由和负载均衡 Dynamic Routing and Load Balancer

基于服务发现功能，路由组件使用discovery API 查询请求的微服务部署在哪里；在被请求的服务部署了多个实例的状况下，负载均衡组件能够决定路由请求到特定的实例。

(4)   电路断路器 Circuit Breaker

为了不失败链问题，咱们须要养分Circuit Breaker模式，详细信息能够参考 Fowler-Circuit Breaker的文章。

(5)   监控 Monitoring

基于电路断路器，咱们能够监控微服务的状态，同时收集运行时统计数据，获知服务的健康状态和当前使用率。这些信息能够收集并显示在dashboard上，并针对配置阈值设置自动报警。

(6)   中心日志分析 Centralized Log Analysis

为了跟踪消息，并检测微服务什么时候故障，咱们须要一个中心日志分析功能，能够访问服务器并收集每个微服务的log文件。日志分析功能保存log信息在中心数据库中，并提供了查询和dashboard功能。备注：为了查找相关的消息，全部微服务须要在log消息中使用相关的id，这点很重要。

(7)   边缘服务 Edge Server

为了对外部暴露API 服务，并阻止对内部微服务的未受权访问，咱们须要一个边缘服务（Edge Server），全部外部的访问都通过边缘服务器。基于前面的服务发现组件，边缘服务器能够重用动态路由和负载均衡功能。边缘服务器做为一个动态和有效的反向代理，在内部系统更新时，没必要手动更新。

(8)   OAuth 2.0保护的API

建议OAuth 2.0 标准保护暴露的API服务。应用OAuth 2.0 有以下效果：

1/一个新组建做为OAuth Authorization Server；

2/API服务做为OAuth Resource Server；

3/外部API消费方做为OAuth Clients；

4/边缘服务器（Edge Server）做为OAuth Token Relay；

（4.1）做为OAuth Resource Server；

（4.2）将外部请求中的OAuth Access Tokens传递给API 服务；

备注：OAuth 2.0 标准可能经过OpenID Connect标准来补充完善，提供更好的受权功能。

 

5. 参考模型

总而言之，微服务须要一套包含上述支持服务的基础设施，微服务使用它们的API来交互。下图描绘了这一基础设施：

 

备注：为了减小上图中交互的复杂度，微服务和支持服务的交互并无画出来。

 

6. 下一步

在接下来的文章中，咱们将描述和演示如何实现上述建议的参考模型。

 

英文原文连接：

An operations model for Microservices