公司介绍
产品展厅
公司相册
资质证书
新闻资讯
人员计划
服务网络
联系我们
 
LED行业资讯        您当前的位置:首页 > 服务网络  

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

时间:2018-08-21 19:06:36  来源:本站  作者:
公司

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

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

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

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

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

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

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

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

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

  首先必须基于镜像管理部署,有自己相应独立的配置,而且程序包不可以因为环境的改变而更改。也就是说,它是独立于环境的不可变的程序包。

  其次所有的微服务通过环境变量或者配置存储时,在启动的那一刻,就可以做配置,也可以通过动态的修改实时生效。

  一个微服务从打包、上线、部署,打包以后,会在启动阶段从配置Configuration Repository 里面拉取它的配置,通过注册与发现,注册在注册中心里,在启动时,把服务中心的配置拉取到本地,成为应用的一部分。

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

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

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

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

  全量更新,灰度更新,或者回滚,必须是可在任何时候查看,在某一个任意的时刻,回滚到某一个历史点的配置。

  最后一个是要有多集群的启动,所谓多集群的启动就是,我们把配置存储的时候,必须存储在一个多集群的环境里面,以达到物理隔离的目的。

  另外还有一些原则,业务无关性、 Open API、配置生效监控。就是说配置中心必须提供API给第三方的系统来使用。配置的生效监控是,必须实时知道,有哪些服务拉取了配置,是否已经生效,或者这个配置的效果如何?

  第一种运维管理体系类似于偏静态类的配置,在启动时通过配置文件直接拉取读业务。

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

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

  这种配置各有各的特性,所以我们就挑选了一些有经典案例的,通用性的东西来做配置的集成,比如原生支持SpringBoot、Spring Cloud,集成支持k8s,就是k8s容器。

  数人云分布式统一配置中心,取名Hawk。Hawk基于ETCD打造,主要解决把开发人员从复杂的业务流程和烦琐的配置中解脱出来,让开发人员只关注自己的业务代码,把运维、配置这些剥离出去。同时降低服务部署、发布过程中的风险。

  基于微服务体系理念打造的分布式统一配置中心Hawk支持多种类型配置:如Spring Cloud、 Dubbo、Kubernetes Configmap、Logback、Linux Environment,具有完善的配置管理流程、配置实施推送、支持多集群多环境、多版本控制,更提供配置细粒度的管理如灰度管理、任意版本重置等丰富功能。

  整个体系兼容开源社区的Spring Cloud Config以及Kubernetes的Configmap,极大降低使用者的学习门槛以及业务对平台的耦合。相应的管理流程也规范了配置的使用,降低配置带来的发布错误等。

  支持配置实时推送以及实时生效,在程序的运行过程中,不能说把服务停下来才能更新,必须实时配置,实时生效。

  支持多版本管理,配置不管哪个版本,都可以随时查看、查阅以及激活历史的版本,并做发布。

  支持多集群环境,多环境配置。通过数据库或者后端存储,以达到支持SIT、UAT环境的体系。

  优美的监控台,提供多维度Dashboard以及监控视图,支持配置灰度和回滚。

  首先接入第一层是网关,整体的存储通过Hawk Server,下发到ETCD集群,ETCD集群再同步到K8S容器运行的平台。

  刚才有同学说Hawk跟阿波罗有相似的地方。在研究对比时,我们觉得阿波罗出于业务需求,有一些比较复杂的地方,决定把流程简化。

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

  另外一种情况,新建一个配置,直接全量发布,状态变成已发布状态,这时候是可更改的。但是每一次的更改,还是会回到原来那个状态。这个更改要做灰度吗?还是做发布?还是对发布有点后悔,不打算更改了?这时,从历史版本里面找一个合适的版本,激活,然后再做一次发布,通过几个简单的回路,涵盖了大部分的业务场景。

  Hawk Portal是主体的配置界面,用户在界面上对配置进行输入、增删、改查的管理。这些资料会有两份,一份做通过Mysql做本地存储,另一份通过Hawk Server直接同步到ETCD。

  由于HAWK Server是同步到ETCD里面,也就是说ETCD相当于另外一个数据库,这当中不存在数据之间的互相抄送,从而减低丢失数据的风险。持久化,是说研发和运维在后台做数据迁移,或者数据监控时更有把握,更方便。

  数人云HAWK其实有两个ETCD,一个ETCD是做注册发现的,HawkServer、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系统做了深度集成。服务通过实时读取配置中心配置实现动态更改分库分表的策略。

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

  A3:目前来说ServiceMesh还是一个比较新的东西。如果ServiceMesh是独立配置的话,其实可以支持到。但是ServiceMesh有非常多的特性,还不敢说100%可以支持得到。其实数人云也在做ServiceMesh相关的项目,就是说它以后还是有非常大的可能,还是要集成ServiceMesh配置中心里面做一个闭环。目前这个版本支持一些比较轻量的配置。

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

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

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

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

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

Copyright © www.g22.com Inc. All rights reserved 版权所有:太阳城娱乐城 沪ICP备07029879号
友情链接: