这款分布式配置中心,会是微服务的降维打击利器吗?


本文来自1月18日数人云资深工程师在IT大咖说平台的线上直播分享。

今天主要探讨这几方面:
一、配置中心的定位

二、云化的微服务对于配置中心的要求

三、微服务配置原则

四、数人云分布式配置中心整体架构

应DevOps和微服务而生的配置中心

首先想跟大家分享一下,为什么会有配置中心的存在?在我早期从事软件开发时,是没有配置中心,也没有微服务的。

以前每次系统发布,无论是大改动,还是很小很小的改动,都必须经历发布的过程。这个改动有时候小到,只是修改了某个配置文件的某个字段,也必须要重新打包,重新部署。

而且,在企业里开发和运维的人员,往往不是同一个群组。部署时,开发人员需要为运维人员准备部署文档。这个过程中,经常会由于沟通协调不到位,无法第一时间预测到所有问题,导致在正式上线时,被用户第一时间察觉到上线出了问题,或者部署不正确等,导致一些非常严重的后果。

随着时间的推移,软件工程界出现了新的名词--DevOps。开发和运维人员共同协作进行产品的部署上线。在DevOps时代,如何将概念通过一些IT的手段转化为直接的生产力。因为每次发布改动越大,发布的频率越高,系统的风险就越大。

所以业界急需一种技术手段,来协助开发、部署和运维三方面的人员,在不断的迭代过程中,减少这种风险。配置能不能是一种动态的配置?而不再需要去做一些静态配置。基于这种业界的风险,就有了去做配置中心的冲动。于是,市面上出现了分布式的配置中心。

无论是分布式的配置中心,还是普通配置中心,它到底在配置什么东西?如果把时间往前推一段,通过SSH登陆服务器修改配置的那个时代,配置中心的作用其实不大。

到了2010年之后,业界出现了微服务,分布式的配置中心才正式地光明正大的走向舞台。为什么呢?因为要结合分布式配置中心+微服务,才能真正实现我们所理解的DevOps。

微服务配置原则

Heroku创始人AdamWiggins发布了一个“十二要素应用宣言(TheTwelve-Factor App)”,为构建使用标准化流程自动配置,服务界限清晰,可移植性高,基于云计算平台,可扩展的服务配置提供了方法论:

1.配置是可分离的,可从微服务中抽离出来,任何的配置修改不需要动一行代码。

2.配置应该是中央的 通过统一的中央配置平台去配置管理不同的微服务

3.配置中心必须必须可靠切稳定地提供配置服务。

4.配置是可追溯的,任何的配置历史都是可追溯,被管理且可用。

在云服务时代,对微服务做配置,对它有什么样的要求呢? 首先必须基于镜像管理部署,有自己相应独立的配置,而且程序包不可以因为环境的改变而更改。也就是说,它是独立于环境的不可变的程序包。

其次所有的微服务通过环境变量或者配置存储时,在启动的那一刻,就可以做配置,也可以通过动态的修改实时生效。 微服务启动时配置 一个微服务从打包、上线、部署,打包以后,会在启动阶段从配置Configuration Repository 里面拉取它的配置,通过注册与发现,注册在注册中心里,在启动时,把服务中心的配置拉取到本地,成为应用的一部分。

并且在服务运行过程中,实时动态监听配置的变更,达到有新的配置时马上下发到微服务,使配置有实时生效的效果。

配置中心的定位

有了以上这种业务需求,到底要做一个怎样的配置中心?数人云认为,这个配置中心必须有一致性的K-V存储中心,K-V存储就是说,一个K对应一个V,而且这种存储必须持久化、可追溯。 它必须是可以集中统一配置,实时推送,以及马上生效。

所有配置都必须实现灰度更新与回滚。所谓灰度发布,是说一个微服务集群里面,比如有个订单系统,做了一些配置上的更新。想在小范围探讨一下,实验一下这个配置对业务有怎样的影响,这时就用到灰度更新这个概念。

灰度更新是说,通过Data center或静态IP,指定某个配置只对某几个IP,或者Datacenter里面的某个服务生效,其他的不在这个范围内的服务,不会受到影响。观察效果,如果OK,就把这个整体配置全面推送到所有的微服务。如果效果不满意,就把配置回滚到原来的状态。

全量更新,灰度更新,或者回滚,必须是可在任何时候查看,在某一个任意的时刻,回滚到某一个历史点的配置。 最后一个是要有多集群的启动,所谓多集群的启动就是,我们把配置存储的时候,必须存储在一个多集群的环境里面,以达到物理隔离的目的。

另外还有一些原则,业务无关性、 Open API、配置生效监控。就是说配置中心必须提供API给第三方的系统来使用。配置的生效监控是,必须实时知道,有哪些服务拉取了配置,是否已经生效,或者这个配置的效果如何? 配置中心的支撑体系 第一种运维管理体系类似于偏静态类的配置,在启动时通过配置文件直接拉取读业务。

另外一种是开发管理体系,偏动态管理,代表的是一种程序或者在运行过程中,通过实时的变更配置内容而实时生效,达到的一种效果。

一个健全的配置中心应该支持这两种运维体系。 配置中心的微服务兼容 配置中心必须对现有主流的一些开发框架有API方面的兼容。数人云在做配置中心时,很难预估第三方来调用服务时,到底搭配在什么样的开发框架上?通常来说,配置中心不可能兼容市面上所有的东西,数人云选择重要的框架来做深度兼容。

首先,对Spring Cloud,阿里的Dubbo这些常规的第三方云服务框架做了API方面的兼容。目前来说,至少要支持SpringCloud、Dubbo、Nginx、Tomcat、Logback等各方面的配置。 这种配置各有各的特性,所以我们就挑选了一些有经典案例的,通用性的东西来做配置的集成,比如原生支持SpringBoot、Spring Cloud,集成支持k8s,就是k8s容器。

数人云hawk分布式统一配置中心

数人云分布式统一配置中心,取名Hawk。Hawk基于ETCD打造,主要解决把开发人员从复杂的业务流程和烦琐的配置中解脱出来,让开发人员只关注自己的业务代码,把运维、配置这些剥离出去。同时降低服务部署、发布过程中的风险。 基于微服务体系理念打造的分布式统一配置中心Hawk支持多种类型配置:如Spring Cloud、 Dubbo、Kubernetes Configmap、Logback、Linux Environment,具有完善的配置管理流程、配置实施推送、支持多集群多环境、多版本控制,更提供配置细粒度的管理如灰度管理、任意版本重置等丰富功能。 整个体系兼容开源社区的Spring Cloud Config以及Kubernetes的Configmap,极大降低使用者的学习门槛以及业务对平台的耦合。相应的管理流程也规范了配置的使用,降低配置带来的发布错误等。

功能特性

对比主流框架,数人云HAWK有如下一些重要的功能特性: 支持配置实时推送以及实时生效,在程序的运行过程中,不能说把服务停下来才能更新,必须实时配置,实时生效。 支持多版本管理,配置不管哪个版本,都可以随时查看、查阅以及激活历史的版本,并做发布。 支持多集群环境,多环境配置。通过数据库或者后端存储,以达到支持SIT、UAT环境的体系。

优美的监控台,提供多维度Dashboard以及监控视图,支持配置灰度和回滚。 支持数据全局备份和回复,进一步提升配置数据的容灾能力。 提供OpenAPI,支持多系统集成的便利手段,支持配置应急预案处理。 配置流程管理,完善的配置流程管理,确保配置下发前必须获得确认和授权。 认证与授权,提供LDAP集成,以及多角色权限管理。 支持操作审计,确保配置操作有据可查。 支持多种配置文件,Spring Cloud Config、Dubbo、Logback、Nginx、LinuxEnvironment、Tomcat。

支持Spring Cloud服务治理配置和管控,支持Spring Cloud自有的Hystrix的微服务治理如熔断、Fallback等等。 无缝集成Kubernetes的Configmap以及Secrets,并提供增强的企业管理流程。 Hawk整体架构 首先接入第一层是网关,整体的存储通过Hawk Server,下发到ETCD集群,ETCD集群再同步到K8S容器运行的平台。 刚才有同学说Hawk跟阿波罗有相似的地方。在研究对比时,我们觉得阿波罗出于业务需求,有一些比较复杂的地方,决定把流程简化。

先从数据迁移的状态简化成简单的几部分。比如新建一个配置,要么配置就被删除了,直接一步到位。如果没有这样做,就面临几种情况,这个配置是否要小范围的去做一些试探性的发布,这种情况可以走灰度发布,状态变成灰度中,配置不允许更改。要么就是两条路走,全量发布到所有服务上。要么就是放弃灰度回到之前的状态,放弃灰度后会去到已修改的状态。

另外一种情况,新建一个配置,直接全量发布,状态变成已发布状态,这时候是可更改的。但是每一次的更改,还是会回到原来那个状态。这个更改要做灰度吗?还是做发布?还是对发布有点后悔,不打算更改了?这时,从历史版本里面找一个合适的版本,激活,然后再做一次发布,通过几个简单的回路,涵盖了大部分的业务场景。 配置数据状态变迁 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。 配置中心集成第三方框架与类库 Hawk有一个第三方类库集成,操作流程是这样的:操作者通过UI调用HAWK后端的portal,通过Hawk Server把配置写入ETCD。另外一些运营者和开发人员所持有的第三方服务,通过集成Hawk Client来读取配置。 Hawk也有新的迭代,跟Sharding-JDBC做了集成,JDBC 2.0的一些趋势跟HAWK系统做了深度集成。服务通过实时读取配置中心配置实现动态更改分库分表的策略。

Q&A Q1:实时更改分布分表策略?
A1:可以,Sharding JDBC 2.0就是重点实现这个功能,这也是Hawk与Sharding JDBC深度合作的成果

Q2:历史数据怎么办?
A2:历史的数据其实都是持久化存储的。如果有一天要回到某个历史版本,可以随时通过调取已发布的历史。Hawk有一个版面叫发布历史。这里,每一个配置都有配置历史可追寻,可以随时查看或激活某个版本。激活的时候,需要用户去选择要做一个全链发布还灰度发布,还是说什么都不做。

Q3:是否支持ServiceMesh?
A3:目前来说ServiceMesh还是一个比较新的东西。如果ServiceMesh是独立配置的话,其实可以支持到。但是ServiceMesh有非常多的特性,还不敢说100%可以支持得到。其实数人云也在做ServiceMesh相关的项目,就是说它以后还是有非常大的可能,还是要集成ServiceMesh配置中心里面做一个闭环。目前这个版本支持一些比较轻量的配置。 ServiceMesh中文网微信公众号(ID:servicemesh),大量Istio、Conduit官方文档翻译版和技术干货文章,欢迎关注。

Q4:开发环境和生产环境用哪一步骤?
A4:SIT和UI其实可以部署在一起,通过存储隔离来做到。但是,不建议生产也部署在一起,生产还是建议独立部署。生产还是物理隔离是最好的方案。

Q5:配置中心和服务中心是不是两个系统?
A5:目前来说是两个系统,但是现在的想法是暂时的。现在的想法是是不是把配置中心再扩大一点,不叫配置中心了,而是叫比如微服务服务平台。服务平台里把配置中心跟注册中心都作为一个组件融入进去,把一些跟业务无关的东西抽离出来,搭载一些公共的平台上,以组件的形式去融入到这个平台里面去。

Q6:开源有本地缓存吗?
A6:目前来说没有本地缓存,是直接获取ETCD的东西,所以它是实时的,但是注册中心里面会加入缓存。

Q7:一般哪些信息通过配置中心配置?
A7:非业务的东西,比如平时开发一个系统,或者开发一个第三方系统,我们都有所有的配置文件,比如数据库的连接,跟治理相关的东西,或者一些国外的引用,都可以通过配置中心来配置,并且这种配置不仅仅是在页面上的配置,有一个插件给它,启动之后直接把这些配置导入到配置中心里面去,还可以通过启动的时候把这种配置下发到本地,形成一个本地的静态配置。

Q8:server如果断开怎么处理?
A8:因为Server是多Server集群的,如果断开了并不是说通过指定IP地址去访问这个Server,而是通过注册与发现去访问这个Server,如果Server断开了,其实也就是说他们之间没有心跳了,他们就会尝试去ETCD里面请求一个新的连接,而这个连接也会通过注册与发现,会发现其他的Server,这样的话他们就会连接。

0 个评论

要回复文章请先登录注册