基于微服务架构的基础设施设计

基于微服务架构的基础设施设计

摘要：本文首先分析传统的单体架构进而解释微服务架构以及分布式环境下四层架构，详细分析了迁移需解决的关键问题如服务间通信机制、数据最终一致性等；然后分析了分布式系统核心问题和DevOps基本原则，以此为设计依据提出微服务架构基础设施总体设计，并且对其关键组件如服务注册与发现、持续交付平台、服务网关的实施提出具体方案；最后针对微服务架构基础设施在运维管理中的应用场景进行了探讨，说明了微服务架构设计思想优于单体架构设计思想。

关键词：软件工程；微服务；服务注册与发现；持续交付

中图分类号：TP311.5 文献标识码：A DOI：

10.3969/j.issn.1003 6970.2016.05.023

本文著录格式：蒋勇.基于微服务架构的基础设施设计卟软件，2016，37（5）：93-97

0.引言

理论上任何业务系统如果长期存在的话，随着此系统业务变更、功能增加必然会不断演变，在一个更大的分布式环境中，这种改变尤其明显，那么就需要架构分析设计时更多的考虑系统所处的生态环境建设，这样才能使得整个系统不

断进化。随着虚拟化技术的发展以及docker容器实践逐渐完善，微服务架构的设计思想逐渐浮出水面，形成分布式环境下新的最重要的设计思想。文献对分布式环境下资源及应用平台进行了研究，但对于应用自身依赖的基础设施建设没有讨论。本文将详细探讨如何基于微服务架构进行基础设施建设的设计与分析。

1.从分布式单体架构到微服务架构迁移

1.1分布式单体架构

分布式单体架构指的是在分布式环境下直接部署运行

一个整体开发的应用，由整体应用来提供系统所需的服务，它在技术上通常采用分层实现，大致分为表现层、应用层、数据层，它有天然的优势：它是模块独立无关的，各层之间是技术分离的；它有统一的技术栈和开发标准；它通常在一个进程中运行，模块相互之间协同消耗极小。

但是，在分布式环境下，随着系统功能的增加，系统越来越复杂，单体架构存在一些必然的缺陷：首先，由于整个系统是一个完整整体，必须重复部署多个才能提高系统性能，而往往系统瓶颈仅仅由于其中某一个或几个功能过载产生，这就极大浪费了运行环境资源；其次，由于系统功能的变更和演变，某一个功能的变化可能影响其它功能的正常结果，也带来重新部署和运维管理的复杂性，持续集成变得极为困难；最后，由于整个系统采用统一的技术栈和开发标准，必

然使得技术本身的多样性受到限制，造成解决问题的方法和开发方式存在一定的局限性，当整合外部服务、开放内部服务时也带来一些技术实现的复杂性。

由此可知，在分布式环境下原有的整体开发的单体架构有必要改进、变化。

1.2微服务架构

1.2.1微服务架构定义

微服务架构是一种新的软件体系设计模式，它并没有形成统一、严格的定义，但是基于其分布式环境应用的场景，却拥有一些共同的特征：比如开发敏捷性、持续交付、可伸缩性、最终一致性等。

微服务架构建议将大型复杂的单体架构应用划分为一

组微小的服务，每个微服务根据其负责的具体业务职责提炼为单一的业务功能；每个服务可以很容易地部署并发布到生产环境里隔离和独立的进程内部，它可以很容易地扩展和变更；对于一个具体的服务来说可以采用任何适用的语言和工具来快速实现；服务之间基于基础设施互相协同工作。

1.2.2分布式四层架构定义

由美国视频服务企业netflix提出的“engagement platform”支持分布式的四层架构，是目前采用微服务架构的最成功实践，它能很好的适用于大规模应用运行环境，满足更高的性能要求。分析理想的分布式四层架构如图1所示。

分布式四层架构的每层功能如下：

1）显示层：这一层主要是把系统提供的各类服务展现给用户，支持用户通过界面与系统进行友好的交互，也支持管理员通过界面对系统进行监控管理。

2）分发层：这一层主要针对用户或者其它系统发出的请求进行预处理，并根据策略决定路由到何处去进行处理，从而达到分发控制的目的，并且根据请求峰值采取负载均衡扩展策略或者相应熔断限流策略。

3）聚合层：这一层负责提供基于各类原子基础服务的集成、编排、组合，并且包含各类数据的清洗、采集、转换；提供可以动态变更策略的服务访问控制功能（如授权机制、角色分配、缓存、数据一致性等）；提供轻量级的通信机制或者采用统一默认调用规则使得各类服务之间容易协同合作。

4）服务层：这一层提供不可分割的、最小原子的、单一业务功能的服务，每一个服务部署在独立的、隔离的运行环境，可以方便的替换和扩展，对上层提供基础API调用接口支持。

1.3迁移需解决问题

在分布式环境下，从单体架构迁移到微服务架构需要解决很多问题：首先需要一种设计理念的转变，根据职责分离的原则把大的复杂的业务逻辑抽象成更小的原子的可重复

利用的服务，并且尽可能的减少流程紧密联系的业务逻辑拆分；其次需要从服务这个角度出发考虑业务逻辑的设计实现，进而考虑服务的定位、编排和访问控制如何优雅的实现；最后需要考虑的是这些微服务的可持续交付以及后端数据最

终一致性问题。从单体应用迁移到微服务应用如图2所示：

1.3.1如何处理服务状态

在分布式环境下尽可能的设计无状态的微服务更容易

实现可伸缩性，但是在很多应用场景（用户相关数据读写）有状态是不可避免的，所以必须把有状态服务的状态相关信息提取出来使得有状态服务达到无状态服务同样的性能和

扩展能力。目前有两种实现方式：一种是采用分布式缓存集群存储状态，一种是采用nosql数据库集群来存储状态。

1.3.2服务之间通信机制

由于每个微服务都是在独立、隔离的进程内部运行，所以这些微服务之间的调用行为属于进程间通信。服务之间通信机制需要考虑以下几点：1）服务标识：每个微服务需要通过类似语义定义语言来准确的描述标识一个服务

的API，还需要考虑到服务升级和多版本共存如何描述，保

证向前兼容；

2）服务并发情况：服务之间的调用方式存在两种响应

方式：一个服务的请求会有一个服务实例响应，一个服务的请求会有多个服务实例响应。如果是并发就需要考虑如何实

现并描述服务并发触发机制以及并发策略；

3）处理部分失效：当服务被调用时可能存在调用超时或者得不到响应因而产生调用堵塞并且占用资源，处理这类情况需要根据不同场景采取不同策略，比如超时重试策略、熔断限流策略、最近失败缓存等。

4）同步请求/响应模式：基于http的REST，基于RPC

和序列化支持多种消息格式的Thrift，二进制格式的Protocol Buffer、Avro。

5）异步消息通信模式：实现AMQP的RabbitMQ、Apache 的Kafka。

6）服务执行结果缓存：随着系统性能要求的增长或者服务被重复调用的需要，在一定时间间隔缓存服务执行结果存在一定必要性。

1.3.3服务注册与发现机制

如何进行服务定位就涉及到服务的注册与发现机制，这就需要提供一个高性能、高可用、实时更新的服务注册与发现中心或者提供智能终端和哑管道。

服务注册有自注册/被注册两种方式。自注册：由服务实例自己到服务注册与发现中心注册或注销，并且通过心跳通讯来确认注册信息有效性。被注册：由服务注册与发现中心来确认服务的注册与注销，它常常通过查询服务实例部署信息或者通过订阅服务实例部署事件来发现一个新的服务实

例，并跟踪其运行状态确认注销终止的服务实例。

服务发现有两种场景：服务调用者发现/分发层服务发现。

1）服务调用者发现场景：服务调用者直接向服务注册

与发现中心请求查询，获得可用的服务，根据默认规则或者负载均衡策略从与此服务对应的多个服务实例中选择请求

对象发出请求。这种场景就需要提供客户端框架。

2）分发层服务发现场景：客户端向分发层提出请求，

分发层处理请求时首先向服务注册与发现中心发出查询获

取查询结果，然后依据分发路由策略将每个请求转发往可用的服务实例。这种场景需要服务端框架。

1.3.4服务可持续交付

实现微服务架构的保障就是能够严格执行服务的可持

续交付，服务可持续交付指的是每个服务交付的流程具备持续性，也就是说一个微服务应用从开发完毕到部署发布中间的过程是一个可持续的过程，并且这个微服务应用可能存在多个版本不同运行状态的服务实例，它们需要集成到现有的运行环境中稳定提供服务。服务可持续交付常常包括几个方面：开发、单元测试、构建、部署、集成、集成测试、发布，从基础设施环境来看又包含几个部分：代码版本管理、构建管理、部署管理、集成管理、测试管理、发布管理、运维监控管理。

1.3.5数据最终一致性

数据最终一致性指的是数据对象在没有新的更新之前，最终所有获取数据的请求都将返回最后更新的值，在分布式环境微服务架构下，为了保证每个微服务的可伸缩性和独立性，为了保证微服务之间的松散耦合，不同的微服务都有自己的数据源并且可能使用不同类型的数据库（nosql或者关系型数据库），这种去中心的分布式数据管理使得实现多个服

务之间的事务型事务变得极为困难，因为如果这种多阶段事务执行中任何一个阶段失败都会造成数据不一致（事务回滚非常复杂），这就需要一种方案既保证多服务之间的事务型

事务执行时业务交易的数据一致性又保证从多个服务获取

一致性数据的高可用性。

一种方案是多个微服务应用访问同一个数据库或者把

多个微服务应用逻辑上归并为一个微服务应用开发，这里就需要在业务逻辑拆分时进行权衡，对于那些频繁访问或者流程紧密联系的业务功能不进行拆分而作为一个微服务进行

设计开发。

另一种方案是使用事件驱动框架和消息队列来完成多

个服务之间的事务型事务，其流程是把跨多服务的事务分解为若干步骤，每一个步骤会发布一个激活下一个步骤的事件，任何一个步骤失败代表整个事务失败，必须保证对数据的修改能够通过事务补偿运算来实现逻辑回滚。这种方案的优点是异步且事务吞吐量大、容错性好，其缺点是开发较为复杂。

2.微服务架构基础设施设计与分析

2.1微服务架构基础设施设计依据

2.1.1分布式系统核心问题

1）性能和可伸缩性

在分布式环境下，微服务架构使得业务逻辑可以拆分为粒度较小的服务，这些服务能够运行在独立、隔离的环境，易于部署、可扩展性强，因此这些微服务的处理请求能力可伸缩性强，性能优势明显。

2）数据一致性和高可用性

在分布式环境下，从硬件到主机操作系统到软件总有一部分存在故障状态，需要保证这个系统的高可用性就需要尽可能的减少系统资源开销的同时排除单点故障或者容忍错误；然而在故障恢复或者多点备份或者执行多服务事务的同时也需要保证数据的一致性，基于性能优先的考虑这种数据一致性是数据最终一致性。

2.1.2DevOps基本原则

DevOps指的是从软件交付的全局出发在开发和运维架起交流和协作的桥梁，并且自动化配置管理软件的文化变革运动，DevOps的重要组成部分就是持续交付，其基本原则是使软件交付的流程自动化且可持续，并尽可能简洁。

2.2微服务架构基础设施总体设计

通过分析在分布式环境下从单体架构迁移到微服务架

构需要解决的问题以及微服务架构基础设施的设计依据，得到微服务架构基础设施总体设计如图3所示。

其中，开发完毕的微服务应用经由持续交付平台部署、验证、发布到分布式环境中，同时把这个微服务注册到服务注册中心，用户或外部服务通过服务网关访问此分布式环境节点中的API服务，服务网关通过服务注册中心发现服务。其他一些基础设施提供对这些微服务的运行监控管理。

2.3微服务架构基础设施关键组件

2.3.1持续交付平台

实现一个可持续交付平台的目的是把基于分布式环境

分析设计的微服务应用快速灵活、可重复且持续的、自动化的集成部署到分布式环境中稳定运行，并且这些微服务是可编程配置、易于维护、变更、扩展的，其可以运行于一个独立、隔离的容器里表现为一个进程。持续交付流程如图4所示。

一个可持续交付平台主要包含两部分内容：

1）软硬件资源管理功能：它主要管理整个分布式环境中的软硬件资源如何合理进行逻辑划分利用，这些资源包括主机资源（内存、硬盘、磁盘阵列、CPU）、网络设施（路由、虚拟网络）、容器实例（微服务实例）等。

2）持续交付流程引擎：通过定义可持续交付流程的各个阶段节点以及触发条件，并且提供默认执行规则和策略或

者人工配置选项设置来实现一个微服务实例的构建、集成、部署流程，通过心跳检测或其它手段监控微服务实例健康状况并且可在期望阈值时触发相应响应事件。

目前开源可借鉴产品有：Jenkins、Netflix的Spinnaker、ThoughtWorks的Go等。

2.3.2服务注册与发现组件

服务注册与发现是微服务架构中的核心组件，分布式环境中服务的实例会根据运行环境变化依据默认规则或策略

动态变化，这时要实现服务注册与发现变得异常复杂，它常常需要提供以下功能：

1）注册和标识服务：一个服务一旦从可持续交付平台部署运行起来就成为一个服务实例服务实例最终是需要被

用户或其它服务访问的，那么需要一个服务注册中心记录服务实例的位置信息属性、访问路径、认证证书、访问协议、版本号以及其它访问相关信息。可以通过在部署流程结束时向服务注册中心自动注册服务实例。标识一个服务的服务实例那么意味着首先需要标识一个服务。一个服务实例和服务的不同之处在于服务实例是有位置信息和部署相关信息的，而且一个服务实例是有健康状态的也是有生命周期的，一个服务可以有多个版本，每个版本的服务对应多个服务实例，每个版本的服务对应一个部署流程。服务注册中心追踪服务实例的运行状态，服务实例随着自身健康状态的变化以及网

络环境的变化其位置信息会动态变化。一个版本的服务它的服务实例在运行环境中动态部署多少个需要配置相应阈值触发策略。

2）定位和发现服务：当用户从客户端直接访问时，分发层会查询服务注册中心发现可访问的服务并根据负载均衡算法转发到相应的服务实例。从分发层来看，服务层提供的服务是单个服务，聚合层提供的服务是多个服务的编排组合。分发层需要根据请求负载和活着的服务实例数量决定负载均衡算法或者扩展已有的服务实例。更多的场景是多个微服务协同合作时如何定位和发现服务。这时调用者如果不经过分发层而是直接访问服务层的服务，那么调用者查询服务注册中心发现可访问的服务以及与之对应的服务实例，然后设置相应的负载均衡算法调用相应的服务实例。

目前开源可借鉴产品有：Netflix的Eureka、Etcd、Consul 等。

2.3.3服务网关

服务网关是一个统一调用逻辑人口，封装了分布式环境中某个节点内部的服务信息。服务网关的实现有几部分：1）支持对已有的服务注册中心注册的服务直接暴露给外部调用。

2）对于客户端展现需要调用的多个服务的场景开发新的服务使得客户端一次请求获得多个服务的组合结果。

3）支持对请求预处理、规则匹配，比如认证、授权判

断等。

4）支持为某些一定时间间隔执行结果不变的服务请求

提供缓存存储，并且对服务请求部分失效提供最后一次正确执行的缓存结果或者空响应。

5）提供请求分发路由、负载均衡、安全防护、协议转

换等功能。

目前开源的服务网关有：Netflix的Zuul，Mashape的Kong、Tyk等。

3.微服务架构基础设施在运维管理中的应用

随着信息化的发展，各类应用系统层出不穷，运维人员管理数量极其庞大的微服务变得十分复杂，因此在分布式环境下应用的可持续交付能力变得极其重要。采用持续交付平台可以支持微服务自动化的便捷部署到分布式环境中并经

过验证后发布。采用服务注册中心可以支持微服务的发现与定位，为微服务的集成、组合提供支持。采用服务网关可以对外提供一个分布式环境节点的微服务API统一访问入口。采用其它基础设施比如消息总线可以提供微服务之间异步

调用支持，任务和资源调度可以提供微服务合理利用分布式环境各类资源。通过在分布式环境下提供各种基础设施使得整个运维管理更加高效、科学、合理，并且极大的降低了运维成本和复杂性。

4.结论

本文通过分析分布式环境下微服务架构相对于单体架构的优势以及其迁移需解决问题提出微服务基础设施总体设计，分析了基础设施关键组件的功能，举例了其在运维管理中的应用。当然微服务架构的实践还存在很多待深入研究的问题，比如其在机器学习、大数据挖掘等分布式计算场景的应用，这些还需要今后在实践中不断探索、学习。