论面向服务架构及其应用

摘要：

2018年5月我参与了某省电信智慧BSS系统的运营管理平台（NOSP）项目的开发。该项目为解决BSS系统的日常运营中提前发现故障、快速定位问题、保障服务稳定运行等方面提供全方位的软件支撑,我在该项目中担任系统架构师，主要负责系统的总体架构设计和技术选型。本文以该项目为例，主要论述了微服务架构在项目中的具体应用，通过采用适配的方式解决不同技术栈的服务提供者之间的互联互通;通过配置中心解决服务的配置管理和实时更新；通过集成网关解决服务的安全访问和服务治理。事实证明，采用微服务架构后，系统在可靠性、可扩展性、实时性等方面都达到了预期目标。系统自2019年2月上线后运行平稳，得到了领导和用户的一致好评。

正文：

随着2016年中国电信提出构造新一代运营商领先的智慧BSS3.0，以满足未来5年以上的市场营销与服务要求。2017年某省电信采用集团规定的平台+应用的方式重构了BSS核心系统，由于重构后的BSS系统涉及到PaaS平台的众多中间件和18个能力中心；同时采用容器化、集群的方式部署在超过140台物理主机、2000个容器中。整个BSS系统在性能和可扩展性等方面得到了极大的提升，但也增大了系统的运维难度，急需配套的运营系统来从整体上全方位的掌握BSS运行情况。由于我们不仅承建了该省的BSS核心系统，同时我们还深度参与了集团PaaS平台的开发，因此2018年5月我公司被该省电信委托建设新一代智慧运营管理平台(NOSP)，以下简称该系统。该系统包含资源管理中心、组件管理中心、数据运营中心、监控告警中心、运营日志中心、运营分析中心等子系统。我以系统架构师的身份负责系统的总体架构设计和技术选型，7月份完成架构设计工作和基础开发框架的搭建，整个项目历时9个月，2019年2月顺利上线并通过验收。

面向服务架构（SOA）是一种松耦合、粗粒度、与语言无关的应用架构，服务之间通过标准化的接口实现交互，不需要了解对方的内部实现细节、具体的技术平台和部署方式，适合于异构系统之间的服务集成。面向服务架构的常用实现方式包括webservice、ESB。webservice包含服务提供者、服务请求者和服务中介者，服务提供者通过发布的WSDL，定义了服务的接口、入参和出参等信息，描述对外提供的服务功能；服务请求者通过SOAP协议访问服务提供者，SOAP主要定义了服务之间如何交互以及消息格式；服务中介者一般采用UDDI实现，UDDI用于描述、发现与集成服务，服务提供者向UDDI发布服务，服务调用者查询UDDI上已发布的服务。ESB采用总线机制，提供了服务的注册、服务路由、消息格式转换、安全认证、服务编排、日志和监控等功能。

微服务架构是SOA的延伸和演化，它强调更轻量级的通信协议，以业务模块划分服务，每个服务可以采用独立的技术栈和存储,可以很方便地水平扩展。下面主要从服务提供者、微服务配置中心和微服务网关3个方面详细阐述微服务架构在项目中的具体实施过程。

1.服务提供者

在微服务架构中，服务提供者主要对外提供服务能力。每个服务都可以有不同的技术栈，服务可以独立维护与演进。由于该系统涉及多个子系统，其中配置管理子系统采用开源的蓝鲸系统改造而来，其采用的开发语言是Golang;组件管理子系统采用Python作为采集Agent的开发语言。为了方便在Spring Cloud架构下与其他子系统之间的交互，我们针对这两个子系统，采用SPring Cloud框架构建了一层适配器，专门负责将原有语言的API接口转换为Spring Cloud的API接口；虽然由于增加了一层适配层，性能上有所损失，但最大化地重用了已有的功能模块。同时为了方便消费者对服务提供者的服务做联调测试，我们采用Swagger实现API的文档化，在微服务治理框架的管理界面中集成了所有服务提供者的API，服务调用者可以在界面根据接口定义的提示，直接可视化测试服务提供者的API，从而极大地提升了联调测试的效率。

2. 微服务配置中心

由于服务需要在不同环境下部署，就必然会涉及到的服务的配置管理和实时更新问题。例如我们采用Swagger实现API文档化，在开发和测试环境下，API文档要处于开启状态，但在生产环境，出于安全考虑，就必须关闭；同时数据库的密码在开发环境下采用明文配置，由开发团队负责，但在生产环境下由DBA团队专门管理。虽然SPring Cloud也提供了config server配置中心，其支持Git和SVN以及文件系统等配置方式，但缺乏管理界面，不利于运维。所以我们采用了携程开源的Apollo作为我们外置的配置中心，将其集成到我们的网关的管理界面中。我们采用服务名称和环境名称两个维度来区别不同的配置文件，配置项可以在线可视化配置、修改、实时同步到服务所在主机，可以缓存在主机的文件系统中，在服务运行期间即使配置中心不可用，服务可以读取本地缓存的配置文件，服务的启停都不受影响。同时配置中心我们采用了集群部署，尽可能地提供了可用性。

3. 微服务网关

微服务架构下，每个微服务会提供很多API接口，必须采用有效的方式管理API的注册、安全访问和服务治理等问题。SPring Cloud提供了Zuul作为网关服务，其支持服务的路由、服务的负载均衡等基本功能。但对于服务的安全访问、限流、监控、日志等需要我们自行开发实现。我们采用JWT的Token机制，解决了前端应用和外部服务对于API的安全访问问题。采用了令牌策略的限流方式，实现对于URL和IP两个基本的流量控制，有效缓解业务高峰期时服务的可靠性问题。对于服务的监控，我们采取了两个维度的策略，首先在每个服务中集成了spring actuator组件，在网关的管理界面可以监控每个服务的JVM、API响应时间等性能指标；同时在服务间的调用关系链路的监控上，我们开发了基于pinpoint实现的APM性能监控子系统，可以实时发现服务调用的性能问题。通过扩展网关的功能，提升了微服务框架的治理能力，降低了运维的难度。

实践证明，通过采用微服务架构有效实现了子系统间的集成，该系统已于2019年2月上线运行到目前为止，各服务运行状态良好，能够较好的满足用户的要求，得到了客户和领导的一致认可。目前已完成了所有存量资源数据的接入，可以满足CRM和计费系统的日常运营要求,在月底业务高峰期间，能定位和发现存在性能瓶颈的服务和故障节点，指导相应系统及时采取扩容和灾备方案。但在系统开发过程中，也存在两方面不足之处：第一在资源管理的数据建模阶段，没有完全识别出所有用户需求，导致集群模型在CRM系统和PaaS平台上理解有偏差，使得后期在做资源树的展现时无法串联；第二原有配置管理服务在多模型关联查询时，性能有待改善。针对第一个问题，我们重新定义Mongodb文档的字段，修改相应功能的查询语句，就满足了要求。针对第二个问题是我方采用线程池和并发查询策略直接操作蓝鲸系统的数据库，使得查询性能控制在1s以内。

通过该项目的顺利实施，让我加深了对架构设计相关知识和技术的运用，同时也认识到在今后的工作和学习中，需要进一步梳理完善自身的知识结构，扩展知识的深度和广度，更好地参与到下一个项目中。