微服务架构是这几年 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/produc…://developer.yonyoucloud.com。（1）与配置中心的结合，在开发者中心的应用发布的过程中进行配置文件提取，并使用 golang 版本工具拉取配置；（2）配置中心将各个租户间数据进行隔离并加入了权限控制，使得其对多租户的支持更加完善；此之外，配置中心和消息总线结合，可以完美支持微服务间解耦！配置中心是逻辑解耦，物理不解耦的微服务的利器。它可以解决配置导致的系统耦合，架构反向依赖的问题，配置中心的演进过程，配置私藏到全局配置文件，到配置中心。异步消息是逻辑上解耦，物理上也解耦的微服务架构利器。它非常适合数据驱动的任务依赖，调用方不关注处理结果，或者调用方关注处理结果，但是回调的时间很长的场景。综上所述，利用用友云配置中心，可以集中管理微服务架构下应用的配置文件，并且其支持多套环境、多个版本，提供完善的 SDK，可利用注解的方式简便的拉取指定的配置。而且，用友云配置中心以服务的方式提供统一的管理界面，结合用友云的认证中心可以提供可靠的安全保障。