AI中台
智能硬件
RPA云平台
数智员工
新一代企业数字焦点系统（YG-DAP）
智税云
财务云
易审云
协同云
人才云
培训云
知识云
售电云基于开源框架及容器手艺的微服务架构研究
- 时间：2018-07-13
- 泉源：电力信息与通讯手艺
摘要：随着软件系统越来越重大，单点应用模式无法顺应大型企业软件的开发与安排，为相识决日益增添的应用重漂后，迫切需要引入微服务架构 。文中使用开源框架和容器手艺举行微服务开发，将服务统一宣布、自动化构建、自力分发等微服务组件应用在现实生产情形中，这种微服务架构具有学习本钱低、使用简朴、高可移植性、易于测试、性能高、安排简朴和易于监控的特点 。实践证实，微应用架构不但对开发职员屏障了手艺细节，还提高了开发职员对营业的关注度，提升了开发效率，具有较高的参考和推广价值 。
要害词：微服务；微应用；容器；服务发明；服务注册
作者：刘辉军，刘培锋，邱钰锋，戴桂灶
（888集团6008股份有限公司)
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 微服务架构平台先容
888集团6008企业云平台(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 微服务开发
微服务可以通过种种协议袒露其接口，并允许使用任何语言/ 框架实现 �；贓CP 微服务架构平台只开发包括切合下列特征的微服务：服务接口为基于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微服务架构平台快速完成了应用源码构建、镜像打包和应用安排，实现了微服务的高效运营，在该平台下，研发职员可以快速构建微服务 。微服务手艺架构和底层实现代码所有由平台提供，屏障了重大的手艺细节，研发职员只需要关注营业代码编写即可 。实践证实，该平台能够大幅加速开发速率，有较高的应用价值 。
粤公网安备 44049102496133号
