转载

配置中心一团糟？Hawk微服务化改造切合企业系统需求

配置中心一团糟？Hawk微服务化改造切合企业系统需求微服务近年来炙手可热，如果在后端服务领域诸多热门技术趋势中，比如容器、微服务、DevOps等，找出一个最火的方向，那么非微服务莫属。微服务架构通过有效拆分应用，解耦系统，提供更好的软件伸缩性和企业的敏捷性，实现敏捷开发和部署。

它不是一种横空出世的技术，事实上微服务microservice的概念已经存在多年，一度曾是软件开发的宠儿。近年来被越来越多的企业和开发人员所推崇，并在互联网企业当中大量落地。一些有代表性的传统行业通过实施微服务架构，提高业务灵活性，加速业务需求变化和响应。

微服务化作为一个体系，包括开发框架、以及周边配套工具链，比如服务治理、配置中心、安全管理、与容器的结合、监控管理等等。往往，围绕微服务的管理体系是微服务搭建的难点所在。

接下我们就谈谈配置中心的架构与实战。

1为什么需要配置管理中心

首先，我们的观点是，每一个稍微有点规模的分布式系统，都应该有一个统一配置中心。

当今的系统，随着系统的复杂度增加，配置也日益增多，随着devops等概念的推广，人们对配置的期望值也越来越高：期望配置修改后实时地生效，期望支持灰度发布，发布回滚，历史追踪，环境隔离，集群配置，服务治理等等，这个时候分布式统一配置中心就变得尤为重要。

配置中心解决什么痛点：

把业务开发者从复杂以及繁琐的配置中解脱出来，只需专注于业务代码本身，从而能够显著提升开发以及运维效率。同时将配置和发布包解藕也进一步提升发布的成功率，并为运维的细力度管控、应急处理等提供强有力的支持。

配置中心的使用场景：

在服务构建阶段，配合构建流水线，为服务软件包或镜像提供配置。在服务运维阶段，动态调整服务配置，满足运维的灵活性需求。在服务开发阶段，提供 OpenAPI，为其他基础设施的配置外置化，中心化提供支持。配置中心Hwk产品需求：

基于上述一些列的特点，我们构思了自己的配置中心的产品需求：

为分布式系统中的基础设施和微服务应用提供集中化的外部配置支持，实现了对服务端和客户端中环境变量，配置文件，动态属性配置的抽象映射，并支持配置的灰度下发，历史版本控制等先进功能配置接口完全兼容 Spring Cloud Config，后台管理功能则通过 open API的形式对外开放，满足企业多样化的定制需求管理Springcloud的微服务框架的业务配置，服务治理配置以及kubernetes的configmap和secrets的配置，同时也能通过插件的方式对流行的第三方类库提供特别支持，比如与 sharding-jdbc 的深度集成 2

数人云hawk的架构

配置中心是一个强一致性的系统，配置数据不一致会一起严重的业务问题， Hawk 使用读写分离的方式处理配置数据，Hawk Portal使用mysql 存储配置数据，并把通过审核的配置数据同步给 HawkServer，Hawk Server 使用etcd 来存储并下发的配置数据。

认证与授权

认证与授权分为 Hawk Portal 和 Hawk Server 两个部分来看。

Hawk Portal

在用户使用 Hawk Portal 管理微服务应用和基础设施的配置之前，首选需要使用用户名与密码登录。这是一个简单的 Form based login，目前展示不考虑与企业的认证与授权中心进行单点登录，但需要能够允许用户通过存储在企业 LDAP 中的用户名和密码登录。

Hawk Server

对于微服务应用通过 Hawk Client 向 Hawk Server 发起远程调用的时候，无需认证与授权过程，仅做必要的 TLS 对客户端进行身份认证。

当用户通过 Restful API 访问配置服务时，需要对用户的身份进行认证，用户的认证在 API Gateway 上完成而不是配置服务本身。

服务发现

etcd 同时也为 hawk 提供服务注册于发现的能力，Hawk Portal 与 Hawk Client 都通过 etcd 提供的能力发现和调用 Admin Service与 Config Service。

配置存储

企业基础设施与微服务应用的配置数据，以及 Hawk 配置中心本身的配置信息首先在 mysql 中落盘，仅当配置数据被激活后，才会同步到 Hawk Server，然后由 Sync Service 落盘到 etcd

领域模型。

集群管理

Hawk 可以同时管理多个配置集群，devops 用户可以把不同的集群映射为不同的执行环境，比如开发环境 DEV，功能测试环境 FAT，验收测试环境 UAT等等，使用一套配置中心同时支持多种环境，降低维护成本。

生产环境一般不会与上述环境部署在一起，此时用户可以把配置集群映射到不同的部门，在物理上隔离不同部门的配置数据。

配置集群也可以用于在物理上隔离不同资源的配置，比如区分基础设施(消息中心，调度中心，微服务中心，存储中心)和微服务应用。

配置下发

微服务应用可以通过Hawk 提供的客户端 SDK Hawk Client 获取配置，也可以通过 Spring Cloud Zuul 服务网管来使用 Config Service 提供的兼容 Spring Cloud Config 的 Restful 接口。

Hawk 可以通过推送的方式把配置变更直接下发给 Hawk Client ，通过这种方式，配置可以实现实时更新。

Hawk Client 在获取配置信息的同时会连接到配置信息所在的 etcd 集群，并 watch etcd 中的配置配置数据。当 etcd 集群中的配置信息更新后，Hawk Client 将会收到通知。

Hawk Client 提供原生接口允许微服务应用注册监听器监听配置信息的变化

服务治理

配置中心的配置管理和动态配置下发能力，使得它可以承担服务治理中的 Control Plane 的职责，它可以把服务治理相关的配置下发给实际的执行模块，比如 dubbo，或者是 Spring Cloud 集成的 Netflix 治理工具库，比如 hystrix 以及 ribbon。

服务治理的主要功能包括：

注册/发现：服务实例启动后，将会自动通过 Hawk Client 向配置中心注册，运维可以在配置中心门户查看服务的实例列表，并进行实例级别的服务治理。
负载均衡：调用其他服务时，可以灵活指定其负载均衡策略，如 round robin, hash, consistent hash, weight based round robin 等等。
路由：配置微服务的路由策略和路由规则，路由策略如本地优先，本地数据中心优先等等，路由规则如白名单，黑名单，流量引导，读写分离，前后端分离，灰度升级等等。
限流：针对某个调用方限流对象进行 QPS 限流，分钟级或秒级，或针对所有微服务客户端进行限流。
降级：针对某个降级对象，进行手动或者自动降级（容错），并制定降级策略，抛出异常或特定返回值。
容错：针对某个微服务，设定调用超时与重试策略。
熔断：针对某个微服务或者 RPC方法，设定熔断的触发条件，可以强制熔断，或者自动熔断，也可以取消熔断，运维可以指定熔断参数，比如异常，错误码，失败次数比率，时间窗口，以及窗口请求书等等。

3Hawk基于Spring Cloud的服务治理系统目标

抽象与具体的服务框架隔离的治理的数据域模型,在系统中均用系统的域模型表示所有的服务治理参数信息,下发到客户端后,能转化成相对应的服务配制信息。

功能分类

为其他应用提供服务：注册；
为调用其他应用提供服务：发现和负载均衡；
应用保护自己:熔断并且包含容错，降级。

数据流向场景

用户在potal上配制a应用要调用的服务b和c,以及a应用的基于Hystrix的熔断配制信息,这些熔断配制可以保存客户端需要的熔断配制信息；
a应用启动,hawk client客户端启动；
hawk client到server拉取a应用的配制,a应用注册到hawk server；
a应用根据配制中的上游服务名b和c,发现提供b和c服务的实例；
根据配制中的负载均衡的算法给每个上游业务配制负载均衡器；
根据配制的熔断参数动态调用相应的功能插件生成各服务框架的标准参数格式,注入到应用中。

组件

服务治理的namespace命名: governance

负载均衡/路由(这里可以让用户自由输入ribbon的配制)

熔断设计

说明:

基于sping cloud的为基础,抽象出熔断的模型.前端通过界面操作，生成自说明key，保存成kv格式。

比如sc应用,全局的command对象的execution的timeout的enabled选项参数生成的key值是

hystrix.command.default.execution.timeout.enabled=true；

对于其他服务框架的配制主要映射到这个模型的相应字段上。

参考：

http://support.huaweicloud.com/usermanual-cse/cse 01 0025.html

https://github.com/ctripcorp/apollo

https://github.com/knightliao/disconf

https://github.com/Qihoo360/QConf

4问答环节

1、 Q：请问配置中心存储的是配置文件还是key-value? 像数据库连接串之类的信息如何管理的？跟数据连接池怎么配合？

A：是key-value的，存储在etcd集群上，服务可通过hawk-client拉取配置到服务本地生成本地的配置或直接导入到本地环境变量，这些配置随着服务启动就会生效。

2、 Q：请问Hawk是一个产品吗？

A：Hawk将会是数人云推出的一个企业产品，同时也会作为一个开源项目发布在github上，具体的开源时间我们还不确定，相信很快。

3、 Q：为什么要自己开发一个配置中心，而不是直接使用Spring cloud config？

A：其实很简单，单纯的spring cloud config没有办法充分地切合企业系统的生产需要。我这里有一个功能对比图，大家可以参考一下。

配置中心一团糟？Hawk微服务化改造切合企业系统需求

4、Q：请问这个配置中心只能应用于Java语音吗？

A：配置中心的代码是Java编写的，但是配置中心的使用方，即拉取配置的一方是不限制语言，因为配置拉取是基于http协议。

5、Q：请问数人云的官方网站有关于Hawk这个产品的详细功能介绍吗？今天讲得还是比较快的，希望能具体了解；谢谢。

A：有的， https://www.shurenyun.com/product-hawk.html

6、 Q：请问CI/CD流程控制是自己研发的还是用的开源方案？

A：CI/CD持续集成，持续交互其实是一个很大的概念，我理解你想问的是Hawk的操作流程以及所使用的技术栈的问题，最初我们参考过其他的一些开源比如携程的appolo，百度的disconf等，结合他们的一些理念，我们又自己总结思考了自己的需求，对CI/CD的业务做出归纳，以达到简单直接的目标，技术方面，我们主要用到spring boot， spring cloud以及etcd等技术，其中spring cloud主要适用于服务注册发现，服务治理等方面。

7、 Q：我想问下，关于配置中心部署问题，第一个，不同环境或者不同集群，你们配置中心是怎么部署的，还有，一些基础组件配置和应用配置放在一个配置中心吗？

A：配置中心通过不同的存储集群，可以实现一个配置中心服务多个环境，但是原则上，建议测试，开发公用一个不熟而生产独立部署，配置中心的中心概念是基于微服务，所以从概念上说，我们的配置是生效于一个服务下的实例级别，而不是组件级别，每个实例下又分为不同的命名空间，命名空间可划分为：应用层，环境变量和自定义的组件，可由客户自定义，所以原则上涵盖了组件与服务的概念。

原文 http://blog.shurenyun.com/untitled-134/

正文到此结束