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

本文来自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是做注册发现的，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系统做了深度集成。服务通过实时读取配置中心配置实现动态更改分库分表的策略。

 

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，这样的话他们就会连接。

本文来自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是做注册发现的，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系统做了深度集成。服务通过实时读取配置中心配置实现动态更改分库分表的策略。

 

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，这样的话他们就会连接。