微服务技术：体系结构、通信和挑战

代 飞，刘国志，李 章，莫 启，李 彤

1.西南林业大学大数据与智能工程学院，昆明650224

2.云南林业职业技术学院继续教育与国际交流学院，昆明650224

3.云南大学软件学院，昆明650091

4.云南农业大学大数据学院，昆明650201

2014年，Fowler 和Lewis 正式提出了微服务的概念[1].微服务是一种新型的架构风格，它提倡将应用程序划分为一组细粒度的服务，服务间采用轻量级的通信机制进行交互，从而为用户提供最终价值[2].通常，这些细粒度的微服务是具有单一职责的小程序，能够被独立地部署、扩展和测试[3-4].

与传统单体架构（monolithic architecture）相比，微服务架构（microservice architecture）具有高维护性、高扩展性、高适应性、去中心化管理、容器化的运行环境等特征，受到了工业界和学术界的大量关注[5-8]并将微服务技术视为云计算的有效补充[9].

由于微服务架构能满足大规模分布式应用期望的可扩展性、可演化性和可维护性等需求，近年来越来越多的云应用向微服务架构迁移[5,10].在国外，Amazon、Netflix、The Guardian、Twitter、PayPal、SoundCloud 等最早开始尝试将云上的软件系统微服务化.在国内，腾讯、百度、京东、淘宝、360 搜索等也陆续开始将软件系统向微服务架构迁移.例如，腾讯的微信系统[6]包含3 000 多个微服务，分布式地运行20 000 多个机器上[11].Netflix 的在线服务系统使用了大约500 个微服务，每天涉及50 亿个服务交互[12].Amazon 每个页面涉及100∼150 个微服务的调用[13].根据国际数据公司预测：到2021年，云平台上80%的应用程序将使用微服务技术开发[14].

本质上，微服务的服务化思想源于面向服务架构（service oriented architecture,SOA）[14]，但与SOA 相比，微服务存在以下显著不同的3 个方面：

1）从设计哲学的角度，SOA 的设计哲学是share-as-much-as-you-can，目的是促进松散耦合服务的高度复用[15]；而微服务是share-nothing驱动的，目的是促进紧耦合代码的进一步分离和自治，支持敏捷方法或DevOps 方法[2,16-17].

2）从通信方式的角度，SOA 架构下服务间通过企业服务总线（ESB）进行通信[15]；而服务架构下微服务间通过RESTful 或基于RPC 的API 等轻量级协议进行通信[2,18].

3）从数据共享的角度，SOA 架构下服务间共享同一数据库；而微服务架构下每个微服务可以拥有自己私有的数据库[2,19].

目前，许多学者已发表了微服务相关的研究成果.文献[20]从论文发表趋势、研究重点和产业应用潜力三个角度，对微服务体系结构的研究现状进行了识别、分类和评价.文献[9]基于2014年和2015年的研究成果，对微服务研究进行了系统地分类和比较.文献[21]对微服务系统中使用的安全机制进行了系统地识别、分类和评价.文献[22]总结了物联网应用开发中采用微服务的现状和未来研究趋势.与这些文献相比，本文采用系统评价（systematic review）的方法，对微服务技术最近五年的主要研究进行了搜集、分析和概况，以期系统了解微服务在体系结构、通信和挑战三个方面的研究现状和最新进展.

1 研究方法

本文采用系统评价方法对微服务的体系结构、通信和挑战进行综述，具体步骤如下：

步骤1研究问题.通过系统评价，本文尝试回答下述3 个问题：

1）单体架构、SOA 架构和微服务结构的主要区别；

2）微服务间的通信研究主要集中在什么方面；

3）微服务技术面临的挑战.

步骤2文献搜索.本文使用关键词"microservices" AND ("architecture" OR "communication" OR "challenges")在IEEE Xplore 搜索发表时间为2015年及以后的论文，共有745项记录.

步骤3选取标准.对于745 项记录，本文的选取标准是查看论文的题目、摘要和正文是否与系统评价的三个问题相关.首先，根据题目和摘要，检测每项记录是否与问题相关，但这种方式会选取大量不相关的记录.其次，对选取的记录采用人工方式进一步查看其正文是否与问题相关.最后，本文用“滚雪球”过程审查每个选取研究的参考文献，并将这一过程中获得的文献与前一步选择的文献相结合.

最终选取了49 篇论文，其中会议论文26 篇，期刊论文23 篇，分别如表1和2 所示.图1给出了选取会议论文2015–2019年的年份分布情况.图2为选取期刊论文2015–2020年的年份分布情况.

步骤4数据提取和分析.针对第一步提出的三个问题，本文对入选的49 篇论文进行了分类、分析和归纳总结.

步骤5完成报告.围绕三个问题，本文第2∼4 节将分别给出系统评价的分析结果.

表1 会议论文列表Table 1 List of conference papers

表2 期刊论文列表Table 2 List of journal papers

图1 历年会议论文分布情况Figure 1 Distribution of conference papers over the years

图2 历年期刊论文分布情况Figure 2 Distribution of journal papers over the years

2 体系结构

近年来，行业需求推动了软件体系架构的不断发展.软件领域出现了公共对象请求代理体系结构（CORBA）[23]、基于构件的软件工程（CBSE）[24]、单体架构[25]等体系结构.为了解耦服务端应用并提高组件的复用，20世纪90年代提出的SOA 作为一项革命性的创新成果，已成为大型企业实现跨行业需求的解决方案[15,26].随后，SOA 在21世纪初得到了广泛应用[27].近年来，微服务架构呈取代单体架构和SOA 之势，逐步成为主流的体系结构[28].

图3直观描述了体系结构的演化，从最初传统的单体架构到SOA，再到微服务架构.

在图3(a)中，单体架构将服务端应用视为一个整体应用层[29].其处理流程是前端用户接口将用户发送的请求重定向到服务端应用，而服务端应用通过与数据库的交互处理请求.

在图3(b)中，SOA 将服务端应用视为多个粗粒度服务的组合，每个服务可托管在地理位置不同的容器中运行[15].服务间通过企业服务总线进行通信组合并共享同一个数据库.

图3 软件架构的演化Figure 3 Evolution of software architectures

在图3(c)中，微服务架构将服务端应用视为多个细粒度微服务的组合，微服务间通过轻量级协议进行通信[2,18].每个微服务是高内聚的小程序，可拥有自己私有的数据库并在其独立的容器中运行[30].

由于微服务架构还没有正式的形式定义[1]，本文以代码为核心，从组件化、部署和扩展、数据存储、开发等4 个方面，对单体架构、SOA 和微服务架构进行系统对比.首先从代码解耦的角度，对比3 种架构的组件化；接着从代码运行的角度，对比3 种架构的部署和扩展；然后从数据管理的角度，对比与代码交互的数据存储方式；最后从代码开发的角度，对比3 种架构的优缺点.

2.1 组件化

组件化是构建现代Web 和云应用的关键基础之一[10].图4直观地描述了组件化的演化，从单体架构的模块到SOA 的服务，再到微服务架构的微服务.

单体架构的组件化是通过模块来实现的.单体架构将软件系统划分为不同的模块，如前端UI（用户界面）、服务端逻辑组件和数据库[31]，但各模块无法单独执行[18].前端UI 在用户设备上运行，服务器端逻辑组件在服务器上或云中运行，后端数据库存储应用程序的数据.

SOA 的组件化是通过粗粒度的服务来实现的.SOA 是一种实现关注点分离的体系结构，由不同的服务提供软件系统的功能，在企业服务总线的集中化管理下，服务间通过响应事件进行集成[32].相比单体架构下的模块，这些服务粒度可以单独运行，具有自治、自描述、可重用和高度可移植等特征[33].此外，SOA 还关注简单服务和智能路由机制[25]，这种智能路由机制的核心是中心化的管理.

微服务架构的组件化是通过高度解耦的细粒度微服务来实现的.为了进一步解耦服务端应用，微服务架构将软件系统高度解耦为微服务，微服务间通过轻量级的协议进行通信[10].与SOA 的服务相比，这些微服务粒度更小且专注于完成一个小任务[2,4].此外，微服务架构还关注智能服务和简单路由机制，反对SOA 中的集中化管理[2].

图4 组件化的演化Figure 4 Evolution of componentization

2.2 部署和扩展

图5直观地展示了单体系统和微服务系统的部署和扩展区别.单体架构要求对软件系统进行整体部署和扩展，如图5(a)所示.随着越来越多的单体系统部署到云端，这种整体部署和扩展的方式严重制约了单体系统的应用.从部署角度来看，对单体系统的任意修改都需要对系统进行整体重建和部署；从扩展角度来看，对单体系统只能进行整体扩展，无法实现部分扩展.

与单体架构相比，微服务架构支持每个微服务进行独立部署和扩展，因此对微服务系统的部署和扩展是以单个微服务为单位的，如图5(b)所示.从部署角度，对单个微服务的修改只涉及该服务的部署；从扩展角度，可根据实际需求动态扩展某个微服务的实例.

图5 单体系统和微服务系统的部署和扩展Figure 5 Deployment and scalability of monoliths and microservices

2.3 数据管理

单体架构和SOA 中都采用中心化的数据管理，即数据统一存储在一个中心数据库.这种集中式数据管理将使得技术平台趋于标准化和趋势化[1].

与单体架构和SOA 相比，微服务架构采用分布式数据管理，其概念模型和存储后端都是分布式的.具体而言，分布式的概念模型是指不同的微服务对同一世界有不同概念模型，如通过对相同实体的不同属性进行操作；分布式的存储后端是指每个服务都有自己独立的存储数据库，该数据库与其他服务的数据库是隔离的[10].与中心化的数据管理相比，这种分布式（去中心化）的数据管理有利于清晰定义每个微服务的限界上下文（bounded context），从而进一步降低微服务间的耦合度.

由于微服务系统中事务可以跨越多个微服务的数据库，因此传统解决单个数据库中事务一致性的ACID 方法不再适用于微服务系统.在这种情况下，当微服务系统出现失败事务时，如何补偿已经执行事务以确保数据的一致性是具有挑战性的.

2.4 开发

2.4.1 单体架构的优点和不足

单体架构具有如下优点：

1）开发与部署简单

单体系统的开发不仅集成工具较多且在同一个目录下执行.这种方式有利于简化开发和部署.

2）减少交叉关注

多数应用程序都依赖于大量交叉关注点，如审计跟踪、日志记录等.由于单体系统的代码基础单一且作为一个整体在容器中运行，因此系统交叉关注将大量减少.

3）性能更好

相比SOA 架构和微服务架构，单体架构因基于内存共享代码和数据而具有更好的性能.

然而，当外部环境或业务需求发生变化时，单体架构将不可避免地面临以下不足：

1）依赖地狱[34]

单体系统常常遭受“依赖地狱”的困扰.在单体系统中，添加或更新库会导致系统无法编译、运行，甚至出现不一致的行为.这种高度的依赖性使单体系统的维护和演化很难实施.

2）局部修改、整体重启

对单体系统中任何模块的任何更改都需要重新启动整个软件系统.对于大型项目，重启所需的停机时间较长.因此这种局部修改、整体重启的方式往往阻碍项目的开发、测试和维护.

3）技术锁定

单体架构要求开发人员使用开发原系统的语言和框架即技术锁定，难以使用新的技术.

4）持续交付差

技术限制和可扩展性问题导致单体系统难以持续交付，因此单体系统往往无法满足快速涌现的业务需求[32].

2.4.2 SOA 的优点和不足

SOA 是一种将孤立的软件应用程序和基础设施重组为一组相互连接的服务集的方式，服务间通过标准接口和消息传递进行通信[27].通常，SOA 具有下述优点：

1）模块化和重用[18]

复杂服务由简单服务组合而成；同一服务可以被不同的软件系统复用.

2）支持分布式开发[18]

通过遵循共同的接口标准，不同的开发团队可以并行地开发软件系统的不同部分.

3）集成异构和遗留系统[18]

SOA 使用开放的互联网标准，如简单对象访问协议（SOAP）、Web 服务描述语言（WSDL）、Web 服务业务流程执行语言（BPEL4WS）.在企业服务总线的支持下，SOA 采用标准化的方式对异构和遗留系统进行服务化的集成.

SOA 具有下述不足：

1）整体部署[32]

SOA 支持在业务流程级别上集成各种服务.这种方式虽然带来了集成的灵活性，但同时也将所有服务绑定到单个流程上下文中，进而导致整体部署[35].

2）受限的独立性[32]

SOA 主张代码间的解耦，但在实际应用中SOA 中的服务大多依赖于某些中间件或框架，这在一定程度上损害了服务的独立性.

2.4.3 微服务架构的优点和不足

微服务架构是SOA 的第二次迭代，其目的是去除SOA 中不必要的复杂程度，以便专注于实现单一功能的细粒度服务[15,18].通常，微服务架构具有下述优点：

1）高扩展性[32].

每个微服务独立开发、部署、维护，因而微服务系统具有高扩展性.高扩展性是指可根据负载需求，灵活扩展某个微服务的实例，而非整个微服务系统[18,36].同时，高扩展性能更好地支持资源动态分配[37].

2）高维护性[4]

微服务的小规模有助于提高代码的可理解性和可维护性[30].更改某个微服务只需重启运行该微服务的容器，而非重启整个微服务系统.因此微服务系统易于维护和升级.

3）高弹性[4]

微服务系统的某个微服务出现故障，不会影响整个系统.

4）低依赖性[9]

由于每个微服务具有限界的上下文且独立地实现和部署，微服务系统能消除各种依赖性问题，减少错误级联.

5）有效支撑DevOps[2]

每个微服务可以由不同的小团队开发，这有利于DevOps 方法的有效实施[38].

6）技术异构性[18]

每个微服务使用不同的编程语言和数据存储，允许技术异构性.

与此同时，微服务架构也带来了很多复杂性：

1）复杂的开发

微服务系统本质上是并发分布式系统，而开发并发分布式系统本身就是很复杂的.

2）复杂的通信拓扑[39]

微服务系统通常包含成百上千个微服务，微服务间的交互所形成的拓扑结构是非常复杂的.

3）复杂的故障诊断

有效检测微服务的故障是确保微服务系统正常运行的关键.但准确定位微服务的故障是困难的：一是微服务通常会有多个运行实例，难以准确定位是哪个运行实例出现了故障；二是一个请求通常涉及多个微服务间的交互和通信，难以准确定位哪个交互出现了故障[40].

基于上述分析和概括，对单体架构、SOA 和微服务架构进行比较如表3所示.

表3 单体架构、SOA 和微服务架构的比较Table 3 Comparison of monoliths,SOA and microservices

3 通 信

软件系统从单体架构演化到微服务架构，最大的改变在于通信方式.在单体架构中，软件系统运行在单个进程上.在单机环境下，组件间使用内存函数调用的方式进行交互和通信.在微服务架构中，软件系统的运行环境由单机环境改变为分布式环境.在分布式环境下，微服务间通过服务接口进行交互和通信[41].与基于内存函数调用的交互相比，这种交互本质上是进程间的通信[42].

根据交互模式，微服务间的通信可分为同步通信和异步通信[41].同步通信是一种阻塞通信模式：一个微服务发送者向另一个微服务接收者发送请求，并等待该接收者响应[43].异步通信是一种非阻塞通信模式：一个微服务发送者向另一个微服务接收者发送请求，并不等待该接收者的响应[44].

在微服务系统中，由于同步通信容易引起停机倍增效应，所以微服务间的交互大多以异步通信为主[39].因此本节重点关注异步通信.

3.1 异步通信模型

尽管同步通信能为用户提供及时响应，但异步通信能为微服务系统提供最大的弹性和可扩展性.具体而言，异步通信模型可分为基于消息队列（message queuing）的异步通信模型和发布订阅（publish subscribe）式异步通信模型[45].

3.1.1 基于消息队列的异步通信模型

消息队列在异步通信中起着重要的通信通道作用，通常被称为面向消息的中间件[46].在基于消息队列的异步通信模型中，消息被持久化在队列中.一个或多个消息接收者可以消耗队列中的消息，但特定消息最多只能被一个消息接收者所消耗.消息按先进先出的方式进出队列.一旦消息接收者从队列中消耗了消息，则该消息就从队列中消失.

基于消息队列的异步通信模型可进一步划分为邮箱式异步通信模型[47]和点对点式异步通信模型[48]，如图6所示.

在图6(a)中，邮箱式异步通信模型要求所有发送给微服务3的消息（微服务1和微服务2生成的消息）存储在队列3中的末尾，而微服务3从队列3 的头部取出需要消耗的消息.这种通过队列缓存消息的方式称为先进先出式[47-48].

在图6(b)中，点对点式异步通信模型要求从微服务1 发送给微服务2 的每条消息以先进先出方式存储在队列12 中，且队列12 只用于存储微服务1 发送给微服务2 的消息.换言之，每个微服务需要为来自其他微服务的发送消息配备不同的队列.

图6 基于消息队列的异步通信模型Figure 6 Message queuing asynchronous communication model

3.1.2 基于发布订阅的异步通信模型

在基于发布订阅的异步通信模型中，消息被持久化在主题中.消息接收者可以订阅一个或多个主题并使用该主题中的所有消息，如图7所示.通常消息发送者称为发布者，消息接收者称为订阅者.在图7中，微服务1 称为发布者，微服务2∼4称为订阅者.

图7 基于发布订阅的异步通信模型Figure 7 Publish-subscribe asynchronous communication model

3.2 协议

3.2.1 REST

REST 本质上是一种架构风格，其中表现层状态转化是一组架构约束和原则[36,49].而满足这种架构风格的软件系统体系结构被认为是RESTful 的.RESTful 体系结构强调：1）使用URI 来定位资源；2）通过表现层进行资源操作，资源可以是XML、JSON、二进制文件等；3）客户端通过使用4 种HTTP 动词（GET、POST、PUT、DELETE）使服务器端发生表现层状态转化[50].RESTful API是指一种API，它使调用资源非常方便和直观，同时也降低了服务的复杂性[51].

当前存在许多支持同步消息传递的中间件标准，例如Corba 的IIOP 协议、Java 远程方法调用（RMI）和简单对象访问协议（SOAP）.相比这些标准，REST 具有简单性、高性能和无状态性等优点.因此，微服务系统中的同步通信更多采用REST协议[52]，并具有更少的计算开销[53-54]和更好的移动性[55].

3.2.2 AMQP（advanced message queuing protocol）

Java 消息服务（JMS）仅仅是一个接口或API 标准，而非指定的标准协议[56].为了创建可互操作的企业级异步消息传递的开放标准，2014年，结构化信息标准促进组织（organization for advanced structured information systems,OASIS）将AMQP 作为一套标准发布，并被国际标准化组织/国际电工委员会（ISO/IEC）所采纳.

AMQP是一个分层的体系结构本质上，AMQP是基于二进制的协议，并具有以下两个显著的特点：

1）责任链模式[56]

在这个模式中，从发送者流向接收者的消息实际上是通过位于两者之间的一组消息处理器来传递的.消息传递过程中，每个消息处理器对消息进行操作（添加操作、修改操作、拒绝操作），并将处理后的消息传递给下一个消息处理器.

2）协议模型[56]

与典型的消息传递系统相比，该协议模型最大的不同在于使代理能够有效地做出路由决策.在典型的消息传递系统中，决定从哪个队列生成或消耗消息的逻辑是嵌入到使用该队列的应用程序中的.

目前，AMQP 协议可用于支持基于消息队列的异步通信模型和基于发布订阅的异步通信模型.

3.2.3 其他协议

可扩展消息出席协议（extensible messaging and presence protocol,XMPP）是一种基于XML 的通信标准，用于面向消息的中间件通信.其核心规范包括RFC 6120[57]RFC 6121[58]、RFC 7622[59].

消息队列遥测传输协议（message queuing telemetry transport,MQTT）由IBM 开发后贡献给结构化信息标准促进组织（OASIS）.目前，该协议已成功应用于物理网领域的各种嵌入式系统中.

3.3 消息格式

目前存在两种流行的消息格式：文本型的消息格式和二进制的消息格式.

文本型消息格式包括JSON（JavaScript Object Notation）和XML（Extensible Markup Language）.其中，JSON 的标准定义包括标准化组织（ECMA International）发布的Ecma-404[60]和互联网工程任务组（IETF）发布的RFC 7159[61].XML是W3C标准支持的消息格式，它是从SGML（ISO 8879）派生的一种简单和灵活的文本格式.文本型消息格式的优点是自描述的和可读性强，而缺点是消息会变得冗长使文本序列化/反序列化将影响内存和带宽[62].

二进制的消息格式包括Thrift[62]和Protocol Buffers[63].Thrift 是Apache 的开源软件框架，用于开发跨语言和跨平台的低开销服务，现有超过15 种语言支持[64].Protocol Buffers 是Google 公司内部使用的一种与平台和语言无关的消息格式，提供了C++、Java、Python 三种语言的API.相比JSON 和XML，二进制表示的消息需要更少的内存、带宽和处理，在移动服务消耗方面也优于文本表示的消息[65].

3.4 实现框架

当前，微服务系统中大量使用的异步通信框架包括：Kafka、RabbitMQ、Google Pub/Sub、Amazon Services、ActiveMQ.

Kafka 是目前最流行的开源分布式发布订阅流平台，每分钟可以处理数百万条消息.

RabbitMQ 消息传递模型的核心思想是：生产者将消息发送到消息交换机（exchanges），而非将消息发送到队列.

Google cloud Pub/Sub 是谷歌公司发布的开放实时消息API，用于支持在不同的应用之间发送和接收消息.通过发布/订阅模型将消息的发送者和消息的接收者进行分离.

Amazon Simple Queue Service (Amazon SQS)是亚马逊公司提供的一个分布式的消息队列服务，支持标准队列和FIFO 队列；Amazon Simple Notification Service (Amazon SNS) 是亚马逊公司提供一项消息推送服务，遵循发布/订阅模式.

ActiveMQ 是Apache 发布的一款开源消息中间件，用于支持企业级消息通信.

表4从消息队列、发布定义、是否开源、支持的编程语言和支持的主要协议5 个方面对上述框架进行了比较.

表4 不同框架的比较Table 4 Comparison of different frameworks

4 挑 战

4.1 数据一致性

尽管微服务系统具有灵活性和高扩展性，但如何确保系统中数据的一致性是具有挑战性的[66].在单体系统中，数据集中存储于同一数据库；而在微服务架构中，数据分布在不同微服务的数据库中，如何跨多个数据库确保事务的一致性是急需解决的关键问题[19,32].

显然，传统解决单一数据库中数据一致性的方法并不适用于微服务系统[67-68].目前在微服务的上下文中有两种解决数据一致性的方法：

1）基于克隆的方法

每个微服务均创建一个原数据库的克隆，以独立的方式与自己私有的数据库进行交互[69].私有数据库的每个更新将通过广播的方式通知其他克隆数据库，以确保各数据库间数据的一致性.该方法的缺点是需要占用更多的资源来存储数据[19].

2）基于私有数据库的方法

每个微服务拥有自己私有的数据库[3].如文献[70]提出了切片模式，根据每个微服务的业务边界，将统一的中心数据存储划分为一组水平切片.但该方法面临的主要挑战在于对不同数据库中的数据进行连接操作时，如何确保数据间的一致性[19].

4.2 调试

微服务系统本质上是并发分布式系统.通常，调试并发分布式系统的有效方法是跟踪和可视化系统的执行[73].与传统的并发分布式系统相比，微服务系统更具复杂性和动态性[74]，具体如下：

1）在大量的节点上（如物理机或虚拟机）运行大量的微服务实例，且微服务实例的分布也在不断变化，给微服务间的通信带来很大的不确定性[75].

2）微服务系统涉及复杂的环境配置，不正确或不一致的环境配置将导致运行时的故障[39].

3）微服务间涉及大量复杂的异步交互.这些异步交互涉及复杂的调用链，容易导致不恰当的协作，进而导致运行时的故障[74].

4）由于微服务实例可以动态创建和销毁，因此在微服务系统中微服务和系统节点之间缺乏对应关系[75].

这些高复杂性和动态性给调试微服务系统带来了众多挑战[71,75].文献[74]指出当前调试微服务系统在很大程度上取决于开发人员对系统和类似故障案例的经验，并主要依靠手动方式检查日志.

4.3 监控

对微服务系统进行性能监控和分析是具有挑战的[76].在微服务架构中，影响性能的主要因素是网络通信.通常，执行微服务系统的某个业务功能需要涉及大量微服务间的交互和协作.在这些交互中，任何一个微服务的响应延迟或慢响应都可能导致整个软件系统性能下降.

由于微服务架构提倡服务的重用，微服务系统中将包含第三方服务[77].如何对第三方服务进行安全监控是面临的另一个挑战.

4.4 安全问题

微服务架构的核心思想是将应用程序的复杂性分布在独立可部署的微服务间.但服务间以及服务和数据间的复杂依赖也给微服务系统带来安全问题[71].

1）更大的攻击面.相较传统的单体系统，微服务系统暴露出了更多的潜在攻击.因为微服务系统由多个微服务组成，而这些微服务在网络中都将暴露API 以便通信和交互.这无疑给攻击者提供了更多的漏洞点来扩大攻击面[71].此外，微服务结构鼓励使用现成的OTS(off-the-shelf) 组件来实现重用，但部署OTS 组件本身就容易带来安全威胁.

2）基于可信计算基础的攻击.基于微服务系统的可信计算基础是所有的微服务彼此信任对方[72].因此，假如一个攻击者获得某个可信微服务的控制权，则通过服务间的信任和依赖关系很容易传播攻击，进而造成整个应用程序崩溃.也就是说，一个微服务被攻破可能导致整个应用程序的崩溃[72].

3）数据被伪造或篡改.当微服务系统采用一组数据切片时，如何防止各个数据切片内的数据被伪造或篡改是至关重要的.

4）通信消息被伪造或篡改.在没有集中式的控制下，微服务间采用基于消息通信的方式进行交互和协作.由于通信消息可能会被伪造或篡改，因此，如果这些消息通信没有考虑安全保护，则服务间的交互和协作是不安全的.

5）监控安全性的难度增加.微服务间大量交互带来的网络复杂性大大增加了监控整个软件系统安全性的难度[72].一方面，这种网络复杂性决定了对整个软件系统的调试、监控、审计和鉴证分析的难度不断增加；另一方面，攻击者可以利用这种复杂性对软件系统发起攻击.

6）未授权的访问.由于微服务系统中存在大量的微服务，如何防止其他微服务未经授权的访问是一项严峻的挑战[32].

5 结 语

本文从体系结构、通信和挑战三个维度对微服务技术的研究现状和最新进展进行分析和概况.首先，从体系结构角度，从组件化、部署和扩展、数据管理及开发4 个方面系统比较了单体架构、SOA 和微服务架构.其次，从异步通信模型、协议、数据格式和实现框架4 个方面概述了微服务间的通信.最后，列举了微服务技术面临的4 个技术挑战：数据一致性、调试、监控和安全.