用友云微服务架构下配置文件管理利器：配置中心

微服务架构是这几年IT领域的一个高频词汇，愈来愈多的项目和应用正在以微服务的思想进行重构。相比于单体应用和SOA架构，微服务优点也逐渐凸显，被广大架构师和技术人员引入和推崇。固然，单体应用、SOA、微服务等各有优点和不足。

单体架构在早期的企业内部信息化或者搭建中小型项目时很常见，简单说就是将应用程序的全部功能都打包成一个独立的单元，能够是JAR、WAR、EAR或其它归档格式。通常单体应用使用通用的IDE便可开发调试，项目便于共享、易于部署和测试。可是单体架构的应用不够灵活，任何修改都须要从新构建和部署，并且应用可能较大，不利于持续的迭代和交付。此类应用容易受到技术栈的限制，一旦先期设计出现问题，后期的技术债务会加剧负担。

微服务架构模式有点像SOA，它们都由多个服务构成。SOA架构将多服务整合在一块儿，但其和服务总线ESB过于紧密的联系以及其复杂性，也使得其在互联网应用中的部分场景里不太适用。微服务架构模式不包含ESB服务，微服务应用乐于采用简单轻量级协议，好比REST或者RPC来实现。

常见的微服务调用拓扑结构以下，此示例是基于Spring Cloud的微服务调用。完整的微服务解决方案应该包括服务注册治理中心、API网关、服务的降级熔断以及分布式配置等机制。

 

 

在业务逻辑体现上，其调用关系可能以下：

 

微服务架构下有不少优点，这里不作具体扩展，可简单罗列以下：

1：独立微服务复杂度可控制；

2：可灵活水平扩展；

3：可独立部署运维；

4：开发针对性强、支持小团队敏捷开发；

5：提升系统的可组合性和可替代性；

可是，在解决服务拆分问题、水平扩展问题的同时，其使用也衍生出了一系列问题，如分布式应用部署自动化问题、数据一致性、配置文件管理、服务的注册、服务的治理等。固然，也有一系列的方案来处理解决上述问题，如基于DevOps的自动化运维工具（用友云运维平台）、配置中心、最终一致性方案、服务注册治理中心与统一的服务网关等。

本文主要讨论下在微服务和分布式架构下，配置文件如何更好的管理。

每一个微服务都维护着相对独立的业务，服务之间经过RPC或者REST API的方式相互调用，聚合成总体。每一个微服务通常有本身的数据库和支撑环境，每个微服务实例也会拥有本身的运行环境或者说是独立的进程，也就相应的须要维护一份自身环境的配置文件，如Spring的配置文件、属性文件、业务的XML文件、AccessKey认证文件等等。

一个完整的业务一般由多个微服务组成，每一个微服务在开发环境、测试环境、预发布环境和生产环境对应着不一样的配置信息，须要针对不一样环境维护多份。开发者在开发测试以及联调的时候须要对应不一样的环境信息，频繁的修改和调整配置信息，带来了很大麻烦。大量的配置文件的维护给运维人员带来至关大的困扰。

痛点一：配置文件太多，若是开发规范不严格，各个组件集成在一块儿时配置文件整合麻烦；

 

 

 

痛点二：一个服务通常对应开发、测试、预发布、生产等多组环境，多套环境下配置文件手动管理也很复杂；

 

 

 

痛点三：运行中的环境对应的配置项须要变化调整时，调整配置文件须要重启环境；

上述问题的出现，迫切须要一个统一的配置文件管理、维护的服务出现，此服务需能统一管理多个微服务的配置文件，还能根据开发、测试、预发布、生产等环境进行区分隔离，而且能记录配置文件的多个版本。咱们一般将这类服务定义为分布式配置管理或者配置中心。

在配置中心的管理下，运维管理员只构建一份代码，便可发布到不一样的环境，应用从配置中心拉取不一样环境的配置，各个应用能够定义多个配置文件，运维管理员在配置中心统一维护各个服务的配置信息。

 

 

 

配置中心具备的以下几大基础功能：

1：配置文件和配置项的统一管理、支持多套环境；

2：提供统一SDK，获取不一样的配置；

3：统一的信息监控和统计；

4：实时或近实时推进变化信息到客户端；

同时，配置中心本还要考虑安全和加密等问题，其自身也是集群应用，应该具备高可用、支持高并发等特性。

业界经常使用的配置中心开源产品如百度的disconf和阿里的diamond以及携程的Apollo等，几种产品各有所长，这里也不统一展开。用友云配置中心（如下简称配置中心）在对比开源产品提供功能的基础上，提供基于自身技术特点的配置中心服务，更加适用用友云体系的云产品，其示意图以下：

 

 

 

配置中心优点：

优点1：配置中心服务端权限控制，统一管理界面；

经过配置中心的服务端，管理员能够进行应用管理、配置管理、文件上传、在线修改、查看客户端连线状态等操做；能够经过超级管理员登陆，也能够统一在开发者中心进行登陆。管理员能够配置通知邮箱，在配置文件变化后以邮件方式通知对应的关注人。

优点2：支持配置的多环境、多应用、多版本；

业务应用可能同时有多个版本在线，也可能有测试、预发布、生产等多个环境同时运行。配置中心包含应用、环境、版本等概念，能够维护多个应用，针对每一个应用的不一样环境，管理多个版本的配置文件，保证不一样版本业务应用的运行环境对应不一样版本的配置文件的须要。

 

 

 

优点3：支持SaaS应用的多租户隔离、应用隔离管理；

基于用友云平台，已经发展起了不少SaaS应用，各个SaaS应用在数据库隔离、文件存储隔离、缓存隔离等作了大量的工做。配置中心也支持将各个租户的配置文件数据隔离管理，更好的适配了SaaS应用对于数据隔离的需求。

优点4：SDK、动态属性注入、回调机制；

和配置中心管理服务端配和使用的，是Client端的SDK。利用SDK，开发者能够集成配置中心的拉取配置、监听变化等功能，其使用配置和注解的方式让集成过程简单快捷且侵入较小。

优点5：实时监控链接状态；

配置中心的管理员能够下开发者中心的控制台，监控到各个版本的配置文件被客户端的拉去和链接的状态，令管理员能够全局监控各个客户端的状态。

优点6：多种链接方式，短轮询和长轮询机制支持近实时推送；

 

 

 

集成与使用篇

用友云的配置中心的集成和使用至关简单，能够经过SDK的方式单独使用，也能够经过开发者中心应用管理中的配置提取和下载方式使用。

使用方式一：SDK方式

步骤1：配置文件统一管理，经过界面操做配置文件的上传和修改；

 

 

 

步骤2：属性文件、XML文件SDK拉取；

 

 

 

 

 

步骤3：配置变化动态通知、属性注入和回调机制支持，注解支持；

 

 

 

能够看到，无需编写复杂的代码，只须要进行Spring的配置修改和少许的Annotation的编写便可，大大简化了开发者的集成过程。

使用方式二：开发者中心结合配置中心使用（用友云配置中心和开发者中心结合，相得益彰！）

用友云开发者中心简介：用友云开发者中心为开者提供了资源管理、持续集成、持续交付、容器服务、镜像仓库等应用基础服务，同时为应用的微服务架构落地提供完备的支撑，结合DevOps的理念，经过提供自动化运维、日志管理、中间件服务等功能，帮助开发及运维人员下降产品研发迭代过程当中的负担。详情请参考http://iuap.yonyou.com/product/dcenter.html和https://developer.yonyoucloud.com。

（1）与配置中心的结合，在开发者中心的应用发布的过程当中进行配置文件提取，并使用golang版本工具拉取配置；

 

 

 

（2）配置中心将各个租户间数据进行隔离并加入了权限控制，使得其对多租户的支持更加完善；

 

 

除此以外，配置中心和消息总线结合，能够完美支持微服务间解耦！

• 配置中心是逻辑解耦，物理不解耦的微服务的利器。它能够解决配置致使的系统耦合，架构反向依赖的问题，配置中心的演进过程，配置私藏到全局配置文件，到配置中心。
• 异步消息是逻辑上解耦，物理上也解耦的微服务架构利器。它很是适合数据驱动的任务依赖，调用方不关注处理结果，或者调用方关注处理结果，可是回调的时间很长的场景。

引用《架构师之路》 的一篇文章，http://mp.weixin.qq.com/s/MUDqLzdnITeTsZv5uEaUYA，这里再也不拓展讨论。简言之，利用配置中心和异步消息机制结合，能够充分解决微服务架构时的部分关键问题。

综上所述，利用用友云配置中心，能够集中管理微服务架构下应用的配置文件，而且其支持多套环境、多个版本，提供完善的SDK，可利用注解的方式简便的拉取指定的配置。并且，用友云配置中心以服务的方式提供统一的管理界面，结合用友云的认证中心能够提供可靠的安全保障。