微服务架构特点、技术趋势及在行业应用中关键问题研究

摘  要： 近年来，微服务架构已成为软件平台系统设计的热点选项。微服务架构可以有效提升软件平台系统的快速交付和灵活部署，并可以更敏捷实现后期功能的扩展。然而，由于微服务架自身构设计复杂且专业性要求较高，导致企业采用微服务架构的难度较大。本文总结了微服务的特点和优势，研究分析了关键技术要素以及未来技术的发展趋势，并结合当前微服务在行业的应用情况，剖析了企业在采用微服务架构方面面临的主要问题和瓶颈，并就微服务架构在传统企业数字化转型中的实施和应用提出可行建议。

关键词： 微服务;软件平台系统架构;服务网格

中图分类号： TP311.5    文献标识码： A    DOI：10.3969/j.issn.1003-6970.2020.06.028

本文著录格式：王义. 微服务架构特点、技术趋势及在行业应用中关键问题研究[J]. 软件，2020，41（06）：132136

【Abstract】： In recent years， Micro-services architecture has become a popular option for the software system development. Micro-service architecture can effectively improve the agility of software systems， with early delivery， flexible deployment and elastic scalability. However， due to the complexity of the design and the professional prerequisites arising from the deployment of the Micro-service architecture， it presents a lot of challenges for the enterprises to adopt the Micro-service architecture. This article summarizes the pros and cons of Micro-service architecture， depicts its application in various industries， the future development trends and the bottlenecks of implementation， and provides viable suggestion for using Micro-service architecture in assisting the digital transformation of traditional industries.

【Key words】： Microservices; Software platform system architecture; Service mesh

0  引言

微服务是一种软件架构，是指在软件平台系统设计中，将单一的应用程序划分成一组小的服务组件，组件之间通过设计好的接口（API）进行访问和调用。系统运行时，这些组件相互协调、互相配合，共同实现上层的复杂功能。微服务的概念由Peter Rodgers博士在2005年“云計算会议”上首次提出，起初被称为“微网络服务”，在之后的几年内一直“不温不火”。2010年以后云服务产业迅速发展，由于微服务的设计理念与云服务极为契合，因而被广泛应用于各大主流公有云服务平台，成为软件平台系统设计的热点选项。

1  微服务特点以及发展趋势

1.1  大型软件平台系统架构发展的历史背景和趋势

大型软件平台系统的发展从“简”到“繁”，其架构设计从“中心化”向“去中心化”快速演进[1]。最早期的大型软件平台系统采用单体式架构（Monolith），将所有程序和数据资源都部署在同一台服务器上。后来，随着产业不断发展，为应对大数据场景，软件平台系统在架构设计上将应用和服务分离，并引入分布式部署和集群，提升系统整体性能。

Gartner公司将面向服务的思想应用在软件平台架构设计中，于1996年提出面向服务架构（SOA）概念[2]，其核心特征是以松耦合、粗粒度的服务单元来构建软件。具体而言，就是将业务系统分解成多个独立、自治、可复用的服务，通过对服务的编排组合实现上层业务流程。在SOA架构的实现案例中，常常用到企业服务总线（ESB），ESB也渐渐成为SOA的核心技术基础。

微服务是SOA思想的进一步深化，是软件架构设计向着“去中心化”的进一步演进。通过一系列功能单一，强内聚、松耦合，可独立部署，可扩展的应用组件，微服务对软件平台系统架构进行了更进一步的专业化拆分，颗粒度从功能模块层级精细到组件层级。

1.2  微服务架构的特点和优势

从服务入口到数据持久层，微服务实现了组件的“真正独立”，无需服务总线接入，每个组件就相当于一个独立的项目，组件之间采用松耦合方式，通过接口调用。这种隔离性使得模块代码量明显减少，遇到问题需要修改组件代码时也不会对其他组件造成影响[3]。此外，开发模式更为灵活，每个组件都可以使用不同的存储方式，支持不同的开发技术。与早期的软件架构相比，微服务具有以下几点优势。

一是简化复杂问题。在总体功能不变的情况下，微服务通过拆分的办法解决复杂性问题，将大型单体式应用拆分成多个相互独立的应用组件，每个组件都有清楚定义的边界，面向特定的功能，易于设计、开发、更新和维护。

二是支持敏捷开发。微服务面向分布式开发，允许业务部门根据自身的业务需求，通过定义好的接口对已有的微服务应用组件进行组合，自助式开发新项目。在对单个应用组件进行代码重构时，也不会对其他组件构成影响，从而实现以持续集成的方式交付项目。

三是灵活部署扩展。由于各个应用组件在功能、部署和数据层面均采用相对独立的松耦合设计，开发者不需要协调其它组件对本组件的影响，从而可以加快项目部署速度。在业务开展后，可以根据实际需求对单个应用组件独立扩展，或随着业务发展特点和趋势及时地对应用组件类别进行动态调整，精准实现多项功能的收缩和扩展。

1.3  微服务的三个关键实施要素

容器、编排调度和开发运营一体化（DevOps）是保证微服务成功的三个关键要素。

容器[4]为拆解后的应用组件提供了相互隔离的承载环境。容器是一种轻量化的虚拟技术，可以将内部的应用和其运行环境以一个标准镜像格式打包，为运行在其中的进程提供一定程度的隔离和约束，保证应用及运行环境的统一性。与传统虚拟机不同，容器共享内核，支持快速扩展。相较于虚拟机的启动时延，容器对负载或者流量增加的反应速度可以达到秒级。目前最主流的容器平台是由早期Linux容器发展而来的Docker[5]，通过Docker，开发人员可以轻松启停或销毁容器，方便快捷。

编排服务[6]负责基于容器组成分布式集群应用的管理工作。容器编排也被称为调度器，主要负责管理基于容器组成的分布式集群，例如监控容器的运行状态、容器故障自动化恢复、基于容器的应用扩容和缩容等。当生产环境需要部署数百至上千个容器时，容器编排可以极大简化操作流程，很好应对日益增长的集群管理问题。当前的最流行的容器编排工具[7]包括Kubernetes和Docker Swarm，分别由Google和Docker公司在2014年和2013年推出。

DevOps是微服务实施的充分必要条件。DevOps（开发运营一体化）通过促进开发、技术运营和质量保障三者之间的沟通、协作与整合，使用自动化的“软件交付”和“架构变更”的流程，加快项目进度、缩短发布周期，提供高质量的软件和服务[8]。微服务将原先一个应用拆分成数十个组件，拆分后的每个组件都需要进行编译、打包和部署，这将带来数倍于先前的工作量。因此对自动化工具、测试流程、团队协作和代码质量把控有着更为严格的要求，需要开发部门与运维部门通力协作，打破部门鸿沟，提升各环节工具链的自动化水平。

1.4  微服务的最佳应用实践场景

微服务的价值通过云平台得到最大化发挥和体现[9]。一方面云平台为微服务发展提供理想应用环境。云平台凭借着快速、敏捷、可大规模扩展的基础架构，以及自助服务和按需付费的计费功能，正在重塑社会生产力，提升运营效率并加快价值实现。容器技术日渐成熟，容器所具备的快速启动、应用程序标准化封装和隔离模型等特性，进一步提升了云服务的效率和敏捷性，这为微服务架构的落地奠定基础。另一方面，微服务能够显著提升云服务效率，推动大型企业的平台系统上云。现代业务的发展特点以及来自市场的竞争压力，对平台系统提出了极高要求，许多业务场景要求在确保7×24小时在线的同时，对系统进行升级、扩容和增加新功能。对于银行、电子商务等行业领域，系统的停机维护将带来巨大经济损失，甚至将导致客户流失。微服务在服务拆解、资源调度、鲁棒性等方面的独特优势，完全适合上述应用场景对于成本效率、可伸缩性和7×24可用性的需求。已经成为云端应用开发的基础和实现全套云功能的核心。借助全面的微服务平台，开发人员可以通过公共云、私有云和混合云创建高性能，高可用性，高成本效益的平台系统。

1.5  微服務技术发展趋势

微服务架构没有公认技术标准，受科技巨头推动，已相继出现若干具有影响力的开源或商用框架。根据框架在应用开发代码中的植入强度，主要分为侵入式架构和非侵入式架构[10]，以服务网格为代表的非侵入式架构被认为是微服务未来发展趋势。

侵入式框架是指在使用这种框架进行开发时，代码需要继承或者实现框架的某一个类或接口，应用对框架存在依赖性，一旦把框架去除或者换掉框架时，需要重新修改代码。目前，侵入式框架占据微服务主流市场，其中以Spring公司的SpringCloud[11]和阿里巴巴的Dubbo[12]为典型代表。

从2017年初第一代架构Linkerd到2018年Google、IBM和Lyft联合开发的第二代架构Istio，服务网格从萌芽走向成熟。服务网格部署应用程序时，会同时部署SideCar和Control Plane两大核心模块[13]。其中，SideCar由一系列轻量级的网络代理组成，这些网络代理实现了服务框架的各项功能，通过SideCar，应用服务和框架之间实现了松耦合，服务节点只关注业务自身，服务之间的调用由SideCar完成。Control Plane是一个大型服务网格的统一控制节点，通过控制SideCar从全局角度实现服务网格的各项功能，负责SideCar的注册，协助各个SideCar之间进行负载均衡和请求调用，同时收集所有SideCar的监控信息和日志数据。

2  微服务在行业中应用以及落地过程中的问题

近年来，企业数字化转型进入加速期。伴随着产业互联网蓬勃发展，企业通过引入各种形式的云，升级、优化内部软件平台系统，提升对上层业务的赋能。在这种趋势下，微服务受到越来越多企业的重视，行业应用范围迅速拓展。研究显示，至2023年，微服务架构市场预计将增至320.1亿美元[14]，4年年复合增长率达到16.17%。

2.1  微服务在不同行业企业中的应用情况

对微服务在不同行业样本企业中的应用情况进行研究和分析，结果显示，互联网行业已经实现微服务的大规模应用落地;传统行业中，随着市场认可度提升，软件和IT企业积极布局，一些大型企业已经基于微服务完成了内部平台系统的重构。未来，伴随着云平台被越来越多行业采纳和使用，微服务也将更广泛、更深入的渗透到社会的方方面面。

首批成功采用微服务的企业主要集中在以互联网业务为主的数字商业市场[15]，例如数字媒体、社交网络、电子商务等领域，这类企业的业务模式对软件平台系统在敏捷性和可扩展性方面有着极高要求。

其次，在金融、零售、消费品制造等传统行业中，越来越多的领先企业也开始采用或已经采用了微服务，较为成功的案例包括Capital One、可口可乐、迪士尼、通用电气、高盛、耐克和红牛。

2.2  应用过程中出现的问题

研究过程中，我们发现，并非所有企业的软件平台系统都适合微服务。微服务的适用性需要综合考虑业务在弹性、迭代速度、并发性和可用性等方面的需求，以及业务复杂程度，长期演进目标，业务对复用性的需要。部分企业在平台系统建设初期考虑不足，没有对自身现状进行深入分析，而是强推微服务架构，不仅没有达到预期效果，相反带来巨大损失。

从传统软件设计架构向微服务迁移是一个逐步推进的过程，盲目强推会带来巨大风险。首先，微服务架构体系复杂，应用之间通过接口交叉调用，形成逻辑依赖，这对系统的整体设计、公共代码开发和后期运营维护提出了更高的要求。其次，微服务要想发挥全部能力需要容器的加持，容器的编排设计就是另一个将要面临的挑战。最后，开发过程及交付质量需要通过持续集成（CI）严格把控，一个接口的改动会对多个项目造成影响，光靠人工测试很难覆盖所有情况，这就需要企业不断提升流程的自动化水平，不断提高自动化测试的比例。复杂的架构体系，加大了线上运营维护时定位排查问题的难度，不仅需要团队具备较高的监控和链路日志分析技能，同时需要开发和运营团队的密切配合，加强跨部门之间的协同合作。

3  实施部署微服务的建议

不是所有的软件平台系统都适用微服务架构，技术选型时，企业需充分考虑业务应用的特点，以产品和业务为目标导向，加强多利益相关方的参与协作，综合衡量各方利益，以实现在系统复杂性和敏捷性之间最优的平衡。

微服务实施重点不在于开发框架和开发技术，而在于前期规划和设计，即微服务组件拆分，每个组件提供功能和接口定义。除基础技术能力之外，企业应更重视以下几个方面。

一是流程机制[16]。开发和运营流程对于能否成功实现微服务至关重要，构建微服务交付平台或开发微服务应用之前，必须准备与之相配套的流程机制。与传统软件架构相比，微服务对流程的成熟度和自动化程度要求较高，这要求企业必須根据DevOps原则，不断提升敏捷开发和部署流程的成熟度;针对微服务在组件调用管理、版本和服务质量控制等方面存在的难点制定相应的新流程，从而实现快速、持续交付业务;同时优化测试和质量保证流程，以满足现有和未来业务发展在安全、治理和风险合规等方面的新需求。

二是团队组织。企业采用的软件平台系统很大程度上反映了交付和维护团队的组织架构。要想实现独立、敏捷的业务交付，发挥微服务的真正价值，需要建立与之相对应的团队组织架构，打造以客户为中心的企业文化，并赋予各级员工实现上述愿景的能力。部门设置上，需打破部门孤岛，按照业务而非技术领域设置团队，每个团队都是面向业务的跨职能部门，不仅负责从应用程序到中间件的各项技术环节，同时也负责产品包括设计、建设、交付、运营到后续升级更新的全生命周期。通过团队设置，在企业内部形成自制与负责相平衡，服务和工程相结合的文化行为。

三是数据管理[17]。微服务架构中的数据具有分布性特征，每个组件内的数据模型和数据产生流程具有较大的独立性，组件间数据的连续性和关联性靠接口维护管理。在进行数据解耦之前，首先需要进行详细的规划和设计，明确定义共享数据的范畴和边界，哪些数据是组件内部资源，哪些数据需要在组件之间共享。然后，按照API调用的数据关系对各组件的数据进行建模。在具体操作过程中，需要很好的平衡数据规划与数据治理之间的关系。因为在微服务架构中，没有中心化的数据视图和控制，这种通过接口调用的数据关联方式，增加了数据治理的复杂度，对前期数据规划提出了更高要求。

4  结论

从商业模式到业务流程，再到下沉至底层的技术支撑，传统企业在各个环节均受互联网影响。软件平台系统架构的创新将推动业务发展，助力企业转型。2014年至今，历经5年发展，微服务从概念阶段逐步落地，相关技术和理念已经在很多场景得到了应用和验证。目前，微服务在互联网，以及偏向于物流、电商、金融等前端线上交易较多的场景里落地较好，但在之外的部分传统行业中遭遇了严峻挑战，仅在一些大型公司得到了实践，尚未完全被中小型企业接受。传统企业也日渐清晰地意识到，仅依赖新技术理念并不能有效解决企业现有问题，应结合自身业务特点重新规划内部软件平台系统的升级路线。随着云计算被广泛应用，越来越多的企业将业务迁移至云平台，微服务将赋能更多行业，使得更多传统企业从中受益。

参考文献

[1] 李智慧. 大型网站技术架构： 核心原理与案例分析[M]. 北京： 中国书籍出版社， 2017： 4-12.

[2] Gartner. "Service Oriented" Architectures[R/OL]. 1996 [2019- 10-03]. https：//www.gartner.com/en/documents/302868

[3] Mark Richards. Microservices vs. Service-Oriented Architecture [M]. OReilly Media Inc， 2016： 21-26.

[4] IDC. Software-Defined Compute： Virtualization， cloud， and Container Platforms[R/OL]. [2020-01-03]. https：//www.idc. com/getdoc.jsp？containerId=IDC_P10666

[5] Allison Randal. The Ideal Versus the Real： Revisiting the History of Virtual Machines and Containers[J/OL]， CoRR Lab， 2019-4： 2， 11. https：//arxiv.org/abs/1904.12226

[6] Avinetworks. Container Orchestration Definition [EB/OL]. [2019-12-19]. https：//avinetworks.com/glossary/container- orchestration/

[7] Uchechukwu Awada. Application-Container Orchestration Tools and Platform-as-a-Service Clouds： A Survey[J/OL]. International Journal of Advanced Computer Science and Application， 2018： 3-4. https：//www.researchgate.net/publication/ 325737011_Application-Container_Orchestration_Tools_and_ Platform-as-a-Service_Clouds_A_Survey

[8] Google. State of DevOps 2019[R/OL]. 2019： 5-6. https：// services.google.com/fh/files/misc/state-of-devops-2019.pdf

[9] James A. Scott. Microservices And Containers： Mastering the Cloud， Data and Digital Transformation[M]. MapR， 2017： 43-46. https：//mapr.com/ebook/microservices-and-containers/ assets/microservices-and-containers.pdf

[10] 中國信息通信研究院. 2018年云计算发展白皮书[R]. 2018-8 [2019-12-14].

[11] 许进. 重新定义Spring Cloud实战[M]. 北京： 机械工业出版社， 2018： 3-11.

[12] Dubbo. User Doc[EB/OL]. Apache Org， [2019-12-25]. http：// dubbo.apache.org/en-us/docs/user/preface/architecture.html

[13] Christian Posta， Burr Sutter. Introducing Istio Service Mesh for Microservices： Build and Deploy Resilient， Fault-Tolerant Cloud-Native Applications[M]. U.S.A： OReilly Media Inc， 2018-04： 4-5.

[14] Kenneth Research. Microservice Architecture Market： Global Drivers， Restraints， Opportunities， Trends， and Forecasts up to 2023[EB/OL]. 2019-04-02. https：//www.marketwatch.com/ press-release/microservice-architecture-market-is-expected-to- reach-3201-billion-by-2023-growing-at-a-cagr-of-around-1617- during-the-forecast-period-2019-04-02

[15] Anne Thomas， Aashish Gupta. Innovation Insight for Micro-services[R]. Gartner， 2019： 10.

[16] Gary Olliffe， Kevin Matheny. How to Succeed with Microservices Architecture Using DevOps Practices[R]. Gartner， 2019： 11-25.

[17] Kevin Matheny， Lyn Robison. Working with Data in a Mic?r?o-services Architecture[R]. Gartner， 2019： 5-18.