点击箭头处

“蓝色字”

---

摘要：

现代软件发展历程中，微服务概念早在2014年由两位美国学者提出，2015年云原生也在linux基金会的推动下茁壮成长。短短几年，越来越多的公司投入研究，越来越多的技术框架孕育而生。本文通过分析和测试微服务架构下的中间件技术，得出评估结果，并指导本次数据治理平台的案例改造。最终的案例分享，旨在对解决企业级应用的微服务化改造，遇到的技术方案与架构调整提供一定指导意义。

 

关键词：

云原生、微服务、数据治理、微服务架构

 

云计算技术的迅速普及，提供给企业一种可基于计算资源按需分配的模型，其中CloudNative 直译过来便是云原生[1]，是面向云环境而设计的软件架构。基于微服务架构思想，以容器技术为载体，产生的一种全新的产品研发运营模式。企业级应用可以部署在IaaS、PaaS和SaaS平台中，对于IaaS和PaaS平台中部署的应用来说，采用传统的单体模式，导致云端模块不能快速迭代更新，用户体验响应速度较慢等，这些都是产品质量提升的掣肘。这也是SaaS提供者一直强调“应用需微服务化”，保证较强的持续交付的重要原因。

在单体化的应用模型中，所有的服务都是由统一的代码库实现，由开发团队的所有人维护，当某个开发者想要修改指定服务时，必须保证其他服务不受影响。随着应用体量越来越大、服务越来越多、业务含义越来越复杂，扩展或修改某一个服务所需的周期变得异常艰难。除此之外，单体应用的更新部署需要重启所有的服务，而且单体化应用具有单点失效问题，只要其中一个服务初始化阶段出问题，会导致整个应用的全部宕机。

很多大型软件公司就是因为意识到单体化架构的局限性，提出了一种新的应用架构模型/模式：微服务架构与云原生模式[2]。

微服务架构在2014年由Martin Fowler和ChrisRichardson两位大神布道，并快速的在NetFlix和Amazon等公司实践。本着“小、独、轻、松”微服务概念，技术框架快速迭代，各种中间件技术在开源社区中也开花结果。如阿里开源的Dubbo服务交互中间件技术[3]，从阿里社区晋升为Apache顶级，目前最新的DubboMesh也在Service Mesh领域中发展迅猛。诸如此类型的技术的引入，让每个服务团队可更专注于自己业务领域的拓展与迭代。

2015 年 Pivotal 公司的 MattStine 写了一本叫做《迁移到云原生应用架构》的文章，第一次提出了云原生(CloudNative)的概念。Pivotal 不但是云原生应用的提出者，同时推出了 PivotalCloud Foundry 云原生应用平台和Spring 开源 Java 开发框架，成为云原生应用架构中先驱者和探路者。目前公认的云原生生态圈由微服务（轻量级HttpApi接口）、DevOps（部署运维平台）、持续交付、容器化（Docker）四个层面组成。由此可见微服务作为核心的重要性。

微服务架构可以帮助企业级应用对于业务的分解更聚焦、功能迭代更快速、减少开发的复杂性、降低资源消耗等，对于功能点众多、业务逻辑复杂的大型系统，采用微服务架构升级后可提高系统开发效率与容错性，便于集群扩展。此外服务的单独部署，让持续集成成为可能，对敏捷开发概念的落地提供了极大的帮助。

本篇文章从三个部分展开，第一部分介绍当前研究的背景及微服务架构优势；第二部分通过比较使用的中间件性能测试结果，分析测试报告，证明目前框架升级用到的核心技术的优势；第三部分分享架构升级过程的RoadMap，最终总结现有工作，展望未来发展。

一、相关研究

微服务架构是把原来的一个提供N种服务的应用模块划分为若干个独立的服务模块，原来应用的所有服务功能由这些服务模块分别实。每一个微服务都是一个相对独立的个体，由专门的开发团队独立开发、测试、部署，至于技术栈的选取完全取决于微服务模块，不必考虑其他服务及后期集成、部署等问题，在表现层，所有微服务发布为REST风格接口。

由于REST风格是基于HTTP协议的网络层接口格式，在数据交互的性能上存在一定的网络抖动与效率问题[4]。传统的RPC调用方式也在大部分微服务实践中广泛使用，成为并发量大、时效要求高情景下的成熟解决方案[5]，这也造就了NIO在现有技术生态中成为核心支柱。

微服务的细粒度导致服务管理存在的碎片化问题。目前NetFlix、HashiCorp、Alibaba等公司开发的注册中心中间件，旨在解决服务管理的问题，保证可监控、可维护、可追溯。从而保证分布式部署下负载均衡的动态调配，增加软件体系的灵活性和时效性[6]。

碎片化的问题同时导致这些细小的API，如何进行授权、限流管控、熔断？如何进行网络接入？如何进行合理的治理这些API服务？服务网关旨在解决以上问题，API Gateway做为系统统一入口，实现对各个微服务间的整合，同时又做到了对客户端友好，屏蔽系统的复杂性和差异性。

二、关键技术比较

2.1 网关技术比较

2.1.1 网关简介

微服务化是当前一大趋势，API网关是仅次于注册中心的存在[7]，不仅可以作为所有微服务的单一入口点，更可以分离出API令牌的授权、访问控制实施、速率限制、日志记录监控等功能。

当前对API网关组件的调研维度如下：社区生态热度、易用性、路由转发及过滤器性能、当前维护状态及特点等。

2.1.2 主流网关类型、特点以及测试结果

当前主流网关共有三种：Gateway，Zuul，Nginx。从定位来看，我们比较倾向于把Nginx定位为承载请求转发的工具，因此从技术层面的角度来说，对于自定义需求的可扩展性的支持上并不是很理想。所以在产品上我们只进行Gateway和Zuul的比较。

名称维度	Gateway	Zuul
社区生态	社区热度高	社区热度较低、中文文档多
易用性	springCloud 组件集成； Sprringboot2.X以上支持	spring cloud netflix组件集成； 1.X版本基于阻塞io； 2.X版本基于netty，异步非阻塞io，支持长连接
维护状态	springcloud组件，持续更新，版本从2.0.0开始	springcloud组件仅支持到1.X，Zuul core持续维护2.1.4至今
重点功能	过滤器有globalfilter和Gatewayfilter，分为全局和局部； 基于netty转发	过滤器仅为全局过滤器； 基于servlet同步阻塞转发

表2.1 Gateway与Zuul对比表

基于以上调研对比结果，对Gateway、Zuul、Nginx在用默认配置下，分别以Rest接口，进行高并发和低并发的比对后可以得出：

低并发（500）下三者的差距是在4ms可接受范围内的，Gateway和Zuul表现更佳。

图2.1 500线程并发对比图

高并发（6000）下，Gateway和Zuul的响应时间更短，平均在200ms-300ms。

图2.2 6000线程并发对比图

基于图、表结果，首先Gateway的社区热度高一些，相应文档多一些；其次根据测试情况，Gateway的性能优于Zuul。除此这两点外，Gateway的也有很多Zuul没有的功能，比如支持http2、websocket，域名转发等[8]。并且Gateway对于做服务转发，而不是数据库转发这种高性能需求上，性能上和Nginx差距不大，所以最终我们的选择是Gateway。

2.2 注册中心技术比较

2.2.1 注册中心简介

服务注册中心往往隐藏在服务框架背后，作为默默支持的产品[9]。优秀的服务框架支持多种配置中心，但是注册中心的选择依然强关联与服务框架，现在普遍的情况是一种服务框架会带一个默认的服务注册中心。ZooKeeper就是一款经典的服务注册中心产品，在很长一段时间里，它是国人在提起RPC服务注册中心时心里想到的唯一选择，这很大程度上与Dubbo在中国的普及程度有关。

2.2.2 主流注册中心类型、特点以及测试结果

当前主流注册中心为：Nacos，Eureka，Consul以及ZooKeeper。

由于Nacos和ZooKeeper可以无缝对接dubbo，更符合本平台需求，所以本文只针对Nacos和ZooKeeper进行分析比对。

 

名称维度	Nacos	ZooKeeper
社区生态	社区热度较低、中文文档多	社区热度较高
cap分布式特性	AP或CP	CP
维护状态	近期才开源；只到0.9.0.release;	开源，一直在维护。
重点功能，特点	1、支持springcloud 服务发现、配置管理2、有web ui控制台3、通过了大规模的性能测试4、注册中心与配置中心。	1.命名服务   2.配置管理   3.集群管理   4.分布式锁  5.队列管理

表2.2 Nacos与ZooKeeper对比表

通过Nacos和ZooKeeper在dubbo接口的性能的对比测试结果中，发现Nacos负载更为均衡，性能更优一些。

图2.3 dubbo+nacos负载对比图

图2.4dubbo+zookeeper负载对比图

其次在CAP 的权衡中，我们认为注册中心的可用性比数据强一致性更宝贵[10]，所以整体设计更应该偏向 AP，而非 CP，数据不一致在可接受范围，而 P 下舍弃 A 却完全违反了注册中心不能因为自身的任何原因破坏服务本身的可连通性的原则。

而且ZooKeeper的写是不可扩展的，当注册节点一定时，写性能会是瓶颈，发布应用时会出现排队现象，它又不可以通过加节点解决水平扩展性问题。这也不符合我们对于平台未来的期望值。

综上，我们最终的选择是Nacos+Dubbo作为高并发压力下的服务通信模型。

三、案例分享

3.1 微服务化历程

回顾数据治理平台的微服务改造RoadMap目前分为两个个阶段。

图3.1 数据治理路线图

阶段一解决代码冲突较高、产品维护不方便等问题，但由于当时业务需求较多，技术栈升级较难。因此只是将产品工程由传统web项目改造为maven管理；由平台分解为产品线并通过svn独立管理；引入Servlet3.0特性解决模块化问题，并开发周边服务，保障各产品线可独立发布、应用可界面化部署、运行库可独立升级等。阶段一为“代码治理”。

图3.2 阶段一SVN工程分解图

阶段二解决框架老化导致维护成本过高、资源调优参数不合理、部署建议不具备等痛点。翻新底层框架进入SpringBoot2.X时代；引入服务网关、注册中心等中间件技术；服务通信整合Dubbo与Rest共存方式；代码使用Git集中管理。阶段二为“服务治理”。

图3.3 阶段二GIT工程分解图

3.2 框架改造成果

基于第二章核心技术的测试结果与分析报告，现阶段微服务化后的产品部署逻辑如下。

图3.4 部署逻辑图

图中描述两种用户使用平台的方式与两种应用间通信方式。

登录用户通过NG代理后的网关地址进行访问，该请求经过登录验权，角色功能验权，操作日志审计过滤后，再通过网关路由到对应的后台AppService，从而完成本次请求。如此次请求过程需要获取非当前的用户信息，则由所属的AppService自行通信门户获取。

非登录用户通过接口签名的验证方式，保证请求路径的一致性，从而满足第三方厂商对安全红线的硬性要求。

应用间访问方式分为Rest方式与高并发的Rpc方式，满足大数据压力下应用的健壮性，如6000个调度流程同时启动，从章节2的压力测试结果下也能看出，Rpc调用方式的必要性。

本次微服务化的技术选型，充分评估了SpringBoot2.X升级风险，并改造Beaf模块，最终确定Nacos引入的必要性，从而完成该阶段下的框架改造。

3.3 核心产品分解

本节分别举例数据治理平台中的两个经典产品线BMM（元数据）与BUW（ETL调度器）。进一步介绍微服务框架在产品中落地情况。

下图为BUW应用结构。目前BUW共分为三个App，流程管理、调度执行器、任务执行器。该结构的确定来自于联通总部、山西试点、移动与智慧城市等项目落地数据治理产品后，对ETL性能指标的要求。

拆分成三个应用可有效的保证诸如内存溢出、数据库死锁、资源占用率筛查等问题的更精确定位，减少单点故障问题。但目前调度器与执行器上由于数据量过大，存在数据交互的压力，传统的Http方式，在响应延迟上不能满足现有需求，目前依然保存Dubbo调用。

图3.5 BUW应用与调用关系图

下图为BMM应用结构。目前BMM共分为三个App，元数据中心、元数据应用管理、元数据资产管理。该产品的微服务拆分思想，以元模型为驱动并作为服务组件化的最小单元，在满足最小集元数据中心App的构建下；探索元数据能力，汇聚元数据应用管理APP；并基于多维度盘点、灵活的检索与溯源能力，构建出元数据资产管理App。元数据之间请求相对独立，因此在应用间调用关系中使用Rest风格接口。

图3.6 BMM应用与调用关系图

以上两个产品结构均为数据治理平台新版本框架下的应用结构，本节通过列举产品逻辑图，描述微服务下的组件间层次结构。

3.4 总结与展望

通过技术调研与测试结果分析，我们看到了技术并无绝对，只有更适用，由于国外社区对技术的闭环，本次改造另辟蹊径并结合大量测试报告，摸索出属于BONC自身特色的数据治理微服务。

下一步我们将考虑微服务在自动化部署下采用不同的策略、工具和云服务管理器的评估，后续工作还包括，数据库可视化部署、异构数据分布、服务版本控制、流量控制及微服务的可靠性保证等。

有架构技术方面的交流，请联系郭凡

四、参考文献

[1] 刘琦     基于云原生应用平台实现应用服务可造性[J]        2019-03-10   

[2] 郑冰    基于微服务架构的系统设计与应用[J]    2019-09-04

[3] 陶先平;马晓星;吕建;余萍;周宇    软件服务多模式交互中间件模型及其支撑技术[J]     2008-04-15

[4] 王萌;王翾    网络抖动实时测量方法的实现与对比[J]  2016-02-29

[5] 王纪臣    异步RPC的设计与实现[J]2005-04-29

[6] 曾冠东    基于MINA构建简单高性能的NIO应用[J]  2008-02-01

[7] 齐勇;赵季中;侯迪;沈钧毅;曾斌异    基于Web的中间件系统集成框架——应用服务器的研究[J]2001-04-15

[8] 谭一鸣    基于微服务架构的平台化服务框架的设计与实现[J]    2017-06-01

[9] 陶明     一种分布式服务框架的设计与实现[J]    2013-03-08

[10] 孟小峰; 慈祥   大数据管理:概念、技术与挑战[J]  2013-01-10