基于微服务的Real DevOps实践

最值得一提的是Delivery Engineering开发的rea-shipper.

• rea-shipper实现了从构建到部署的全自动,真正解决了最痛的那个点.
• 为了保证Zero downtime,rea-shipper读取微服务的cloudformation配置,采用immutable ASG(auto scaling group)deployment模式 进行部署.
• rea-shipper自动将监控和日志管理所需要的模块也用Docker打包,在部署过程中与每个微服务的Docker Image整合,如下图所示.这样微服务开发人员只需要关注业务的开发,无需担心日志和监控的问题.

以我们一个实际的service charge-central为例,登陆到EC2 instance之后,可以看到正在运行的几个container.

Global Infrastructure & Architecture 团队负责基础设施建设,管理维护并开发相应的工具,包括网络、数据中心、AWS账号的管理、Splunk的集成等.比如,去年悉尼大雨,Amazon的机房被水淹了,澳洲大批网站受到影响,也包括我们公司的一小部分,当时苦了GIA team的人了.

所以全工具链的配置和开发是Global Infrastructure & Architecture 和Delivery Engineering的职责,而作为程序猿的锤子,则是工具链的使用者.下面就说说程序猿所参与的DevOps日常.

程序猿DevOps日常

1. Coding

前面提到过代码库使用github企业版,采用github flow.

微服务需要的部署脚本和AWS Cloudformation的信息,提供给不同监控工具的接口,fried Docker image 定义等,也都是代码的一部分,需要开发人员完成.

2. 构建和部署

构建和部署就以Buildkite为例子,这是一个微服务的buildkite脚本.

这个流程里代码检查和单元测试自动化起来很容易,那么怎么做整合测试?REA基于Ian Robinson提出的用消费者驱动的契约进行面向服务开发的模式开发了 开源的Pact 测试框架,用轻量级的契约测试来代替厚重的集成测试.Pact在消费端用单元测试的形式(更轻)来生成 pact 契约,服务端通过验证契约来保证两者稳定集成.一旦有一端契约未经协商发生改变,那么Pact测试就会失败.

构建成功之后,会把微服务打包成Docker Image然后上传到Docker Registry.我们会选择在Delivery Engineering提供的基准Docker Image之上来打包,这是一个微服务的Dockerfile的例子：

用这种方式,在buildkite上打包并上传到Docker Registry的时间小于三分钟.

部署时,脚本会调用rea-shipper.不同的环境下,Buildkite会选择不同的Agent进行部署：Test 环境的non-prod-corp:default和Prod环境的prod-corp:default.部署的时间通常10分钟以内,下面是一个微服务部署到test(6分1秒)和prod(5分43秒)的时间,图中能够看到Cloudformation更新的步骤.

尽管是全自动的部署,考虑到生产环境的重要性,我们还是选择谨慎地Block,需要某个开发人员手动触发.触发的时间没有特别的规定,只是在我们的kanban中,deploy是最后一步,这意味着只有真正部署到生产环境,这个卡片才算完成.如果部署过程中出现失败,rea-shipper不会切换运行中的ASG(Auto Scalling Group),业务并不会受到影响.如果部署的新版本发现bug需要紧急回滚,可以很容易地根据Docker Image的版本找到相应的Image进行部署.

3. 运维

日常的运维如下图所示：

需要处理的问题一般有两种：

• 直接源于客户的问题,使用Zendesk Ticket.
• 源于生产环境的问题,比如PagerDuty告警.

（编辑：源码网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!