微服务若干关键问题研究

邓杰文，曹彩凤



微服务若干关键问题研究

邓杰文，曹彩凤

（五邑大学 计算机学院，广东 江门 529020）

微服务软件架构正处于探索和兴起阶段，亚马逊、Netflix等互联网巨头的成功案例表明微服务在大规模的企业应用中有较明显优势. 本文介绍了微服务架构的原理，分析其优势和不足；对微服务实践过程中遇到的若干关键问题及解决方案进行探讨；为满足一般教务系统弹性可伸缩的需求，设计了基于微服务的架构方案，在架构设计层面解决了系统应用过程中出现的性能瓶颈问题.

微服务；软件架构；单体式应用

微服务（Microservices）[1]一词最早在2011年由威尼斯的一个软件架构小组提出，用以表示当时出现的一种流行的软件架构风格，2012年，该小组将其命名为微服务. 同年，James[2]在波兰展示了微服务的案例. Netflix公司的Adrian称“微服务是细化的SOA，是Web领域一种先进的架构风格”[3]. 此后，陆续有互联网公司尝试使用类似架构并取得了成功，尽管它们不一定都称其为微服务，典型的有Amazon[4]，Netflix[5]，Uber[6]，Groupon[7]等. 本文拟对微服务实践中的关键问题进行探讨，提出解决方案，为以后微服务系统的设计与实现提供更多理论指引.

1 微服务的定义

微服务还没有一个统一的定义，Martin[8]认为“微服务是一种软件架构风格，它把复杂的应用分解为多个微小的服务，这些服务运行在各自的进程中，使用与语言无关的轻量级通信机制（通常是基于HTTP的REST API）相互协调，每个服务围绕各自的业务进行构建，可使用不同的编程语言和数据存储技术，并能通过自动化机制独立部署，这些服务应使用最低限度的集中式服务管理机制”.

与微服务相对的是单体式（Monolithic）应用架构，它把所有业务作为一个整体来构建和部署，一个典型的Web应用可能包含了与用户交互的前端、后端业务逻辑和数据库3部分，尽管都会使用模块化设计，但最终该应用都会被构建为一个整体来部署，运行在单一进程中. 如一个Java Web应用会被打包为一个War文件部署在Tomcat中. 单体式架构的优点显而易见：构建、测试简单，因为现有IDE都是针对单体应用设计的；部署容易，只要把压缩包拷贝到相应目录即可. 但当应用的规模越来越大时，其缺点就越发明显：1）开发效率越来越低，因为几乎没有开发者能全面了解如此庞大的应用，即使修改一行代码也要重新编译部署整个应用；2）持续交付的周期越来越长，现今的敏捷开发要求快速响应变化，及时获取客户反馈，缩短迭代周期，而单体应用都是整体部署，所以需等各模块均修改完成后方可交付部署，无法满足短时间多次部署的要求；3）技术选型成本高，单体式应用自始至终使用同一种技术栈，系统规模越大，转型越困难，无法享受新技术的便利，也给开发人员的招聘带来限制；4）可伸缩性差，对于单体应用通常只能实现纵向伸缩[9]，通过部署应用实例的集群，然后使用负载均衡器把用户请求分发到不同节点上来实现，但如果要提高某些模块的性能或吞吐能力，实现横向伸缩则很困难，因为单体应用是所有模块整体运行在一个进程中的.

2 微服务的优势和不足

微服务的思路是把单一的巨大应用拆分为众多松散耦合的微小服务，其通常是按照业务功能来分解的，每一个服务虽然微小但却实现相对完整的功能，使用私有的数据库，可以单独构建和部署，某个服务的修改和部署不会影响其他正在运行的服务，提供语言无关的API接口供其他模块调用. 这种风格与传统的面向服务架构SOA[10]比较相似，经过多年的发展，SOAP、Web Services、ESB[11]等技术出现使SOA得以实现，众多厂商也制定了相关的标准. 两者最重要的区别在于SOA使用复杂的ESB集成为单一应用，而微服务是轻量级的，不使用复杂的ESB，松散耦合，可以独立部署.

微服务架构在规模较大的应用中具有明显优势. 首先体现在独立性方面，服务是松散耦合的，有明确的系统边界，各开发团队可以并行开发和部署，避免了牵一发而动全身，提高了效率. 其次是技术选择灵活，可针对具体业务特性和团队技能为一个服务选择最合适的语言、框架和数据库，各服务使用不同的技术栈，技术转型的成本也大为降低. 再次是系统伸缩更自由，可针对某些服务单独进行伸缩，实现系统三维度伸缩[12]. 最后是服务可独立部署，借助自动化构建和部署工具，为DevOps[13]的实施提供更好的支持.

当然，微服务的优势也是有代价的. 第一显而易见的是性能问题，微服务应用中每个服务运行在独立进程中，服务间的调用需要通过网络传输，当众多服务需要相互调用时，就要考虑网络延迟对系统性能的影响，Villamizar[14]等人研究认为通常的应用（包含若干个微服务），系统响应时间差距不远. 但当应用包含成百上千的服务时，远程调用的性能损耗是一个要解决的关键问题. 第二，微服务本质上就是一个分布式应用，分布式系统固有的可靠性等问题随着微服务数量的增加变得越来越突出. 第三个也属于分布式系统的问题，如何保证数据一致性，微服务使用非集中式的数据管理，要解决数据一致性[15]问题比起单体式应用要困难得多.

3 微服务的关键问题分析

采用微服务架构的应用是一个分布式的应用，相对于单体式应用其实是更复杂了，在展示出其特有的优越性同时，还需解决好若干关键问题.

3.1 服务间通信问题

微服务是一个分布式系统，服务被部署在不同节点中，服务的交互需要通过网络进行通信，因此服务间如何通信是一个需考虑的问题，它会直接影响着系统的性能. 按交互模式分可把服务间通信分为同步的请求响应模式与异步的消息模式两种. 同步模式由于要等待对方响应，所以当有多个调用时总时延是各调用时延之和. 而异步模式由于不用等待响应，所以总时延是各调用时延的最大者，大大改善了性能. 异步模式虽可改善响应时间，但模式要根据实际的业务功能进行选择，实际的应用经常会同时使用这两种模式. 同步模式实现可以使用基于HTTP的REST或Thrift[16]，使用REST的好处是简单，与语言无关，开发门槛低. Thrift则支持多种语言的远程调用，可用二进制传输数据，在高并发、大数据量情况下更具优势. 至于异步模式可借用众多成熟的消息系统，如RabbitMQ、ActiveMQ、Apache Kafka等，它们都支持多种语言接口，并且提供持久化的、异步的、高性能的消息通信机制. 对于复杂的微服务应用，使用消息系统的优势很明显，它实现了服务间的解耦，并且解决了分布式系统中的可靠性问题. 但使用消息系统令开发变得更加复杂，还需要额外的配置与维护，增大了部署运维的难度.

另一个提高服务间通信效率的方法是使用API网关. 考虑如下场景，一个微服务应用既支持Web网站又支持手机原生应用，各微服务通过API接口对上述两客户端提供后台服务. 展示手机上一屏画面可能就需要调用多个后台微服务，因为移动设备与微服务不是处于局域网中且其网络带宽通常较低，这种频繁的调用会令时延增加直至严重影响用户体验. 一种解决方法是在微服务前增加一个API网关服务，把多个细粒度的调用归并为一个粗粒度的服务供客户端调用，一次提供所有需要的结果. 由于API网关与其他微服务同处局域网，因此调用时延低且不会消耗客户端流量. 一个微服务应用的结构通常如图1所示.

图1 微服务应用结构图

3.2 服务发现问题

当一个服务需调用另一个微服务时，如何定位其网络位置又是一个需解决的关键问题. 出于系统伸缩的需要，微服务会有多个实例，它们被部署在一台或多台虚拟机中，网络位置是动态生成并有可能变动的，因此需要一种服务发现机制. 目前有两种解决方案，客户端发现和服务端发现. 客户端发现机制类似DNS解析，由客户端向服务注册表查询服务位置，并使用负载均衡算法从返回的实例中选择其一再向其发起调用. 服务实例启动时向服务注册表注册自己的位置，并发送心跳信号表明自己没有失效. 这种机制易于理解，但每个客户端都需编写服务查询代码. 服务端发现机制中，客户端请求是发给负载均衡器的，由其查询和选择服务实例并转发请求，因此客户端无需操心服务查询. 但负载均衡器必须是高可用的，否则容易成为系统瓶颈，因为它承载了所有的请求转发. 实例的注册也可以使用前述的自注册方式. 还有一种第三方注册方式，系统中有一个注册管理服务负责监控服务实例，当有新的实例启动时就向注册表注册该服务，当实例失效时注销该实例，这样服务实例就免去了编写自注册的代码. 但第三方注册方式需要系统处于一个集中式的实例管理环境中才可行. 另外，服务注册表本质上是一个高可用的数据存储，当系统规模较大时需要使用集群，目前已有满足这种分布、可靠、高可用条件的开源实现，如etcd[17]，consul和ZooKeeper[18].

3.3 服务部署问题

微服务的部署方式是另一个关键问题，有几种常见的方法：第1种是微服务实例都部署在一台或多台虚拟机或物理主机中，不需特别的隔离方法，只要保证每个微服务拥有不同的网络端口或位置即可. 如Java Web应用可以让多个微服务的War文件都部署在同一个Tomcat中. 这种方法简单直接，共享系统资源，利用率最高，但缺点是由于服务间没有隔离，某个服务的崩溃可能会影响其他服务的正常运行，或者某个服务错误地掠夺了共享的系统资源；第2种方法是让每个微服务实例运行在单独的虚拟机中，这种方法隔离最彻底，相互不受影响，并可以控制每台虚拟机使用资源的额度，对某个服务进行伸缩也很简单，缺点是虚拟机启动较慢，且较消耗系统资源；第3种方法得益于容器[19]技术如Docker[20]的发展，是让每个微服务实例运行在一个容器中，每台虚拟机可运行一个或多个容器实例. 容器属于操作系统层面的虚拟化，提供了类似虚拟机的隔离环境，但却共享操作系统内核，其占用资源少，启动速度快. 这种方法的优点是使得服务间能相互隔离，系统的资源利用率也较高. 对于这种方法可以使用容器集群系统来进行管理，常用的有Google Kubernetes[21]、Docker Swarm和Mesos，它们兼具了服务发现功能，大大减轻了微服务部署和伸缩的难度. 这3种方法都能应对系统伸缩的要求，需要扩展某服务性能时，只需部署更多实例就可以了.

4 方案应用

针对一般教务系统应用过程中出现的性能瓶颈问题，对其核心架构进行设计. 教务系统用户可分为3类：学生、教师与教辅人员，学生主要使用场景是评教选课与成绩查询，教师主要使用场景是成绩录入与开课查询，教辅人员主要使用场景是教务信息管理等. 评教选课与成绩查询集中在开学初与学期末，由于学生人数众多，使用时间高度集中，因而系统负载很高，但其余时间访问却几乎为零. 教师成绩录入也是高度集中在学期末. 因此，需要使用一种可单独对这些服务弹性伸缩的方案，以提高资源利用率，微服务架构可以满足以上需求，系统核心架构如图2所示.

图2 教务系统核心架构图

教务系统分解为评教选课服务、开课查询服务、成绩录入服务、成绩查询服务及其他若干服务. 采用每个服务实例部署在一个Docker容器的部署方式，以提高系统资源利用率，容器则运行在云主机或物理主机中. 由于需要容器集群，所以选用了Kubernetes这个开源的容器集群管理系统. Kubernetes属于集中式的容器管理环境，它使用etcd实现服务发现功能，只要做一些配置即可解决服务发现问题，各服务无需自己实现服务注册、查询功能，适合教务系统这种规模较小的应用. 评教选课与成绩录入服务类似，在特定时段需要根据负载增加集群实例，集群作为一个调度单元通过REST API对外提供服务. Kubernetes的服务代理兼具了简单的负载均衡功能，使用随机算法把服务请求转发到服务调度单元的其中一个实例，当系统负载较高时服务代理容易成为瓶颈，可根据需要增加一个专门的负载均衡服务进行替代. 每个服务使用私有的数据库，上述两个服务选用MongoDB集群. MongoDB是一个高性能、易于集群的NoSQL数据库，部署相对简单. 服务间通信同时使用同步及异步两种模式. 因为本系统服务间没有高频次的通信需求，所以同步选用开发门槛低且通用性较好的REST HTTP. 评教选课与开课查询两个服务各自使用自己的数据库，选课的数据是需要同步到开课查询数据库的，但选课数据的更新可能非常频繁，如果实时同步的话开课查询服务负载就会过高，所以使用异步的消息队列来进行缓冲，并对两个服务进行了解耦，当评教选课数据更新后使用异步消息通知开课查询服务即可. 成绩录入与成绩查询服务的设计也跟上述类似.

本系统没有使用API网关的方式，原因是系统不存在大量服务间的相互调用，客户端的移动应用直接调用各服务模块，并不会带来太大的性能问题. 可以发现，应用微服务架构的教务系统比单体式系统要复杂，但好处是服务间相互隔离，系统某些部分可以弹性伸缩，提高了资源的利用率，而单体式系统只能整体迁移到性能更强的主机上，否则资源的争夺就会影响系统所有模块的使用.

5 结束语

本文阐述了正在兴起的微服务软件架构原理，与传统单体式应用架构相比，微服务能明显降低系统耦合度，提高系统可扩展性，增强系统持续集成能力，在大规模企业应用中优势明显. 针对微服务实践中的服务间通信，服务发现和服务部署3个关键问题进行了研究，提出了各场景下的解决方案并分析其优劣，为微服务系统的设计提供了更多理论指引. 最后应用具体的方案设计了基于微服务架构的教务系统，提供了弹性伸缩的能力，在架构设计层面解决了性能瓶颈问题. 后续我们将就该方案进行具体实现与测试验证.

[1] 王磊. 微服务架构与实践[M]. 西安：电子工业出版社，2015.

[2]JAMES L. Micro services-Java, the Unix Way [EB/OL]. (2012-03-21) [2015-07-21]. http://2012.33degree.org/ pdf/JamesLewisMicro Services.pdf.

[3] JAMES L. Microservices [EB/OL]. (2014-03-25) [2015-08-29]. http://martinfowler.com/articles/microservices. html.

[4] O’HANLON C. A conversation with Werner Vogels [J]. Queue, 2006, 4(4): 14-22.

[5] ADRIAN C. State of the Art in Microservices [EB/OL]. (2014-12-15) [2015-04-22]. https://blog.docker.com/ 2014/12/dockercon-europe-keynote-state-of-the-art-in-microservices-by-adrian-cockcroft-battery-ventures/.

[6] EINAS H. Service-oriented architecture: scaling the uber engineering codebase as we grow [EB/OL]. (2013-10-30) [2015-07-05]. https://eng.uber.com/soa/.

[7] ADAM G. I-Tier: dismantling the monolith [EB/OL]. (2013-10-30) [2015-06-23]. https://engineering.groupon. com/2013/misc/ i-tier-dismant ling-the-monoliths/.

[8] FOWLER M, LEWIS J. Microservices [J]. Viittattu, 2014, 28: 2015.

[9] ABBOTT M L, FISHER M T. The art of scalability: scalable web architecture, processes, and organizations for the modern enterprise [M]. [S.l.]: Pearson Education, 2009.

[10] ERL T. Service-oriented architecture (SOA): concepts, technology, and design [J]. Concepts, 2005, 118(2): 33-37.

[11] SCHMIDT M T, HUTCHISON B, LAMBROS P, et al. The enterprise service bus: making service-oriented architecture real [J]. Ibm Systems Journal, 2005, 44(4): 781-797.

[12] FISH. Splitting applications or services for scale [EB/OL]. (2008-05-08) [2015-09-21]. http://akfpartners.com/ techblog/2008/05/08/sp litting-applications-or-services-for-scale.

[13]BASS L, WEBER I, ZHU Liming. DevOps: A software architect’s perspective [M]. Sydney: Addison-Wesley Professional, 2015.

[14] VILLAMIZAR M, GARCES O, CASTRO H, et al. Evaluating the monolithic and the microservice architecture pattern to deploy web applications in the cloud [C]//2015 10th Computing Colombian Conference, Bogota: IEEE, 2015.

[15] VIENNOT N, LECUYER M, BELL J, et al. Synapse: a microservices architecture for heterogeneous-database web applications [C]//Proceedings of the Tenth European Conference on Computer Systems. New York: ACM，2015: 21.

[16] SLEE M, AGARWAL A, KWIATKOWSKI M. Thrift: scalable cross-language services implementation [R]. [S.l]: Facebook White Paper, 2007.

[17] ONGARO D, OUSTERHOUT J. In search of an understandable consensus algorithm [C]//2014 USENIX Annual Technical Conference (USENIX ATC 14). Philadelphia: USENIX 2014: 305-319.

[18] SIMPLICITY. Service discovery overview [EB/OL]. (2015-06-10) [2015-07-22]. http://www.simplicityitself. io/getting/started/with/microservices/2015/06/10/service-discovery-overview.html.

[19] SOLTESZ S, POTZL H, FIUCZYNSKI M E, et al. Container-based operating system virtualization: a scalable, high-performance alternative to hypervisors [J]. ACM SIGOPS Operating Systems Review, 2007, 41(3): 275-287.

[20] MERKEL D. Docker: lightweight linux containers for consistent development and deployment [J]. Linux Journal, 2014(239): 2.

[21] BREWER E A. Kubernetes and the path to cloud native [C]//Proceedings of the Sixth ACM Symposium on Cloud Computing. New York: ACM, 2015: 167.

[责任编辑：韦 韬]

Research on Some Key Problems of Microservices

DENGJie-wen, CAOCai-feng

(School of Computer Science, Wuyi University, Jiangmen 529020, China)

The microservice software architecture is in the stages of exploration and rise. The successful cases of Amazon, Netflix and other Internet giants show microservices have obvious advantages in terms of large-scale enterprise applications. This paper introduces the principle of microservices architecture and analyzes its advantages and disadvantages. Some key problems encountered in the practice of microservices are discussed and some solutions are researched. In order to meet the elastic scalability requirements of general educational administration systems, a microservices-based architecture is designed. At the architecture design level it solves the performance bottleneck problems encountered in practice.

microservices; software architecture; monolithic application

1006-7302（2016）02-0049-06

TP311.1

A

2016-2-29

邓杰文（1977—），男，广东罗定人，硕士，讲师，研究方向为软件架构与软件组件技术.