微服务来了,配置怎么办

1年前

微服务来了,配置怎么办

配置管理是个简单的小话题,做技术的都非常熟悉了解,那怎么就跟微服务挂上钩了呢,前些年不提微服务的时候,大家也都会做配置管理相关的事情,我接触过的很多项目都是手工改配置,上线靠手工操作,运维阶段手工改配置重启服务,好像也能凑合。

其实不论有没有微服务,把配置管理好的手段和方法都差不多,只是做了微服务有了大量的分布式进程后,再不把配置好好管理一下,还想继续凑合就行不通了。

我今天主要也是跟大家一起梳理一下把配置管理好的一些思路和方案。

 


今天的内容主要就是这5部分,前三部分就是先理清楚概念。

第四、五节就是介绍一下我认为比较好的配置管理方式介绍给大家

 

我们先来看看软件配置的定义

配置是独立与程序的变量,配置通常有各种形态,比如有人喜欢用配置文件、还有人喜欢用数据库表、系统环境变量、进程启动参数等。

一般我们会把配置按程序启动为分界线,分为两类:

1、运行前的配置

2、运行时的配置

运行前的配置,通常是指与环境相关的一些配置,比如数据源、邮件服务器地址,不同的环境有不同的值。

还有一类比如安全控制类的,例如weblogic服务启动时,会要求输入启动账号密码等。

当程序把环境相关的参数设置好之后,才可以在对应的环境上正常启动运行。

运行时的配置,通常就是一些可以动态调整的参数,程序会根据不同的参数值产生不同的行为。大致分两种:

1、技术运维相关的参数,如线程池大小、队列长度,调整为不同的值会有不一样的性能表现。

2、业务相关的参数,比如贷款系统贷款额度调整,贷款利率调整。

动态参数发生变化时,程序运行行为会有变化,计算结果可能不一样。一般运行时的配置调整,最好是能够做到动态的热更新,不需要重启动服务才能生效。

 

接下来我们一起看配置与程序的关系

 

首先,配置管理的前提是程序与配置要分离,如果是写死代码的话,配置管理也就无从谈起了。

其次就是一套程序支持多套配置,这是针对静态配置来说的,一套程序,不同的配置值,适应不同的环境。

再次就是程序是稳定的,配置是可变的 ,运行时,程序根据配置值的变更会产生不同的行为并得到不一样的计算结果。需要注意的一点就是,由于配置会有调整,因此配置需要持久化保存,不要放到虚机和容器的内部存储中,避免虚机、容器重启动后配置丢失,还原成镜像的最初状态。

 

我们再来看一个比较重要的公式:介质+配置=部署包

这个也主要是针对静态配置的。介质就是程序,配置就是适合环境的配置值,两者组合成的部署包就成了某个适合具体环境安装部署的部署包,有了这个环境部署包,我们就可以非常方便的把部署包安装到对应的环境中。

程序与配置关系中,比较重要的几个点再小结一下:

•              程序配置要分离

•              一套程序,多套配置,适应不同环境;介质加配置等于环境部署包

•              动态配置变更需要支持热更新

•              程序稳定可以做成镜像,配置可变需要持久化存储

 

接下来,我们再看看配置管理需要关注的几个维度


配置是需要治理的,配置管理的过程中,我们需要考虑这么四个维度。

一、多环境管理,维护好环境与配置的关系,即不同环境不同配置

二、影响范围控制,运行时配置变更后,会影响单点还是集群,是只影响一个应用,还是会影响多个不同的应用

三、配置管理过程需要有权限控制,严格的话配置变化还需要有流程审核才能发布。

四、配置变更操作需要审计,要知道什么人、什么时间修改了哪些配置。每次修改发布都要留痕,也就是有多版本,一旦修改除了问题,可以进行回退操作,回到修改之前的状态。

以上这四点,静态配置通常关注 134 动态配置关注 234

 

接下来是静态配置如何管理

 

先来看一个反例,一些企业比如金融行业,非常重视上线过程的流程和操作合规性的,但现状是没有技术手段支撑,全是手工操作,开发人员和运维人员都很痛苦,真个上线周期很长,还非常容易出问题。

功能开发结束后,开发人员为了上线,先要准备一堆文档,比如操作手册,要写成运维人员不需要思考,完全机械化的按步骤复制粘贴,就能完成操作的状态。比如在什么目录下某个文件里面,配置数据源,然后再负载均衡什么目录下配置Ip端口等等。

先写个半个月,然后评审,接下来再演练,反复进行好多次,最后才能上线。开发工作量和上线过程的工作量几乎到了11.  效率非常低下。

 

我们推荐的做法是要流程和技术并中,通过自动化的手段,将介质和配置组合,打出适合某环境安装的部署包,非常方便的交付到开发环境。

集成过程中设置好配置值,编译后可以直接注入配置作出部署包,如果有自动化部署服务能力的话,就能够自动的吧部署包发布到对应的环境中了。即便没有自动化部署,一个已经配置好的应用部署包,手工操作起来也是很简单的事情,解压到合适的位置就好了。

 

这里介绍两个静态配置管理的方案。

先说一下使用Spring Profiles管理多环境配置。Spring提供的组件,提供了应用程序在不同环境中使用不同配置的能力。

我举的例子是在spring boot应用中的用法。如果使用properties文件存储配置时,可以为每个环境分别设置一个配置文件

如果使用了yml格式的配置文件的话,不同环境的profile需要在同一个配置文件里面定义,类似右边的图里面的方式。

定义好后,在spring boot应用启动时,可以通过参数指定激活那个profile,然后spring boot程序就会加重对应profile下的配置值。

 

再看一下方案2SCM + autoconfig,图片中包含文字介绍

 

 

我们看一下autoconfig 是怎么做配置注入的,主要分三个步骤。

1、配置模板抽取

2、配置元数据定义

3、配置文件注入

application.template是根据application.yml抽取出来的配置文件模板。其中${}内的字符就是配置项名称。

auto-conf.xml主要包含两部分:

1)配置元数据的定义,即配置项的定义

2)配置文件生成的脚本定义,如<generate template="application.template" destfile="application.yml"/>

有了模板和配置元数据的定义,再加上配置值就可以执行一行命令,把配置值注入到目标文件里面。

autoconfig工具非常强大,针对的是目标文件,不依赖编译框架。在编译过程中编译后都可以执行,能够注入压缩包里面的配置文件。

 

再强调一下,配置管理是软件交付过程中的非常重要的环节。

如果说没有软件配置管理的话,项目会是个什么样子,开发人员没定义或者乱定义,测试人员不会装不会配,上线的运维人员更不会了。

这种状态下,想要成功上线,就只能回到严格控制流程,逼开发写文档,逼测试演练,运维逼成机器人。大家都得干枯燥无味的事情。

SCM的作用就是要支撑软件配置的协作化管理,通过SCM提供的能力,可以让开发人员再设计过程中,规范的定义配置项,并设置好默认值。测试人员负责设置测试环境需要使用的配置值,运维人员负责生产环境的配置值,做好这些后,持续集成和交付服务可以快捷的编译出部署包并安装到目标环境里。

其中,版本、环境、角色、权限、流程 配置管理服务SCM都有相应的能力支撑。

 

我们看一下方案二对应的持续集成、交付示意图。

这个是我们DevOps产品的一个CICD示意图。

开发、测试、运维人员,通过门户去设置不同环境的不同配置值,然后发起编译、打包、部署操作,后台就由各服务自动的进行源码编译、配置注入、自动部署等操作。

开发人员不用写那些一堆上线操作手册了,只需要定义配置项,设置默认值。测试人员、运维人员也都设置自己维护环境的对应配置,评审都是在线进行,审核通过,点个按钮就自动部署。

能让机器代劳的工作,尽量少让人手工干。

 

 

我们看一下,SCM服务的主要概念模型。

 

 

再看一页DevOps门户中,部署设计中配置项设置相关的页面截图。

 

 

静态配置管理的两个方案对比如下:

 

我们再来看看动态配置如何管理

 

我们先回顾一下动态配置的一些要点

动态配置通常包含,业务运营配置,和技术运维配置。

动态配置管理,通常就需要考虑右边这三个维度,影响范围、权限控制、审计很多版本

当然还有一个隐含的要求就是要支持热更新。

 

传统动态配置管理的方案和微服务架构下的管理方式思路基本一致。

主要是这三个方面:

1.应用状态统一管理

2.中心配置仓库

3.配置推送和拉取

区别就是,以前分布式程度低,很多情况都是手工维护。比如应用状态管理、集群配置都是手工维护的。很少有做配置修改审计和回滚的。

微服务架构下,我们需要更加灵活,快速变化。那么应用需要自动注册发现,应用很分散,审计的需求加强了,异常回退的需求也来了。

 

上图是微服务架构下的一个配置中心架构示意图。

我们的微服务平台配置中心是选用了携程的Apollo,也是功能非常强大,需要的能力基本都是现成的。

微服务中心能够方便的与注册中心集成,我们的微服务平台是基于Spring Cloud,而Apollo也是能够跟Spring Cloud这套环境方面集成。

 

Apollo的主要概念模型如下:

 

上图是我们的微服务平台管理门户的应用配置管理页面,通过管理门户,控制应用管理配置权限

每个配置项修改分为保存、发布两个动作,发布过程可以支持流程审核

配置项值变更多版本记录,可以回滚到某个历史版本

 

最后,我们一起回顾一下今天的内容,

 

我们讲的配置管理,主要就以 运行前的静态配置和运行时的动态配置 入手展开的。

配置管理的前提,就是程序和配置要分离

静态配置考虑多环境,要管理配置和环境的关系

动态配置要考虑影响范围。

两者都需要考虑的是,权限、审计、多版本

那我们要做好配置管理,需要在不同的阶段,配合一些手段来逐步实现。

•              先定规范,要求程序和配置分离

•              然后统一打法,选合适的技术框架,让配置定义、加载、热更新等方式尽量统一

•              最后平台化,做规范化的集中配置管理

 

今天的分享就到这里,谢谢大家!


COMMENTS

需要 后方可回复
如果没有账号可以 一个帐号。