基于微服务的Real DevOps实践

《基于微服务的Real DevOps实践》要点：
本文介绍了基于微服务的Real DevOps实践，希望对您有用。如果有疑问，可以联系我们。

锤子两年前登陆墨尔本时,完全是DevOps小白.面试REA的时候,被问到什么是Continuous Delivery(持续交付),锤子诚恳地表示“不知道”.面试官不依不饶,“不知道不要紧,你想想怎么样才能做到Continuous Delivery?” 锤子回顾了一下自己维护项目时的噩梦,斟酌着用词说：“这需要好多自动化的工具支持,怎么测试,怎么接入不同的网络,怎么部署不同的环境,还有数据库的data migration和回滚,个顶个的都是痛点.”

之前锤子所做过的系统都是Monolith(单体)架构,所以,每次需要重启生产环境时,真得一而再,再而三地确认.所以当REA的同事给我讲解我们的微服务架构,和怎么做Continuous Delivery时,我问：“那最坏的情况就是重启系统了?”这个同事说：“不,重启系统是正常情况.”由此,锤子开始慢慢了解REA强大的DevOps.

微服务和DevOps

在介绍REA的DevOps之前,还是简单说说我们使用的微服务架构.

微服务有时被人诟病违背了DRY原则,但是Monolith架构下各种服务间的强耦合对于扩展部署都很痛苦,所以Don’t repeat yourself 诚然不错,微服务架构下,定义好边界之后(APIs),每个微服务独立存在,独立部署且可扩展,即使有一些简单的复制粘贴,其带来的灵活性也是Monolith架构不具备的.

在REA内部,为了保证某种程度的一致性,我们的微服务都需要遵循12 Factor：

• 基准代码： 一份基准代码,多份部署.
• 依赖： 显式声明依赖关系.
• 配置： 在环境中存储配置.
• 后端服务： 把后端服务当作附加资源.
• 构建,发布,运行： 严格分离构建和运行.
• 进程： 以一个或多个无状态进程运行应用.
• 端口绑定： 通过端口绑定提供服务.
• 并发： 通过进程模型进行扩展.
• 易处理： 快速启动和优雅终止可最大化健壮性.
• 开发环境与线上环境等价： 尽可能的保持开发,预发布,线上环境相同.
• 日志： 把日志当作事件流.
• 管理进程： 后台管理任务当作一次性进程运行.

不过不管微服务设计得如何精良,当一个“小而美”的团队(5-6名开发人员)需要同时开发维护生产环境中10个以上的微服务时,服务运行和管理上的额外复杂性使得全自动构建和部署变得不可或缺,更进一步,最好使用Continuous Delivery来解决这些问题,而DevOps为真正的Continuous Delivery提供了必要的支持.

那DevOps究竟是什么?DevOps就是更好的优化开发(DEV)、测试(QA)、运维(OPS)的流程,开发运维一体化,通过高度自动化工具与流程来使得软件构建、测试、发布更加快捷、频繁和可靠.

下面这张图(图片来源什么是 DevOps?)就是DevOps的日常.

既然DevOps不是新工具,不是新团队,不是新角色,也不是大量知识,而且DevOps的伟大实践来自于许多不同的领域,并且在IT组织内执行,为了提升IT的性能,那下面就让锤子讲讲REA的DevOps实践,首先自然从最贴近我们程序猿的全工具链开始.

REA DevOps全工具链

REA实际使用到的全工具链包括：

• 代码仓库：github企业版.
• 构建和部署工具：Buildkite和Jenkins,还有一些老的项目依然在使用Bamboo.
• 容器平台：微服务用Docker进行打包,Docker的引入让公司内部微服务的部署流程一致化.
• 环境：目前绝大部分的service部署在AWS(Amazon Web Services)中,开发环境和测试环境使用同一套IAM,生产环境使用另一套IAM,三套环境通过Virtual Private Cloud (VPC)的设置进行隔离.不同部门的不同的组在IAM下拥有不同角色和访问权限.部署采用AWS Cloudformation服务,避免手动创建和更新使用到的AWS的业务.
• 日志管理：splunk.Docker已经提供对Splunk的支持,所有微服务的日志都能够通过Splunk Agent发送到集中的Splunk服务器.集中式的日志管理方式,方便程序猿们进行trouble shooting,而且完全避免了登陆到不同的机器收集log的窘境.
• 监控：建立分层的监控体系.使用NewRelic用来监控网络、设备和应用的性能；使用AWS Cloudwatch监控AWS的服务,比如某个SQS对应的dead-letter queue里是不是收到了消息,或者AWS Lamda执行是不是有错误等；Nagios提供服务可用性监控.可以直接使用REA内部的rea-health-check库,提供心跳API供Nagios的主动模式使用；也可以通过设置接收相应的消息格式,使用Nagios被动模式监控微服务.不管哪种模式下发现问题,Nagios马上会产生告警发送到PagerDuty.
• 告警：PagerDuty.前面提到的监控工具都可以发出告警,这些告警会通过PagerDuty用邮件,Slack,电话和短信的方式通知给当时的值日人员.PageDuty虽然是全天24小时运行,也只有极少部分高优先级的告警才会在非工作时间发出.还有一个告警的来源是Zendesk Ticket,这种信息通常直接来自于客户.就我们组而言,基本上都是一些数据错误,需要个别修正.
• 协同工作：Leankit.

工具链看起来并不复杂,那么有了工具链,所有的问题就迎刃而解了吗?答案自然是否定的.

怎么样自动化所有流程?怎样为REA超过40个组管理AWS的账号?怎么为AWS里的测试环境和生产环境配置VPC?怎样把微服务部署到不同的环境?监控的策略怎么样实施,怎么样在不同的组之间协调?所有的几百个微服务,一旦某些微服务除了问题怎么办等等.这些都需要工具链切切实实的落地.

REA DevOps工具链的实施过程中,分层协作不但厘清不同部门的责任,也让所有开发人员参与到Operation工作中,让DevOps融入每个IT人员的日常.

REA DevOps的分层协作

REA DevOps不同层面的问题由不同的组负责,如下图.

不同的Squads(REA引入了Spotify模式)使用DevOps工具链来开发和维护自己的微服务.详情会在下面一节进行介绍.

（编辑：ASP站长网）