微服务操做模型

微服务操做模型

本文不是另一篇关于微服务介绍的文章，要看微服务介绍的经典文章直接戳后面Fowler的微服务。

而本文假设咱们已经开始使用微服务，用它来分解单体应用以提升部署效率和可扩展性。

随着系统领域部署微服务数量剧增，就会出现新的挑战，而这些挑战在只部署一些单体应用的时候是没有的。这篇文章咱们就聚焦这些新的挑战，并给使用大量微服务部署的系统领域操做模型作个定义。

本文分为以下几部分:

• 先决条件
• 扩展
• 问题
• 必要组件
• 参考模型
• Next step

1. 先决条件

首先若是要在系统蓝图中使用大量微服务须要什么条件?

根据Fowler微服务介绍，咱们要达到下面的目的:

然而，在咱们开始在咱们的系统蓝图铺开大量微服务来取代咱们现有的单体应用以前，咱们须要知足一些先决条件(或者至少在某种程度下), 咱们须要:

• 目标架构
• 持续发布连锁工具
• 优化的组织结构

下面咱们分别看看这几个条件。

1.1 目标架构

首先咱们须要一个如何分解咱们微服务的架构思想。例如咱们能够将他们分解成下面几个垂直层:

• 核心服务: 处理业务数据持久化以及应用业务规则和其余逻辑的。
• 组装服务: 组装服务能够协调多个核心服务执行普通任务，或者从一些核心服务中聚合信息。
• API服务: 给外部暴露一些可用的功能，例如，容许第三方发明创造性的应用程序，这些应用程序可使用系统蓝图里的底层功能。

另外水平层面咱们能够应用一些领域驱动分区。这样目标架构有可能相似以下:

注意： 这只是一个目标架构的样板，而你具体的架构可能彻底不一样。这里关键点在于， 在开始扩展部署微服务以前须要有一个目标架构。 不然看到的系统蓝图就像意大利面条同样, 望而止步，这样的话比现有的单体应用的特色还要糟糕。

1.2 持续发布

咱们也假设已经有一些的现成的持续部署工具链，所以咱们能够进行有效的、重复的、高质量驱动的方式来开始微服务实现, 例如:

1.3 组织结构

最后, 咱们假设咱们已经采起咱们的组织结构来避免Conway法则引起的问题。 康威法则陈述以下。

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.
任何设计系统的组织，必然会产生如下设计结果：即其结构就是该组织沟通结构的写照。简单来讲： 产品必然是其组织沟通结构的缩影。

扩展(SCALING UP)

所以，本文接下来的焦点在于当咱们开始将一些单体应用分解并使用微服务替代它们的时候，在系统蓝图中会发生什么?

• 大量部署的单元: 不少微服务代替一些大型的单体应用，固然会致使明显数量的发布单元须要管理和跟踪。
• 微服务既暴露服务也消费服务: 这就致使系统领域中大多数微服务须要互相交互。
• 某些微服务会暴露外部API: 这些微服务会负责屏蔽其余微服务免受外部访问。
• 系统领域更加动态: 新微服务部署后，旧的须要替换或移除，原有微服务的新实例须要启动来知足负载增长。 这就意味着服务比以前的来回访问要更频繁些。
• 平均故障间隔时间(MTBF)会下降, 例如系统领域的失败发生的频率仍是比较高的: 软件组件有时会出错。 对于有大量小的部署单元的系统来讲，系统领域中的部分失败的几率会增大，相对于只使用一些大的单体应用程序的几率来讲。

问题

这样会致使一些重要的以及在新运行环境中引起的新问题:

• 咱们全部的微服务如何配置以及这样是否正确? 处理配置对于一些应用程序来讲，不是主要问题， 例如，每一个应用程序在磁盘中的属性文件或本身的数据库中的配置表来存储它本身的配置。在多个服务器为大量微服务部署多个实例，这种方式中管理变得更加复杂。致使大量小的配置文件/表遍及系统领域，使得很难有效维护，也很难有很好的质量。
• 咱们部署了什么微服务，以及微服务部署在哪里? 使用一些简单的应用程序来跟踪服务暴露的主机和端口号很是简单，由于这些量少而且改变的概率也不大。使用大量独立部署的微服务，在系统领域来看或多或少会有一些不断变化的状况，若是手动来处理这些可能会致使很难维护。
• 如何让路由信息保持不变？对于在动态系统领域中的服务消费者可能有挑战。 具体来讲若是所在路由表，例如反向代理或消费者配置文件须要手动更新。基本上来讲没有时间在或多或少处于不断演化的微服务领域中手动编辑路由表来弹出新的host/port地址。交付时间太长，容易冒手工错误的风险，这样会影响质量方面和/或无必要高的操做代价。
• 如何防止连锁失败? 既然微服务须要互相链接，须要特别注意系统领域中的连锁失败。例如，若是其余一些微服务依赖的某个微服务失败了，依赖的微服务也将失败等等。若是处理不当，系统领域的大量部分都会由于单个失败的微服务而受影响, 致使脆弱的系统领域。
• 如何验证全部服务已启动而且在运行中? 跟踪少许应用的状态相对容易，可是咱们如何验证全部的微服务的健康以及准备接收请求?
• 如何跟踪服务间的消息流? 若是支持组织开始抱怨一些失败的处理怎么办? 如何找到相关的处理，例如，订单号12345的处理被卡住，由于微服务A不可访问或在微服务B能够发送关于那个订单的确认信息以前须要执行手工审批。
• 如何确保只有API服务是外部暴露的? 例如，如何避免来自外部到内部微服务的无受权访问?
• 如何让API服务安全? 不是关于微服务的新问题或特性问题，可是对于让真正暴露外部的微服务安全来讲依然很是重要。

必要组件

为了解决这些问题的大部分，须要在没必要要的系统景观中加入必要操做和管理功能, 或者至少在必定程度上，当只操做几个应用的时候。上述问题的建议解决方式包括下面的组件:

• 集中配置服务器: 代替每一个部署单元(例如微服务)的局部配置, 咱们须要集中化配置管理。 咱们也须要微服务能够用于获取配置信息的配置API。
• 服务发现服务器: 代替手工跟踪当前发布了什么微服务，以及服务发现功能容许的host和port，经过API，微服务启动时能够自动注册。
• 动态路由以及负载均衡: 给定的服务发现功能，路由组件可使用发现API来查找请求的微服务在哪里部署以及负载均衡组件能够决定将请求路由到哪一个实例，若是对于请求服务部署了多个实例的话。
• 断路器: 为了不连锁失败问题，咱们须要应用断路器模式，要了解详情能够参考Release It!这本书或者Fowler的短路器文章。
• 监控: 鉴于咱们有就绪的断路器，咱们能够从它们身上开始监测它们的状态以及搜集运行时间统计来获取系统领域以及当前使用的健康状态。这些信息能够收集并显示在dashboard上，而且能够经过配置的阀值来自动告警。
• 集中化日志分析: 为了可以跟踪消息并监测它们什么时候被卡住，咱们须要一个集中化日志分析功能，它们能到达服务器而且搜集每一个微服务产生的日志文件。日志分析功能将日志信息保存在集中数据库中，提供搜索和dashboard能力。 注意: 为了可以查找相关消息，在日志消息中使用相应的id对于全部微服务来讲是很是重要的。
• 边界服务器: 为了对外暴露API并防止对内部微服务的未受权访问，咱们须要一个边际服务器，全部的外部流量都经过它。 边际服务器能够基于上面描述的服务发现组件来复用动态路由和负载均衡能力。边际服务器将扮演一个动态的、活动的反向代理，每当内部系统领域改变的时候无需手工更新。

• OAuth 2.0保护的API: 为了保护暴露的API服务，推荐使用OAuth 2.0标准。 将OAuth 2.0应用到建议的解决方案中:

  • 新组件能够扮演OAuth受权服务器.
  • API服务将扮演OAuth资源服务器.
  • 外部API消费者将扮演OAuth客户端.

  • 边际服务器将扮演OAuth Token中继，意思是:

    • 它将扮演OAuth资源服务器.
    • 它将传递来自外部请求带来的OAuth Token给API服务.

注意: 随着时间的推移，OAuth 2.0标准将最有可能与OpenID链接标准相补充，以提供改进的受权功能。

参考模型

总之，意味着微服务须要一系列上面描述的支持服务设施，微服务使用它们的API来交互。能够经过下面的图片可视化:

注意：为了减小图片中的复杂性，微服务和支持服务之间的交互是不可见的。

Next Step

在即将出现的博文中咱们会描述和演示建议的参考模型是如何实现的，能够参考文章序列 - 构建微服务。

术语

• MTBF: 平均故障时间(Mean Time Between Failures).
• 连锁失败: chain of failures.

参考连接

• 微服务操做模型原文
• OAuth 2.0
• OpenID
• 专题首页