微服务:微服务配置中心架构解析

本文根据优云数智技术总监岳晓阳于8月14日可信云大会《容器和微服务》论坛演讲整理而成,主要解析了配置中心在微服务的前世今生、微服务配置中心管理及原则、微服务配置中心Hawk架构解析以及未来展望,希望对大家有所帮助。

图:优云数智技术总监岳晓阳

演讲提纲:

1.微服务的前世今生;

2.微服务配置中心管理及原则;

3.微服务配置中心架构解析;

4.未来展望

一:微服务的前世今生

配置中心在整个微服务体系里算其中一小块,只是解决了分布式环境下如何去做软件配置管理的问题。首先,先简单讲解一下微服务相关概念。

微服务本身的诞生并不是一个偶然的现象,从领域驱动设计、敏捷方法论、持续交付、虚拟化和基础设施自动化、DevOps文化这些因素都是推动微服务诞生的重要因素:

图一:微服务的前世今生

1. 领域驱动设计指导我们如何分析并模型化复杂的业务;

2. 敏捷方法论帮助我们消除浪费,快速反馈;

3. 持续交付促使我们构建更快、更可靠、更频繁的软件部署和交付能力;

4. 虚拟化和基础设施自动化(Infrastructure As Code)则帮助我们简化环境的创建、安装;

5.DevOps 文化的流行以及特性团队的出现,使得小团队更加全功能化。

软件开发经历的三个阶段:单体应用、SOA架构、微服务架构。因为本人做了差不多17年的开发,亲身经历了每一个阶段,在目前这个阶段,微服务现在基本上已经被广泛接受了。

图二:单体架构Vs. 微服务架构(来源:网络)

这里做一个比较,上图中两个架构图都是从网上下载的,实际是一个订车系统的架构,图中左侧是单体架构,右侧是微服务架构,从图上可以很清晰的看到两种架构的区别。单体和微服务的优劣对比,这里就不展开讲了,总的来说各有利弊,在一定的规模下,你很难说到底哪个好、还是不好。

图三: 微服务生命周期

从DevOps的角度来看,每次构建微服务并将其部署到环境时,都要经历组装、引导、服务注册/发现、服务监控四个阶段,分别对应了微服务开发的四个原则:

➢    微服务应该是独立的,可独立部署多个

➢    微服务应该是可配置的

➢    微服务实例需要对客户端透明

➢    微服务应该传达其健康状况

二、微服务配置中心管理及原则

图四:单体应用的配置管理

我们认为每一个大型的分布式微服务系统都需要一个配置中心。从单体应用那个时候的配置管理来回顾一下,左边的图描述的是按照不同的环境,提供不同的配置文件,将这些配置文件跟二进制包打包在一起,在Weblogic时代这是很流行的一种做法。

到现在,有些解决方案提供商还是用这种方式来实现,它也是容器运行环境,在打镜像的时候会把配置的信息和镜像打在一起。假设,实际当中有三个环境,前面是一个开发环境,中间是测试环境,后面是一个企业的生产环境。每个环境都有相关对应的配置文件,程序去哪个环境运行,就提供对应环境的运行包。

2.1 微服务系统到底怎么管理配置信息

图五:微服务系统到底怎么管理配置信息

一个系统到后面可能会拆成好几个微服务,每一个微服务可能有好多的实例,这些实例分布在不同的系统上,要让人手工去改这个配置系统——这些都是构建微服务系统需要考虑的问题,想想就是很可怕的事。这还只是一个系统,如果是多个系统呢?牵扯到多个数据中心呢?所以对于微服务的配置,我们有几个原则:

图六:微服务配置管理

1.程序和配置一定要分离;

2.配置要集中进行管理;

3.同一个程序包要适应多个环境;

4.我们要提供一个客户端去拉取配置信息;

5.服务端要能够推送,这一条主要是考虑程序运行时动态修改配置的情况。

此外,还要维护多版本的配置信息、配置中心自己的容灾以及客户端规模达到一定数量的时候,必须考虑配置中心的性能问题。

2.2 微服务配置原则

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

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

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

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

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

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

1.完全分离要部署的程序和其对应的配置;

2.程序包对于任何环境都是不可变的;

3.通过环境变量或配置存储在程序启动时注入配置。

2.3 配置中心功能需求分析

图七:微服务配置中心功能需求

上图是我们对配置中心功能需求分析的整理,主要分三个大的方面:一是需要具备的功能,二是跟其它产品的集成,三是企业级的管理属性。我们认为配置中心应该具有以下四个必备要素:

1.配置数据持久化存储。

2.可以横向扩展的缓存集群。

3.配置信息的拉取和推送。

4.配置数据及配置过程管理。

三、配置中心Hawk系统架构解析

图八: 微服务配置中心架构解析

首先,接入第一层是网关,整体的存储通过Hawk Server,下发到ETCD集群,ETCD集群再同步到K8S容器运行的平台。先从数据迁移的状态简化成简单的几部分。比如新建一个配置,要么配置就被删除了,直接一步到位。如果没有这样做,就面临几种情况:

1. 这个配置是否要小范围的去做一些试探性的发布,这种情况可以走灰度发布,状态变成灰度中,配置不允许更改。要么就是两条路走,全量发布到所有服务上。要么就是放弃灰度回到之前的状态,放弃灰度后会去到已修改的状态。

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

图九:微服务配置中心配置管理

3.1 配置数据状态变迁

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。

3.2 配置中心的支撑体系

第一种运维管理体系类似于偏静态类的配置,在启动时通过配置文件直接拉取读业务;另外一种是开发管理体系,偏动态管理,代表的是一种程序或者在运行过程中,通过实时的变更配置内容而实时生效,达到的一种效果。一个健全的配置中心应该支持这两种运维体系。配置中心应该具备有以下几点特性:

1.基于Spring Cloud config打造。

2.完全兼容Spring Cloud config API。

3.配置更新通过GRPC双向流实时推送。

4.采用ETCD作为配置数据的强一致性存储。

5.具备LDAP用户认证、授权管理、审批流程、审计日志等企业级特性。

6.通过Open API和查件体系扩展支持基础组件,如sharding-gdbc。

3.3 配置中心部署模式

微服务配置中心如何部署,一般来讲会是这么两种方式,生产环节中单独布一套配置中心,在开发环境部署一套配置中心,开发环境的配置中心可以支持Dev、SIT、UAT等多个环境。

图十二:微服务配置中心如何部署

四、对未来的展望

我们要做的工作,首先还是继续围绕Spring Cloud体系,为用户提供成熟方案和服务治理中心;二是探索基于Service Mesh的新方案,拥抱Istio/Conduit;三是配置中心Hawk我们已经做好了在GitHub上开源的准备工作,希望大家多多关注Hawk,关注您可信赖的云服务合作伙伴——优云数智。

图十三:未来展望

链接:https://www.jianshu.com/p/1c6ac83cab10

你可能感兴趣的:(微服务:微服务配置中心架构解析)