微服务如何持续“无痛”演进?统一分布式配置中心不可或缺

小数导读:

今天为大家分享,数人云3月31日Building Microservice NO.2北京站meetup上,晓阳老师为大家带来的关于《微服务配置中心架构解析》的实录分享。

今天讲的主题是微服务配置中心的架构解析。

微服务的前世今生

这段英文是2014年martin flower在微博上发的关于微服务的一个定义,我们在讲配置中心之前,先讲讲微服务,大概了解一下配置中心在微服务里到底是什么样的地位,处在哪一个环节上。

2014年算是微服务的元年,那年有几个比较大的事情,一个是微服务概念的提出,其次是Netflix的OSS框架经过实践之后终于落地,Pivotal公司将Netflix的OSS应用于Spring,成就了SpringCloud体系。

三四年过去以后,技术上也层出不穷,包括我们的docker等其它的,但是在这中间微服务配置中心这个概念始终是比较重要的。微服务从开发到最后配置上线,配置是很重要的。

再看第二页,它有一个Configuration repository,实际它并不是只在这有,因为微服务配置中心是从微服务的构建,包括它测试一直到它上线,始终贯穿在其中的。

这是我最近梳理的微服务基础架构,这里面大的模块主要有七个方面吧,包括服务的监控、服务的容错,以及后台服务等等。最中间的是配置服务,配置中心是属于运行时候支撑服务的。对于微服务系统来说是配置中心是不可或缺的重要组件。

在这里我们提出一个观点:“每一个大型的分布式微服务系统,都需要一个配置中心。”为什么呢?

做过单体应用系统的同学可能都会有比较直观的感受,那个时候系统里有配置文件,测试完之后要上线怎么办,把这个程序部署好,登陆到服务器上,手动的把配置文件里的内容改成正确的生产环境参数,就完成了单体应用系统的配置管理。

那么到了微服务里之后,这个状况就变了。首先微服务系统里的一个应用程序,我们可能会把它拆成很多个微服务;再加上它天然的分布式特性,每一个微服务可能会有很多的实例,分布在不同的服务器上,用户从测试环境或者是UIT环境验证完了以后要上生产,还需要靠我们运维人员挨个改配置吗?这是不太现实的。

一个系统是这样的,如果系统多了呢,这个问题就越发的明显。现在大家都在讲敏捷开发,为什么要用微服务,就是为了快速的迭代,快速的上线。这样的话,对于我们的运维人员来说,按照以前的方式改配置基本上是不可行了。如果系统规模比较大,像阿里有很多个数据中心,而且还要求异地多活怎么办?

我们就希望能够有这么一个集中化管理的配置中心,这样的话,用户通过配置中心管理控制台,能够把我所要的配置中心管理起来,它能够对应到下面所有的服务器上,所有微服务的每一个实例。当然它有一些要求,首先程序和配置要分离。

其次我们的配置是集中管理。后面我的程序包可以适应多个环境,SIT环境、UAT环境,从开发敏捷到最后上生产,包都是同一个包,它能适应多种环境,我们需要上线的时候改它的配置就行了,后面就有服务端口往下推配置,我的客户端可以拉配置,对一个配置中心来说,它可能是有历史版本的。你经常要多个版本,那么配置数据要持续化,对于所有配置的更改和下发,作为我们企业来讲,会有审计和管理的要求,还要考虑配置中心自己的数据要不要容灾,微服务的实例多了以后,我们还要考虑它的性能,考虑它的时效性。如果你的规模不大的话,配置中心是很容易实现的。但是如果你的规模大,很多的问题会暴露的比较明显。

下面来看一下业界微服务中心的发展现状,我个人觉得阿里Diamond是当之无愧的第一,不管是从应用规模还是数据体量来看都是如此,因为现在整个阿里系所有的系统都是通过他们的配置中心做配置管理,它应该是全世界最大的配置中心,但是这个好象没有开源。

开源我们了解一些,像spring-cloud-config,Netflix archaius,Ctrip apollo,Disconf,后面有一张片子对spring-cloud-config进行了详细说明。另外现在在公有云环境也有云化的配置服务,包括亚马逊的AWS-config,包括阿里的ACM。

这个是我们对开源的几个东西加上我们自己对这个配置中心有一个产品叫hawk,做了一些对比,因为各家的产品,从开源到现在,在不同的历史时期,因为技术在不断的往前发展,有一些方面是另外一些问题。并不是说有一个产品能够完全适应我们80-90%的需求。

Spring Cloud微服务配置中心

Hawk是我们从去年开始做的,它应该是比较贴合spring-cloud真实的环境,我们为什么要做配置中心?我们是一家做PaaS云的公司,在给客户实施云PaaS平台时候,就发现客户对配置中心有很强的需求,客户经常会问你们有没有相关的产品,或者别家有没有类似的产品。之前也考虑过引入一个三方的PaaS公司给客户去用。但是因为客户始终会有一些个性化的需求要重新实现,这个时候你去改别人的代码就会有各种问题,我们就想我们能不能自己做这个东西?

我们首先做了一些对比,这张表里的内容就是详细比对的结果,这里就不一一展开说明了。这张片子是spring-cloud-config配置中心的一个典型例子。大家可以看到,spring-cloud-config配置中心是存在git上的,配置数据改动以后,它实际上是通过spring-cloud-bus发业务消息让应用系统进行更新。

这张图比较清晰的描述了大概的流程:服务启动的时候,它需要从本地去拿config-server的地址,或者是通过注册中心拿这个地址。后面他会去调config-server里面的接口拿这个配置。如果git仓库有修改,POST请求configserver的/bus/refresh接口,config通过消息总线通知服务节点。服务节点接到通知后,重新到config获取新配置。

按照这种架构来看的话,spring-cloud-config并不是production ready的,在网络上也没有看到有谁真正拿这个spring-cloud-confif应用到他们的生产环境(包括老外)。

我们感觉云化微服务它就这么几个配置原则,第一要完全分离,你要部署的程序和相关对应的配置。程序包对于任何环境都是不可变的,我们可以通过环境变量或者是配置在程序启动的时候把配置注入进去。

这是在当时做hawk的时候,我们对微服务配置中心提出的功能性的需求,主要分三个,一个是按照技术功能,一个是按照管理功能,后面是加了一个集成,集成这一块主要是第三方的一些东西。

我们认为配置中心需要具有这么几个要素(当然不仅限于这几个要素)。前面提到的hawk数据要持久化存储,这个地方我们用的是mysql。可以横向扩展的缓存集群,我们用的是etcd。所有的配置,我要让它生效的时候,才会从mysql里拿出来,然后推到etcd。这样的话,所有的客户端实际上是从etcd拿这个配置信息。实际应用中,用户还可以去拉取,或者由服务端进行推送,这一块我们用client提供支撑。对于整个过程的管理,我们会提供一个UI-portal。这是我们认为配置中心必须要具备的几个比较大的要素,还有一些比较细的,片子里没有完全列完。

这是微服务配置中心的一个系统架构,像刚刚提到的,首先支持认证。这个在企业客户推的时候,企业客户一般都有自己的ldap。我们可以接他们的ldap,登陆到配置中心(hawk)做一些微服务管理的事情。

下面可以看到,控制台对应的是后台的Hawk sever,同时它还会接受调用,配置数据下发的时候,是从mysql关系型数据库拉出来,然后放到ETCD里,数据中心里所有的这些APP,或者是微服务实例,通过etcd把整个配置信息拉取到自己的运行环境里。如果做的更好一些的话,实际上在客户端还要具备一个缓存的功能,客户端拉取一次就有缓存,这样配置中心本身的健康状况对用户其他的服务是没有影响的。Configmap 和Secrets是k8s的概念,hawk给他们提供了管理界面,这是hawk与k8s平台结合使用的一个亮点。

这张片子描述了hawk的数据流程,就是我一个配置新建了以后,我会把它全量发布,实际上是它状态的一个变化。如果要回滚或者是修改,有一个历史版本。如果这条配置删掉的话,它会被删除。还有那些针对某些特定实例做灰度,这一部分修改了之后做灰度发布。这就是整个微服务配置中心数据状态的一个变化。

数人云微服务配置中心

数人云配置服务中心产品的名字叫hawk,它是基于Springcloud config打造,完全兼容Springcloud config API,配置更新通过GRPC双向流实时推送,采用ETCD作为配置数据的强一致性存储,另外还支持其他的企业管理需求,包括LDAP用户认证,授权管理等等,配置信息需要经过审批流程,才能下发到生产环境上去用。图的下方是OpenAPI和插件体系,目前主要是跟当当的sharding-jdbc做了一个集成。

配置中心不是只能用来去做程序的配置版,现在大家都在提治理,对于数据治理这一块,Hawk集成了sharding-jdbc,在应用程序运行期,可以支撑动态的分库分表。

我们的hawk里面的存储,首先是持久的数据,所有的数据都是存在service,发布可能是要跟etcd,上面会有一些Service,整个是一个high-level架构。

内部的架构大概是讲了一个流程,运维人员对配置数据做了修改并且发布之后,hawk把发布的数据推到可横向扩展的edct的集群里,这个主要是考虑到微服务规模会越来越大,需要edct有一个更高的并发管理,我们所有的第三方应用实际上是通过SDK去访问Hawk里面的数据,这也是一个更细化配置下来的,这就不展开说了。

这张图是hawk的领域模型,大家都知道,领域模型是在需求层面做分析用的,从图上可以看到,hawk需要支持不同环境的配置隔离、历史版本等等。

那么配置中心还能做什么?这里有两点,一是服务治理,二是数据治理,我们在这两个方面做了一些简单的尝试。因为配置中心每一个微服务用hawk提供的SDK去连接我们的HawkSever,可以把它本身注册到HowkSever上,这样的话,配置中心就可以承担服务治理中的ControlPlane的职责,它可以把服务治理相关的配置下发给实际的执行模块,比如dubbo,或者是SpringCloud集成的Netflix治理工具库(比如hystrix以及ribbon)。

数据治理主要是说在运行过程当中,对于动态的分库分表提供动态刷新和治理功能。因为目前只做了不到一年,很多功能现在不是特别的完美,后面我们还会继续完善这个东西。

最后提一下这个中心应该怎么部署,理论上来说,我可以只布一套hawk去管多个环境,实际情况是什么样呢?我们现在在客户现场实施云平台的时候发现,客户的开发环境和生产环境一般是物理隔离的,因为物理隔离了,所以一套配置中心就不能既支持开发环境,又支持生产环境,所以推荐的部署方式是这样:在开发测试环境里部署一套,在生产环境部署另外一套。生产环节里Hawk的用户是运维人员,开发环境里Hawk的用户是开发人员。

总结

今天主要分享的重点就是配置中心在微服务架构体系中的地位,其次是业界微服务配置中心发展情况,后面我们把数人云的hawk架构给大家做了一个简单的介绍。

拥抱配置中心,配置中心本身并没有多么高深的技术,但是在微服务这个领域不可或缺,谢谢大家。

添加小数微信:xiaoshu062 备注公司、姓名、职位 小数将拉您进入相应技术群