基于开源框架及容器技术的微服务架构研究

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

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

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

0引言

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

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

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

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

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

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

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

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

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

1微服务架构

1.1微服务架构优点

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

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

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

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

1.2微服务架构不足

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

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

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

1.3微服务架构应用场景

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

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

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

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

1.4架构抉择

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

2ECP微服务架构平台介绍

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

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

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

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

2.1基本目标

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

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

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

2.2微服务调用

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

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

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

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

2.3微服务监控

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

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

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

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

3微服务实践

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

3.1微服务开发

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

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

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

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

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

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

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