发布及其检查的自动化实践

标签: 产品和系列专题 Dubbbo 发布 实践 服务 | 发表时间:2013-01-23 12:42 | 作者:李 鼎
出处:http://rdc.taobao.com/team/jm

这里记录的是Dubbo注册中心的发布过程中的自动化改进点。实践是通用的,希望可以能给你一些借鉴和启发。

Dubbo注册中心记录整个网站服务信息,服务消费者(Consumer)通过注册中心获得服务提供者(Provider)列表,才能完成服务调用。注册中心是网站服务的一个关键组件。
# 现在一个站点的注册中心上的服务Consumer和Provider就有35K+。

随着注册中心的服务越来越多,注册中心上的功能越加越多,注册中心上线发布和验证的过程变得越来越复杂繁琐,发布过程常常会出些问题,发布过程变得危险重重。

应付这些复杂就是持续的改进发布及其检查。

(1) 数据库配置错误

阿里系线上发布有, 生产环境预发布环境 2套,这2套环境是隔离的,不同环境的注册中心使用不同的DB。应用先在预发布环境发布,检验没有问题后在生产环境上发布。

发布是由SCM来做的,通过使用不同配置文件(包含不同的DB配置)打包发布。

人操作就会有出错的可能。有一次SCM在生产环境配置了预发布环境的DB。DB中有预发布环境的Provider数据,导致线上应用出错。

解决方法

监控注册中心布置目录下数据库配置文件值是否正常。

Dubbo注册中心的DB信息配置在 jdbc.properties文件中:

database.url=jdbc:mysql://1.2.3.4/dubbo_registry
database.username=dubbo_registry
database.password=dubbo_registry
......

监控这个配置中database ip、用户名的值是否预期的。

PS:监控 文件的内容,URL的输出结果,URL响应时间,硬盘、内存、网络使用量 等等是监控系统的基本功能。

原则

人的操作是可能出错的操作。
可能出错的地方都加上监控,这样出错了就会报警出来。
这样的监控项应该一直开着。

(2) Consumer和Provider的数据核对

注册中心的发布后,要Consumer和Provider核对发布前后是否有缺失。

  • 如果没有缺失,安心完成发布。
  • 如果有缺失,则要处理,找出原因,比如,少的Provider是真的下线了?注册中心原来的脏数据?自己不能处理,则要联系对应应用的负责人一起确认处理。

解决方法

1) 注册中心提供URL可以Dump出Provider、Consumer的数据:(实际上也会做方便查看的页面。)
# 提供URL是可以方便和脚本集成,可以用其它的方式。

13210 provider instance

dubbo://10.200.216.119:20882/com.aliyun.crm.panorama.webx.BucAclService com.aliyun.crm.panorama.webx.BucAclService:1.0.0
dubbo://10.246.130.110:20880/com.alibaba.havana.api.member.JoinService hz_idc/com.alibaba.havana.api.member.JoinService:1.0.0
dubbo://10.246.130.110:20880/com.alibaba.havana.api.member.MemberService com.alibaba.havana.api.member.MemberService:1.0.0
dubbo://10.246.130.110:20880/com.alibaba.havana.api.member.MemberService hz_idc/com.alibaba.havana.api.member.MemberService:1.0.0
dubbo://10.246.130.110:20880/com.alibaba.havana.api.member.OperatorService hz_idc/com.alibaba.havana.api.member.OperatorService:1.0.0
......

2) 在发布的关闭脚本 和 启动脚本中,添加逻辑:把数据Dump到文件中

wget http://127.0.0.1:${APP_PORT}/sysinfo/dump/providers \
    --timeout=15 --output-document=$DUMP_DIR/providers.dump \
    --output-file=$DUMP_DIR/providers.dump.log

3) 添加一个脚本,Diff数据前后的Provider数据。比如简单的实现可以是

$ diff dir1/provider.dump dir2/provider.dump

直接使用diff命令输出的格式不方便直接阅读,可以实现更好一些。

4) 启动完成,注册中心稳定后,执行上面的Diff脚本,快速找到差异。

原则

对于繁琐的检验操作,可以在程序添加逻辑输出需要的数据。
在发布脚本中Dump好需要核对的数据。
再通过脚本来自动完成核对操作。

(3) 注册中心状态报告

  • 为了加速,注册中心有Cache数据,比如 注册的Provider信息先在内存中,然后异步写入DB。如果这样的Cache如果长时间有数据,说明有问题。
  • 执行任务的线程池状态。如果线程池Active很高说明有问题。
  • ……

这些业务状态在发布过程也需要检查。

解决方法

注册中心有一个URL可以访问,列出这些状态的情况:

OK

[Cache]
FailedRegitered=0

[ThreadPool]
Active=30
Max=200
Idle=200
......

第一行是一个汇总行。
# 后面对比脚本可以忽略这一项。

这样可以加上一个监控项,监控这个URL返回是不是 OK

在发布的时候,只要检查这一个地方就可以拿到所有要的信息。不用到各个地方一项一项的查看。

原则

需要核对的数据,提供逻辑可以方便的查看。
如果核对是有必要持续,则配置到监控系统中。

(4) 注册中心重启引发大量动态数据删写

Provider和Consumer是动态数据,也就是Provider、Consumer断开连接后数据会被清除。

这样功能没有问题,线上有个问题是,在注册中心发布时,注册中心重启,连接断开,注册中心启动后,Consumer、Provider连接上来,注册中心会要把Consumer、Provider的数据删除和写入,造成了数据动荡:

  • 大量数据删除和写入,注册中心压力很大。
    线上注册中心多次因为这个问题导致DB被大量操作Hang住,注册中心无法完成启动,相当惊险!
  • Consumer可能收到的Provider列表缺失的(数据不完整),会引发应用的问题。
    比如Consumer收到的Provider列表只有一个Provider,Consumer调用到一台Provider上,会压垮Provider,结果服务调用出现失败。

解决方法

注册中心可以设置warm-up状态,发布完成后,等待注册中心稳定后,关闭warm-up状态。
# “注册中心稳定”的意思是,Provider已经重新连接上来,Provider数据不会再动荡。

在warm-up状态时:

  • Consumer和Provider的动态数据不会删除(写入允许)。
  • 注册中心不通知Consumer,Provider列表的变化不推送给Consumer。
    # 在注册中心发布过程中,Provider的变化很少,旧一点数据不会有问题。

有了这个功能,如果不能与发布脚本集成,那么发布过程就多个人肉操作,要和发布脚本集成。

仍然可以考虑注册中心提供一个URL来开关warm-up状态。

curl http://127.0.0.1:${APP_PORT}/sys/config?warmup=true

curl http://127.0.0.1:${APP_PORT}/sys/config?warmup=false

这样在发布开始时,发布脚本中开启warm-up状态;完成发布后等待注册中心集群稳定后,关闭warm-up状态。

warm-up一个临时状态,长时间处于warm-up状态会有故障。所以加上监控项:如果注册中心是warm-up状态,报警。
# 这个问题引发过故障,当时warm-up状态设置还是人肉完成,结果发布完成后忘记改回来了。
# 这个问题也引出另一个方面的思考,在我的下面这篇博文中说明: 准备一个安全可靠的发布流程

总结

  1. 越是容易出错的步骤越是要多执行,越需要自动化是执行。因为执行多了就可以发现容易出错的步骤,进而去找出发现出错的原因去改进,稳定可靠的执行。
  2. 自动化至关重要。当然刚开始为了安全是手执行的,手动执行几次后:
    • 步骤会固定下来
    • 会出错的地方心中有数了

从上面的发现问题到自动化解决,整个过程如下图:

发布及其检查的自动化

随着发现的问题被逐步自动化,在正常的情况下,脚本运行完成返回正常,就有信心不再需要 人肉介入了。即理想情况下,发布操作只要运行脚本的“one-line”,极简人肉介入。
# 非正常情况,如有Provider丢失,则免不了要人肉参与,和用户一起排查解决问题。 # 命令行的“one-line” vs. GUI的“one-click”

个人博客的博文地址: 发布及其检查的自动化实践

相关 [检查 自动化 实践] 推荐:

发布及其检查的自动化实践

- - 淘宝网综合业务平台团队博客
这里记录的是Dubbo注册中心的发布过程中的自动化改进点. 实践是通用的,希望可以能给你一些借鉴和启发. Dubbo注册中心记录整个网站服务信息,服务消费者(Consumer)通过注册中心获得服务提供者(Provider)列表,才能完成服务调用. 注册中心是网站服务的一个关键组件. # 现在一个站点的注册中心上的服务Consumer和Provider就有35K+.

微店 MySQL 自动化运维实践

- - IT瘾-tuicool
互联网时代,数据库如何满足敏捷开发,敏捷交付的要求. 传统靠DBA人肉执行的方式,在面对大量业务需求时,DBA手速再快,记忆力再好估计也不能提供好的数据库服务. 在介绍自动化运维之前,我们来了解下是怎么使用数据库的. 数据库的使用方式主要有两种:. 应用混合部署(实例):有新数据库需求时,很多人都会选择找个实例,建个数据库和帐号提供给业务.

Puppeteer前端自动化测试实践

- - SegmentFault 最新的文章
本篇内容将记录并介绍使用Puppeteer进行自动化网页测试,并依靠约定来避免反复修改测试用例的方案. 主要解决页面众多时,修改代码导致的牵连错误无法被发现的运行时问题. 目前我们在持续开发着一个几十个页面,十万+行代码的项目,随着产品的更迭,总会出现这样的问题. 在对某些业务逻辑或者功能进行添加或者修改的时候(尤其是通用逻辑),这些通用的逻辑或者组件往往会牵扯到一些其他地方的问题.

Python项目自动化部署最佳实践@搜狐

- - the5fire的技术博客
今天主要介绍下我们组刚刚开源出来的一个自动化部署的工具 essay ,功能在readme上已经介绍的很详细了,这篇文章只是介绍下外围的情况,产生的环境,一些决策的考虑. 事情还得从头开始说起,从那些自动化的fabric文件开始,也从我刚入职搜狐负责手机搜狐开发开始说起. 我参与开发的时候项目的部署已经是自动化了,不过并没有抽象出一个工具来.

一键实现自动化部署(灰度发布)实践

- - SegmentFault 最新的文章
在过去几年的DevOps的浪潮中,自动化、持续集成这两个概念早已深入人心(互联网技术人). 比尔盖茨先生曾经都说过:“任何技术在一个业务中使用的第一条规则就是,将自动化应用到一个高效的操作上将会放大高效. 第二条就是自动化应用到一个低效操作上,则放大了低效率. 自动化部署也逐渐成为各中小型企业追求的方向,那么,今天民工哥就自动化部署的概述、自动化部署的工具、自动化部署的流程、自动化部署实践等4个方面,与大家一同来讨论、交流一下关于中小企业自动部署的问题.

自动化接口测试实践经验

- -
作者:faithchen,腾讯 PCG 测试开发工程师. 自动化测试对于我们提升研发效能、CI/CD(持续集成/持续交付)是不可或缺的部分. 在后台自动化测试中,接口测试尤为重要,它能够保证被测后台服务的质量,以及接口逻辑的正确性等,帮助我们快速测试功能、提高测试覆盖率、把控质量风险等. 接口测试是功能测试的一种,是测试系统组件间接口的一种测试,重点在于检验对于服务接口的数据交换的正确性,一般全部依赖真实链路,测试时需要启动被测服务.

收钱吧高效自动化测试实践

- - IT瘾-dev
收钱吧业务服务千万级商家,业务庞大,产品背后有复杂的应用支撑. 我们采用了微服务架构,有成百上千个不同类型的后端服务,使用了包括Node.js、Java、Go、Python等后端语言,还有Mysql、MongoDB等数据库以及Elasticsearch、Kafka、Redis、Apollo、RabbitMQ等中间件.

前端开发中的流程自动化与提效实践

- - Joe’s Blog
随着前端的发展,越来越多的工具库、方法被用在日常研发流程中,这大大提升了业务开发的效率,而随着各类自动化流程的建设,开发同学也不再需要关注到每一个细节. 前段时间项目阶段性交付,在推进的过程中也做了不少尝试,虽然从长期看,这类工作最后可能都该收敛到基础设施部门或者标准的自动化流程中去,但并不妨碍我通过实践来落实一些对项目开发的思考和想法.

MGR复制架构+自动化运维平台,汽车之家MySQL高可用建设实践

- -
陶会祥,2020年加入汽车之家,任职智能数据中心-云平台部,负责之家数据库的运维及RDS产品研发工作,致力于为公司提供安全,稳定,可靠的数据库服务. MySQL具有开源免费,运维简单,性能好等优点,是在汽车之家使用最多的一种数据库. 数据库作为应用的后端存储,承担着数据持久化存储的功能,是应用可以正常对外提供服务的关键组件,数据库的高可用非常重要.

检查清单(20200510)

- - coderbee笔记
入参基本校验:金额不能小于0、不能大于余额、不能大于应还总额等. 请求参数用 POJO 接收,POJO 的属性要添加基本校验注解,Controller 方法要用. 正则表达式:用正则表达式进行参数校验时,不能写太复杂的,因为 Java 的正则引擎采用的是贪婪匹配模式. 超时限定:为了防止外部服务出现响应缓慢而拖累调用方,调用方必须设置连接超时、读超时等.