微服务架构研究概述
2019-10-15李春霞
摘 要：目前对微服务软件架构的研究正处于探索阶段，Amazon、Netflix等互联网巨头的成功案例表明微服务架构在大规模企业应用中具有明显优势。通过对单体架构应用与微服务架构的对比，对微服务软件架构研究现状进行综述，介绍微服务架构的概念、优势、设计模式等，分析微服务软件架构面临的问题与挑战，总结微服务架构与单体架构的适用场景。
关键词：微服务;软件架构;单体架构
DOI：10. 11907/rjdk. 182825 开放科学（资源服务）标识码（OSID）：
中图分类号：TP303 文献标识码：A 文章编号：1672-7800（2019）008-0001-03
Research Overview of Microservices Architecture
LI Chun-xia
（Institute of Information Science and Engineering，Ocean University of China，Qingdao 266100，China）
Abstract： At present， the microservices software architecture is in the stages of exploration and rise. The successful cases of Amazon， Netflix and other Internet giants show that microservices architecture have obvious advantages in large-scale enterprise applications. In this paper， by comparing to monolithic architecture application， microservices software architecture for the current research status were reviewed. This paper introduces the principle， development and design patterns of microservices architecture， then analyzes its advantages and disadvantages， and summarize the applicable scenarios of microservices architecture and monolithic architecture application in the end.
Key Words： microservices; software architecture; monolithic architecture
作者簡介：李春霞（1993-），女，中国海洋大学信息科学与工程学院硕士研究生，研究方向为高性能计算。
0 引言
随着互联网用户群体的日益扩大、互联网技术的不断革新以及线上业务的快速增长，近年来互联网的发展十分迅猛[1]。互联网用户群体的不断增加也促进了新型网站的研究与开发，各种购物网站、社区论坛以及直播网站等层出不穷。随着各网站活跃用户数量与访问量的日益增长，互联网后台技术面临着巨大考验。Java Web[2]、Yii[3]、Rails[4]框架等是目前比较流行的互联网后台实现方案。其中，Java Web入门简单，是现阶段非常流行的轻量级框架，解决了老式EJB[5]（Enterprise JavaBean）开发难度大、维护成本高、部署困难等诸多问题。但随着用户群体的不断扩大、用户范围越来越广，用户的业务需求也持续增加，因此对互联网软件开发速度提出了非常高的要求，即使轻量级的Java Web也难以满足市场快速变化的需要。为了提高软件开发速度，快速抢占市场，各大型互联网公司投入大量时间、精力进行软件架构转型，寻找最敏捷的架构开发方式，以适应当前的互联网发展态势。因此，如何以最短时间、最低成本开发出一套稳定、健壮且具有良好可扩展性的后台系统以满足企业特定需求，成为各互联网企业系统开发的首要任务。
在Java Web开发模式中，中小型企业一般选择传统的单体应用架构开发方式，例如SSH[6]或SSM[7]。这种单体应用架构开发方式除容器外，基本没有外部依赖，将应用程序代码编译后打包成一个独立单元，可以是JAR、WAR或其它归档格式，并部署在一个JEE[8]容器里，包含了DO/DAO、Service、UI等所有逻辑。当程序运行时，所有功能都运行在同一台机器的同一进程中，没有考虑负载均衡与业务需求水平扩展的情况。借助于单体架构应用易于开发、测试与部署，便于共享以及易于水平伸缩的优势，开发人员可以迅速开发出满足企业初期功能需求，且具有一定访问承载量的后台初始版本[9]。但随着业务范围的不断扩大，系统功能模板数量将进一步增加，系统中的代码耦合会越来越严重，系统的可维护性、扩展性、灵活性将逐步降低，对项目作进一步修改、开发、部署及测试的压力会不断增大，使得单体应用架构的缺点越来越明显地暴露出来。随着应用程序维护成本不断增加，并且新人培养周期长、技术选型成本高，最终造成构建全功能团队难，持续交付周期长[10]。因此，单体架构应用的优势已逐渐无法满足互联网时代快速变化的需要，面临着越来越多挑战[11]。
微服务[12]架构是近期软件应用领域的热门概念，是一种新的架构风格。通常一个大型复杂软件应用由一个或多个微服务组成，系统中每个微服务仅关注一件任务，并且能很好地完成任务。各微服务可以独立部署，微服务之间是松耦合的，各服务之间相互协调、配合，为企业与用户提供最终价值。近年来，随着云计算技术的进步与服务量的不断增长，利用其优势，微服务正在为敏捷部署以及复杂企业应用实施提供巨大帮助。
1 微服务架构概述
微服务架构[13]将一个大型的单个应用或服务拆分成多个微服务，可扩展单个组件而不是整个应用程序堆栈，从而满足服务等级协议。微服务架构围绕业务领域将服务进行拆分，每个服务可以独立进行开发、管理和迭代，彼此之间使用统一接口进行交流，实现了在分散组件中的部署、管理与服务功能，使产品交付变得更加简单，从而达到有效拆分应用，实现敏捷开发与部署的目的（见图1）。Amazon[14]、Netflix[15]等互联网巨头的成功案例表明微服务架构在大规模企业应用中具有明显优势[16]。
图1 单体架构与微服务架构
1.1 复杂应用解耦
微服务架构将单一模块应用分解为多个微服务，同时保持总体功能不变。应用按照业务逻辑被分解为多个可管理的分支或服务，避免了复杂度的不断积累。每个服务专注于单一功能，通过良好的接口清晰表述服务边界。由于功能单一、复杂度低，小规模开发团队完全能够掌握，易于保持较高的开发效率，且易于维护。
1.2 独立
微服务在系统软件生命周期中是独立开发、测试及部署的。微服务具备独立的运行进程，每个微服务可进行独立开发与部署，因此在大型企业互联网系统中，当某个微服务发生变更时无需编译、部署整个系统应用。从测试角度来看，每个微服务具备独立的测试机制，测试过程中不需要建立大范围的回归测试，不用担心测试破坏系统其它功能。因此，微服务组成的系统应用具备一系列可并行的发布流程，使得开发、测试、部署更加高效，同时降低了因系统变更给生产环境造成的风险。
1.3 技术选型灵活
微服务架构下系统应用的技术选型是去中心化的，每个开发团队可根据自身应用的业务需求发展状况选择合适的体系架构与技术，从而更方便地根据实际业务情况获得系统应用最佳解决方案，并且每个微服务功能单一、结构简单，在架构转型或技术栈升级时面临较低风险，因此系统应用不会被长期限制在某个体系架构或技术栈上。
1.4 容錯
在传统单体应用架构下，当某一模块发生故障时，该故障极有可能在整个应用内扩散，造成全局应用系统瘫痪。然而，在微服务架构下，由于各个微服务相互独立，故障会被隔离在单个服务中，并且系统其它微服务可通过重试、平稳退化等机制实现应用层的容错，从而提高系统应用的容错性。微服务架构良好的容错机制可避免出现单个服务故障导致整个系统瘫痪的情况。
1.5 松耦合，易扩展
传统单体应用架构通过将整个应用完整地复制到不同节点，从而实现横向扩展。但当系统应用的不同组件在扩展需求上存在差异时，会导致系统应用的水平扩展成本很高。微服务架构中每个服务之间都是松耦合的，可以根据实际需求实现独立扩展，体现了微服务架构的灵活性。
2 微服务架构模式方案
微服务是一种软件架构演变后的新型架构风格，是系统应用开发的一种设计思想，没有固定开发模式。开发团队可根据企业实际业务场景进行架构设计，体现了微服务架构的灵活性。常见的微服务设计模式[17]有聚合器微服务设计模式、代理微服务设计模式、链式微服务设计模式、分支微服务设计模式、数据共享微服务设计模式、异步消息传递微服务设计模式等。
2.1 聚合器微服务
在聚合器微服务中，聚合器[18]调用多个微服务实现系统应用程序所需功能，具体有两种形式，一种是将检索到的数据信息进行处理并直接展示;另一种是对获取到的数据信息增加业务逻辑处理后，再进一步发布成一个新的微服务作为一个更高层次的组合微服务，相当于从服务消费者转换成服务提供者。与普通微服务特性相同，聚合器微服务也有自己的缓存和数据库。作为聚合器模式的一个变种，在代理微服务器中，客户端并不聚合数据，只会根据实际业务需求差别选择调用具有不同功能的微服务，代理微服务器仅进行委派请求和数据转换工作。同样地，代理微服务器也有自己独立的缓存和数据库。分支微服务器模式是聚合器微服务模式的一种扩展，在分支微服务器模式下，客户端或服务允许同时调用两个不同的微服务链。两个微服务调用链相互独立，互不影响。
2.2 链式微服务
客户端或服务在收到请求后，会返回一个经过合并处理的响应，该模式即为链式微服务设计模式。例如，服务A收到请求后会与服务B建立通信，服务B收到请求后会与服务C建立通信，依次往下游发送请求，并对结果进行合并处理后作为请求响应返回上游服务调用者。显然，该模式下的所有服务调用都采用同步消息传递方式，在一条完整的服务链调用完成之前，客户端或调用服务会一直阻塞。因此，在使用该模式过程中，服务调用链不宜过长，以避免客户端处于长时间等待状态。
2.3 数据共享微服务
运用微服务架构重构现有单体架构应用时，SQL数据库反规范化可能会导致数据重复与不一致现象。按照微服务的自治设计原则，在单体架构应用到微服务架构的过渡阶段，可以使用数据共享微服务设计模式。在该模式下，当服务之间存在强耦合关系时，可能存在多个微服务共享缓存与数据库存储的现象。
2.4 异步消息传递微服务
目前流行开发RESTful[19]风格的API，REST使用HTTP协议控制资源，并通过URL加以实现。REST提供了一系列架构系统参数作为整体使用，强调组件的独立部署、组件交互的扩展性，以及接口的通用性，并且尽量减少产生交互延迟的中间件数量。但是REST设计模式是同步的，容易造成阻塞，从而耗费大量时间。消息队列将消息写入一个消息队列中，实现业务逻辑以异步方式运行，从而加快系统响应速度。因此，对于一些不必要以同步方式运行的业务逻辑，可以使用消息队列代替REST实现请求、响应，加快服务调用的响应速度。但该模式可能会降低系统可用性，并增加系统复杂性，因而在使用过程中，要做好消息队列的选型。常用消息队列有ActiveMQ、RabbitMQ、RocketMQ、Kafka等。
3 微服务架构面临问题与挑战
微服务架构在规模较大的应用中具有明显优势，但其优势也是有代价的，微服务架构也会给人们带来新的问题和挑战。其中一个主要缺点是微服务架构分布式特点带来的复杂性，开发过程中，需要基于RPC[20]或消息实现微服务之间的调用与通信，使服务发现与服务调用链跟踪变得困难。另一个挑战是微服务架构的分区数据库体系，不同服务拥有不同数据库。受限于CAP原理[21]约束以及NoSQL数据库的高扩展性[22]，使人们不得不放弃传统数据库的强一致性，转而追求最终一致性，因此对开发人员提出了更高要求。微服务架构给系统测试也带来了很大挑战，微服务架构可能涉及多个服务，传统的单体Web应用只需测试单一API即可，然而对于微服务架构测试，需要启动其依赖的所有服务，该复杂性不可低估。在大规模应用部署中，在监控、管理、分发及扩容等方面，微服务也存在着巨大挑战。
因此，对于微服务架构的取舍，要考虑企业开发团队规模、业务需求变化以及系统用户群体规模等诸多因素。使用微服务架构主要是为了降低应用程序开发、维护等方面的复杂性，如果系统程序架构已无法再扩展，或数据库增长速度过快，并且整个团队（包括产品、设计、研发、测试、运维）都具备微服务思维，采用微服务架构的收益会大于成本。但如果系统现有程序架构还能很好地工作，不需要有太大改动，采用微服务架构则不会有太多收益。综上所述，尽管微服务架构有很多优势，但在使用微服务架构之前要结合系统自身特点，综合评估以后再决定是否采用微服务架构。
4 结语
本文通过对微服务架构概念、优势及常见设计模式的介绍，分析微服务架构面临的问题与挑战，得出微服务架构并不一定是最好的企业开发架构的结论。是否采用微服务架构进行系统开发，需要考虑企业自身业务系统特点，综合评估利弊后再进行技术架构方案的选定。
参考文献：
[1] 李敏，唐春玲. 基于语义的Web服务发展现状[J]. 科技信息，2014 （9）：8.
[2] 孙莹，许俊华，张毅，等. MVC编程模型在Web程序中的应用及Java实现[J]. 计算机工程与应用，2001，37（17）：160-163.
[3] 程伟根，危建国，吴荷红. 基于YII框架的实验室管理系统设计与实现[J]. 软件导刊，2012，11（11）：99-101.
[4] 周迅飞，王崑声. 基于MVC模式的Rails框架研究[J]. 计算机仿真，2006，23（2）：270-274.
[5] JOHNSON R，HOELLER J. Expert one-on-one J2EE development without EJB[M]. John Wiley & Sons，2004.
[6] 智为. 基于SSH多层框架的Web安全架构的研究与设计[D]. 沈阳：沈阳工业大学，2007.
[7] 李晓夏. 基于SSM框架的快捷信息输入APP管理系统研究[D]. 哈尔滨：哈尔滨工业大学，2018.
[8] 杨鹏，李腊元. EJB组件技术在电子商务系统中的应用研究[J]. 武汉理工大学学报：交通科学与工程版，2005，29（2）：223-226.
[9] DRAGONI N，GIALLORENZO S，LAFUENTE A，et al. Microservices： yesterday， today， and tomorrow[J]. Present and Ulterior Software Engineering，2017.
[10] 罗贵木. 基于微服务化的Web后台系统架构优化及实现[D].北京：北京邮电大学，2017.
[11] 唐志涛，刘星. 企业应用系统架构演进[J]. 科技创新与应用，2017（35）：120-121.
[12] LEWIS J，FOWLER M. Microservices， a definition of this new architectural term[EB/OL]. https：//martinfowler.com/articles/microservices.html.
[13] 王磊. 微服务架构与实践[M]. 北京：电子工业出版社，2015.
[14] OHANLON C. A conversation with Werner Vogels[J]. Queue，2006，4（4）：14-22.
[15] ADRIAN C. State of the art in microservices[EB/OL]. https：//blog.docker.com/2014/12/deckercon-enrope-keynote-of-the-art-in-microservices-by-adrian-cockcroft-battery-ventures/.
[16] 郭棟，王伟，曾国荪. 一种基于微服务架构的新型云件PaaS平台[J]. 信息网络安全，2015（11）：15-20.
[17] 张锋. 微服务架构实战[M]. 北京：电子工业出版社，2018.
[18] GUPTA A. Microservice design patterns[EB/OL]. https：//www.javacodegeeks.com/2015/04/microservice-design-patterns.html.
[19] WEBBER J，PARASTATIDIS S，ROBI I. REST实战[M]. 南京：东南大学出版社，2011.
[20] 李洋. 云计算中可扩展的远程服务调用机制的设计与实现[D]. 哈尔滨：哈尔滨工业大学，2012.
[21] 陈明. 分布系统设计的CAP理论[J]. 计算机教育，2013，195（15）：109-112.
[22] STONEBRAKER M. SQL databases v. NoSQL databases[J]. Communications of the ACM， 2010， 53（4）：10-11.
（责任编辑：黄 健）
