摘要：随着软件系统越来越庞大，单点应用模式无法适应大型企业软件的开发与部署，为了解决日益增加的应用复杂度，迫切需要引入微服务架构。文中使用开源框架和容器技术进行微服务开发，将服务统一发布、自动化构建、独立分发等微服务组件应用在实际生产环境中，这种微服务架构具有学习成本低、使用简单、高可移植性、易于测试、性能高、部署简单和易于监控的特点。实践证明，微应用架构不但对开发人员屏蔽了技术细节，还提高了开发人员对业务的关注度，提升了开发效率，具有较高的参考和推广价值。

关键词：微服务；微应用；容器；服务发现；服务注册

作者：刘辉军，刘培锋，邱钰锋，戴桂灶

（远光软件股份有限公司)

0引言

微服务（Microservices） 是目前业界非常受欢迎的架构模式，企业和服务提供商正在寻找更好的方法将应用程序部署在云环境中，微服务被认为是未来的方向。通过将应用分解成更小的、松散耦合的微服务，这些微服务更加容易升级和扩展，主要特点如下。

1）学习成本低：学习和入门成本比较低，可以即学即用；学习准备不会花费太长时间。

2）使用简单：微服务开发样例清晰，很容易上手，不会出现开发一个简单的样例比开发一个功能还艰难。

3）高可移植性：微服务体量较小，功能较单一，这使得移植工作更容易。

4）易于测试：微服务依赖比较少，主要聚焦在功能测试，由于功能单一，代码对测试友好，无需过度测试。

5）高性能：不会出现性能瓶颈，引入的相关依赖很小。

6）部署简单：微服务相关应用可以独立进行开发和部署，使用微服务架构和平台，这些应用的部署和功能交付将非常简单。

7）易于监控：完善的日志记录，出现问题能被监控、告警，对系统运行状态及各种指标能随时掌握。

8）易于运维：对突发事件有运维调度能力，防止雪崩效应。能够对系统进行弹性三维伸缩，快速开启和优雅关闭等。

1　微服务架构

1.1　微服务架构优点

首先，微服务架构本身就是一个化繁为简的过程。传统软件架构是集中部署一套大的Web 应用，将各类服务方法集中到整个应用中，所有的开发者都在一个整体应用环境下开发各个功能模块。微服务架构开创了全新的理念，提供了系统的模块化的解决方案，该架构将整个系统的每个服务方法单独拆解出来，独立成一个模块，这样拆解每个服务单独开发、部署和测试，大大提高扩展性与可维护性。

其次，微服务架构是一个技术创新的过程，由于每个服务独立，这就可以使服务实现的技术更加灵活，不拘束原有的技术实现，可以自由选择最新技术，只要对外保持一致的服务即可。

再次，微服务部署简单快速。由于每个服务都是独立的，体量较小，每个服务可以单独部署，可以告别整套系统应用部署的尴尬局面，更加灵活快速地部署到位。

最后，微服务架构是具有高性能的分布式架构模式。微服务中每个服务都是独立部署，部署时可以按需部署分布，可以选择适合服务部署的软件环境与硬件资源。

1.2　微服务架构不足

微服务架构的每个服务是独立的、分布的，给服务间的通信与服务的管理带来挑战，开发者要编写代码实现不同服务间的进程或网络通信，同时，要面对不同服务间通信所带来的问题，如网络时延、网络故障等问题，这相对一个大系统内的不同服务通信略显复杂。

微服务架构的每个服务都是独立的，允许采用不同的语言来实现、不同的数据库存储，这样对数据库架构要求也很高。针对数据时效要求高、更新频度高的业务场景，由于要针对不同的服务实现，更新不同数据库中的数据，势必是一个挑战，要求数据库支持分布性。因此，设计人员与开发人员在微服务的设计与技术选型上要考虑分布式的问题，需要相关人员有一定的技术积累。

微服务架构的测试，由于分布式与独立的特点，需要针对不同的服务进行测试，相比传统集中式部署的风格，测试的复杂度提高。

1.3　微服务架构应用场景

通常来讲单体应用是更好的选择，对于简单和中等复杂程度的应用，无论是长期还是短期来看其成本开销都好于微服务架构，但对于非常复杂的应用，微服务架构长期来看会有回报，但是需要经历很长时间来弥补前期的巨大投资。如果企业出现了下面的问题，则可以尝试采用微服务架构进行应用设计。

1）开发一个应用需要100 个以上开发者。

2）应用的源代码超过10 M。

3）需要按照月份或者季度发布应用。

1.4　架构抉择

微服务架构并不是万能的，不能解决全部问题，而且没有一种开发模式，在技术和管理领域，可以承诺在10 年内，无论是生产效率、可靠性还是简化程度可以领先其他技术一个数量级，所以需要根据实际的应用业务需求结合未来的发展趋势，做相应的抉择，选择最适合自己的软件架构。

2　ECP 微服务架构平台介绍

远光企业云平台(Enterprise Cloud Platfrom，ECP) 微服务架构平台满足下列要求。

1）微服务开发：允许使用各种语言/ 工具/ 框架开发微服务；在Java EE/Spring 体系的微服务开发中可以复用其他ECP 基础服务；考虑已有的企业应用系统（财务管控）接入方式。

2）微服务调用：服务发现、负载均衡、限流与容错、不同语言/ 框架都可以支持的调用方式等。

3）微服务管理与监控：提供微服务运行环境，支持扩容缩容、运行时监控、错误追踪等。

2.1　基本目标

ECP 微服务架构平台的最初目标主要包括：

1）服务调用：依托服务注册与发现机制，通过反向代理实现动态的负载均衡；

2）服务监控：提供必要的服务监控能力，即便不是应用级的服务监控（调用次数、平均耗时等），也需要系统级的服务运行状态监控（当前服务实例个数以及每个服务实例CPU/ 内存/ 网络等系统资源占用情况）。

2.2　微服务调用

案例实现的微服务架构运行时，服务调用相关的技术方案实现方式如下。

1）所有微服务均暴露为Rest API，任何语言/框架均可以用来实现微服务；同时所有对微服务的调用都是直接访问Rest API，无需针对不同的语言/框架提供相应的API；

2）服务注册：每个微服务启动时向注册中心进行自注册。负载均衡：反向代理（负载均衡器）通过注册中心动态感知微服务变化情况，并基于微服务示例运行状态动态更新自己的负载均衡策略；服务发现：微服务客户端（包括远程客户端和集群内的微服务）以固定地址访问所需微服务对应的反向代理（负载均衡器），无需关心反向代理（负载均衡器）后面的微服务运行状态。在上述方案中没有网关（API Gateway）的存在，但此方案中的反向代理（负载均衡器）可以在后期被API Gateway 取代，在提供上述功能的同时，并不对微服务的调用方产生影响。

通过HTTP+REST 对开发使用友好。但是治理起来较困难，连接无状态，以及附带的服务端推送、调用链路监控埋点等，增强了系统的附加能力，对调用方提出了新的要求。综合来看，远程方法调用(Remote Procedure Call，RPC) 从性能、契约优先来说具有优势，引入gateway 层，让REST 与RPC 的优点进行融合，在gateway 层提供REST 的接入能力。

2.3　微服务监控

运行环境基于容器集群管理产品/ 项目，通过运行环境实现下列功能。

1）统一软件交付形式：以镜像作为软件交付形式，便于DevOps的实施；

2）支持扩容缩容：基于容器集群实现微服务扩容缩容，甚至实现自动扩容缩容；

3）运行时监控：可以通过容器集群实现容器运行状态监控，当容器与服务一一对应时，容器运行状态可以被认为近似于服务运行状态。

3　微服务实践

上述微服务运行环境依赖容器集群管理，建议选择Google Kubernetes或者DaoCloud 产品实现。

3.1　微服务开发

微服务可以通过各种协议暴露其接口，并允许使用任何语言/ 框架实现。基于ECP 微服务架构平台只开发包含符合下列特征的微服务：服务接口为基于http(s) 的Rest API；语言/ 框架基于Java EE/Spring OSGi 体系。

另外，所有Rest API 都应该满足分布式部署（实现无状态）并保证业务功能正确（最终一致性）。

3.1.1　基于ECP 平台(OSGi) 的微服务架构

基于ECP 平台OSGi 版本的软件开发工具包(Software Development Kit，SDK) 微服务，就是将Rest Controller 暴露为微服务（Rest API），但通过ECP 平台SDK 实现微服务，有下列优势：

1）重用ECP 中涵盖的基础设施（消息、缓存、调度、流程等），无需自行集成这些能力；

2）简化安全认证：微服务所需的安全认证机制，可以重用。

与此对应，基于ECP 微服务架构开发的微服务将被构建为war，需要打包部署到Java EE Servlet 容器中（Tomcat/Jetty 等）。

3.1.2　基于ECP 平台(Spring Boot) 的微服务架构

Spring Boot 提供了实现Rest API 的良好支持，并极大地简化了配置和部署。在无需Web UI 而仅仅只为了提供Rest API 的情况下，是Java EE/Spring体系下实现Rest API 的首选框架。

Spring Boot 实现的Rest API 将被构建为jar，其中内置了Tomcat/Jetty，可以直接部署运行，无需外部的Java EE Servlet 容器。

3.1.3　原有旧系统接入

已有的应用系统（如财务管控），通常不可能大规模重构为微服务应用系统，还需要复用已有系统的部分服务并接入微服务运行环境。对于此类需求，建议采用下述方法实现：

基于Spring Boot 实现微服务，这些微服务将调用已有系统的API 实现其功能，如果这些服务有严格的性能要求，也可以直接访问原系统的数据库实现这些服务。总之，新实现的微服务进行接入，这些微服务的实现依赖已有系统，这些微服务适配已有系统的功能进行接入。

3.1.4　服务接口演化

在日常开发的过程中，服务端对外开放的接口API 会有一个变化的过程。

单体应用处理服务端接口的变化，直接修改对应的接口，然后再修改所有接口的调用即可。

微服务对于接口变化的处理，由于各个微服务的独立性，很难实时更新服务调用实现。在这种情况下，在不影响原有调用又要提供新的服务供调用的前提下，服务的提供者有可能提供2 套服务，一套是新的接口API 服务；另一套是旧的API 服务。

当微服务的发布者对原接口进行修改时，考虑的是改动的大小及旧的服务API 的兼容性。进程间使用轻量级通信机制进行通信对接口改造帮助很大，建议使用在最初的设计过程中，每个服务的设计都遵循健壮性的原则，比如：只是对某个特定场景设计API，调用API 的服务使用旧的接口，能同时兼容调用新的接口一起工作，API 服务仍然提供原有的默认响应值，调用服务忽略即可。有时接口改造涉及的改动很大并且与旧接口不兼容，由于不能强制所有调用服务进行升级，所以存在新老服务并存的情况，服务端调用会针对新老不同API 服务，这就要求服务的API 具有多版本概念，针对不同调用进行处理。

3.2　微服务部署

微服务架构是由一组小但是独立的服务组成，各服务有独立的进程，需要独立部署，服务部署需要快速、可靠并且性价比高。选择基于容器部署的方式能满足上述需求，ECP 微服务部署架构如图1 所示。

图1 ECP 微服务部署架构

3.2.1　基于Google Kubernetes 架构

Google Kubernetes 提供了完整的微服务运行环境，完全满足前述微服务调用、微服务管理与监控的要求。

1）API Server/etcd：作为注册中心，微服务实例将在其中注册；

2）kube-proxy：实现反向代理，能够自动根据服务实例的运行状态调整其代理策略；

3）通过Kubernetes Service 定义，保证集群中指定Service 的实例数量；

4）具备完整的容器运行状态监控能力。

Kubernetes 提供了完整的微服务架构实现方案，但其概念及实现方式与原生的Docker解决方案并不一致，与Docker 版本的更新时间上不同步。

3.2.2　基于DaoCloud DCE 架构

DaoCloud 提供的运行环境以及集群监控能力能满足前述基本目标中监控相关的要求。

DaoCloud 基于原生Docker 提供容器集群管理方案，仅作为容器管理产品使用，自动的服务发现和负载均衡需要通过HAProxy+etcd 自行实现。

因此具体实现为：

1）微服务调用均通过HAProxy 进行，HAProxy作为反向代理（负载均衡器）；

2）etcd 作为注册中心；

3）每个微服务启动时向etcd 注册；

4）HAProxy 自动发现etcd 中微服务实例的变化并透明代理。

3.3　微服务研发过程

微服务架构模式容易实现敏捷开发，将开发和运维高度协调，提高生产率。通过流程和工具自动化，更敏捷的交付产品。ECP 微服务持续交付过程如图2 所示。

3.4　成果展现

最终通过ECP 微服务架构平台，将现有应用的基础组件拆分为多个微服务，如缓存服务、消息服务、调度服务、非结构化服务、流程服务、接入服务、配置服务、认证授权服务、日志服务等。各个服务自治，服务之间协同，所有服务调用都使用统一的HTTP 服务通信框架，达到标准化。提供开发者中心和微应用发布中心，实现了服务注册、服务自动发现、负载均衡、容错、会话跟踪、访问控制、灰度发布、数据可视化。

图2 ECP 微服务持续交付过程

4　结语

本文研究微服务架构平台实现，通过ECP微服务架构平台快速完成了应用源码构建、镜像打包和应用部署，实现了微服务的高效运营，在该平台下，研发人员可以快速构建微服务。微服务技术架构和底层实现代码全部由平台提供，屏蔽了复杂的技术细节，研发人员只需要关注业务代码编写即可。实践证明，该平台能够大幅加快开发速度，有较高的应用价值。