岳晓阳：大家下午好！开始之前先介绍一下优云数智，这是今年新搞的一个品牌，熟悉我们的人知道我们之前是数人云，数人云在今年5月份和UMCloud做了一次合并，合并之后启用了一个新的品牌优云数智。第一个字为什么是优呢？因为我们是Ucloud的全资子公司，这个优代表Ucloud，后面三个字“云数智”，代表公司以后的业务主要集中在云计算、大数据和人工智能，从IaaS到PaaS提供全方位的解决方案。前面几位老师从微服务的架构到后面的治理，讲的都是比较高level的内容，我们这个配置中心在整个微服务体系里算其中一小块，只是解决了分布式环境下如何去做软件配置管理的问题。
今天分享的标题是微服务系统的配置中心，按照常规，在开始之前需要老生常谈把微服务相关的内容大概介绍一下。微服务本身的诞生并不是一个偶然的现象，从上面这几个点，领域驱动设计、敏捷方法论、持续交付、虚拟化和基础设施自动化、DevOps文化我们展开来看：领域驱动设计指导我们如何分析并模型化复杂的业务；敏捷方法论帮助我们消除浪费，快速反馈；持续交付促使我们构建更快、更可靠、更频繁的软件部署和交付能力；虚拟化和基础设施自动化（Infrastructure As Code）则帮助我们简化环境的创建、安装；DevOps 文化的流行以及特性团队的出现，使得小团队更加全功能化。这些都是推动微服务诞生的重要因素。
前面几位老师都在讲2014年的论文对于微服务的定义，我就不再赘述了。这张暴露年龄的片子的下方是软件开发经历的三个阶段：单体应用、SOA架构、微服务架构。因为我本人是做了差不多17年的开发，亲身经历了每一个阶段，在目前这个阶段，微服务现在基本上已经被大家广泛接受了。
这里我们做了一个比较，片子上这两张图都是从网上下载的，实际是一个订车系统的架构，左边是单体架构，右边是微服务架构，从图上可以很清晰的看到两种架构的区别。单体和微服务的优劣对比，这里就不展开讲了，总的来说各有利弊，在一定的规模下，你很难说到底哪个好还是不好。
这一页是微服务的生命周期，从DevOps的角度来看，每次构建微服务并将其部署到环境时，都要经历从组装、引导、服务注册/发现、服务监控等四个阶段，对应了微服务开发的四个原则：
Ø 微服务应该是独立的，可以独立部署多个
Ø 微服务应该是可配置的
Ø 微服务实例需要对客户端透明
Ø 微服务应该传达其健康状况
我们的观点
今天分享的主题是配置中心，那我们主要还是讲讲有关配置中心的事情。在这里先抛出一个观点，我们认为：每一个大型的分布式微服务系统都需要一个配置中心。从单体应用那时候的配置管理来回顾一下，左边的图描述的是按照环境的不同，提供不同的配置文件，将这些配置文件跟二进制包打包在一起，这个在Weblogic时代是很流行的一种做法。到现在我知道有些厂家还是用这种方式做，它也是容器运行环境，在打镜像的时候会把配置的信息和镜像打在一起。假设实际当中有三个环境，前面是一个开发环境，中间是测试环境，后面是一个企业的生产环境。每个环境都有相关对应的配置文件，程序去哪个环境运行，就提供对应环境的运行包。
微服务系统到底怎么管理配置信息
考虑这么几个问题，一个系统到后面可能会拆成好几个微服务，每一个微服务可能有好多的实例，这些实例分布在不同的系统上，要让人手工去改这个配置系统，想想就是很可怕的事。这还只是一个系统，如果是多个系统呢？牵扯到多个数据中心呢？所以对于微服务的配置，我们有几个原则：一是程序和配置一定要分离，二是配置要集中进行管理，三是同一个程序包要适应多个环境，四是我们要提供一个客户端去拉取配置信息，五是服务端要能够推送，这一条主要是考虑程序运行时动态修改配置的情况，此外还要维护多版本的配置信息，还有配置中心自己的容灾，以及客户端规模到达一定数量的时候，必须考虑配置中心的性能问题。
我们整个团队的主要精力还是放在容器平台本身，去年上半年还在基于Mesos做PaaS平台，下半年转到Kubernetes体系。但是去年上半年开始，我们已经持续在微服务的领域中进行投入，配置中心是我们推出的其中一款产品。
微服务配置原则
Heroku创始人AdamWiggins发布了一个“十二要素应用宣言（TheTwelve-Factor App）”，为构建使用标准化流程自动配置，服务界限清晰，可移植性高，基于云计算平台可扩展的服务配置提供了方法论：
1.配置是可分离的，可从微服务中抽离出来，任何的配置修改不需要动一行代码。
2.配置应该是中央的 通过统一的中央配置平台去配置管理不同的微服务
3.配置中心必须必须可靠切稳定地提供配置服务。
4.配置是可追溯的，任何的配置历史都是可追溯，被管理且可用。
在云服务时代，对微服务做配置，对它有什么样的要求呢？
首先必须基于镜像管理部署，有自己相应独立的配置，而且程序包不可以因为环境的改变而更改。也就是说，它是独立于环境的不可变的程序包。
这是我们提到的，云化微服务的配置原则：
1.完全分离要部署的程序和其对应的配置。
2.程序包对于任何环境都是不可变的。
3.通过环境变量或配置存储在程序启动时注入配置。
这是我们去年整理的，对配置中心功能需求的分析，主要分三个大的方面，一是需要具备的功能，二是跟其它产品的集成，三是企业级的管理属性。
配置中心的必备要素
1.配置数据持久化存储。
2.可以横向扩展的缓存集群。
3.配置信息的拉取和推送。
4.配置数据及配置过程管理。
配置中心的系统架构
首先接入第一层是网关，整体的存储通过Hawk Server，下发到ETCD集群，ETCD集群再同步到K8S容器运行的平台。
先从数据迁移的状态简化成简单的几部分。比如新建一个配置，要么配置就被删除了，直接一步到位。如果没有这样做，就面临几种情况，这个配置是否要小范围的去做一些试探性的发布，这种情况可以走灰度发布，状态变成灰度中，配置不允许更改。要么就是两条路走，全量发布到所有服务上。要么就是放弃灰度回到之前的状态，放弃灰度后会去到已修改的状态。
另外一种情况，新建一个配置，直接全量发布，状态变成已发布状态，这时候是可更改的。但是每一次的更改，还是会回到原来那个状态。这个更改要做灰度吗？还是做发布？还是对发布有点后悔，不打算更改了？这时，从历史版本里面找一个合适的版本，激活，然后再做一次发布，通过几个简单的回路，涵盖了大部分的业务场景。
配置数据状态变迁
Hawk Portal是主体的配置界面，用户在界面上对配置进行输入、增删、改查的管理。这些资料会有两份，一份做通过Mysql做本地存储，另一份通过Hawk Server直接同步到ETCD.
由于HAWK Server是同步到ETCD里面，也就是说ETCD相当于另外一个数据库，这当中不存在数据之间的互相抄送，从而减低丢失数据的风险。持久化，是说研发和运维在后台做数据迁移，或者数据监控时更有把握，更方便。
优云数智HAWK其实有两个ETCD，一个ETCD是做注册发现的，Hawk Server、Hawk Portal都会注册在里面，作为相关的组件。类比Spring Cloud Eureka，Eureka是注册在Eureka Server里面的一个内存列表，集群里面所有Server共享这个内存信息。这个过程优云数智做了简化，所有信息全部注册在ETCD里面。
ECTD集群由于是共享的，组件的状态和一致性得到保障。Portal和Server之间不再通过Portal注册在Server并通过心跳来维持关系而是通过共享持久化的ETCD，保证数据在任意时刻所看到的状态都是一致的，从而保证了服务的注册，以及服务发现的稳定性。
Hawk和Eureka 选择的路径不一样。Eureka是比较重量级的，HAWK则简化了这个配置，简化这种代码的复杂性，重点提高系统的完整性，打造系统闭环，通过一些相对简单的方法，提高服务的稳定性。
配置一旦通过Hawk Portal潜入本地数据库，微服务的注册服务是怎么实现配置呢？当Portal写入配置到本地数据库时，同时也会通过服务Sever去同步到ETCD，ETCD里面存储的信息，是一个持久化的数据。
通过Server实时从ETCD拉取配置，有时是运行的时候拉取，有时是启动时拉取。启动时拉取有两种策略，启动的时候拉取配置，存储到本地作为静态文件的配置，运行时候拉取，动态的变更实时生效。
在Web层其实也有一些问题需要解决，比如，因为我们不是一个开发框架，是奔着一个开源系统的方向去，所以要解决服务跟浏览器之间的授权。
优云数智现在的做法是在本土数据库存储一些用户的信息，但是并没有采用传统意义上的建Session来做验证和授权，而是通过动态下发JWT的形式，每一个请求动态下发，根据我个人用户的一些信息生成，每次的请求一来一去都有交换新的Token，每个Token实时生效并有续约的功能，来代替传统意义上的Session.
配置中心的支撑体系
第一种运维管理体系类似于偏静态类的配置，在启动时通过配置文件直接拉取读业务。另外一种是开发管理体系，偏动态管理，代表的是一种程序或者在运行过程中，通过实时的变更配置内容而实时生效，达到的一种效果。
一个健全的配置中心应该支持这两种运维体系。
配置中心有这么几点：
1.基于Spring Cloud config打造。
2.完全兼容Spring Cloud config API.
3.配置更新通过GRPC双向流实时推送。
4.采用ETCD作为配置数据的强一致性存储。
5.具备LDAP用户认证、授权管理、审批流程、审计日志等企业级特性。
6.通过Open API和查件体系扩展支持基础组件，如sharding-gdbc.
配置中心部署模式
微服务配置中心如何部署，一般来讲会是这么两种方式，生产环节中单独布一套配置中心，在开发环境部署一套配置中心，开发环境的配置中心可以支持Dev、SIT、UAT等多个环境。
简单小结一下，前面主要分享了三个方面的内容，一是配置中心在微服务架构体系中处于什么样的地位；二是分析了业界微服务配置中心的发展情况，最后是微服务配置中心Hawk的架构说明。
对未来的展望
我们要做的工作，首先还是继续围绕Spring Cloud体系，为客户提供成熟方案和服务治理中心。二是探索基于Service Mesh的新方案，拥抱Istio/Conduit.三是配置中心Hawk我们已经做好了在GitHub上开源的准备工作，希望大家多多关注Hawk，关注您可信赖的云服务合作伙伴——优云数智。
今天的分享就这么多，谢谢大家。
热门专题
