作者：汪照辉 王作敬

软件工程有时候像养孩子，虽然生育的过程是痛苦和困难的，但养育孩子长大成人的过程才是真正需要花费绝大部分精力和成本的地方。通常我们都在讨论软件开发过程，追求敏捷化、精益化，却比较少讨论其部署、发布、运营、维护的过程，但有数据显示，软件系统在运营维护期间的花销占整个生命周期费用的40%-90%。服务化架构更强调“持续改进”，一个服务开发测试完成、部署到生产环境到正式发布，它是相对“稳定的”。所以现在很多人推崇DevOps，持续的集成、部署、发布、监控、反馈、改进，从而形成一个闭环，以适应业务需求快速变化的要求。
DevOps提倡开发运维一体化。但就像上篇文章我们提到的，一个人覆盖微服务整个生命周期并不可取。Google把专注软件设计和构建作为一种职业，专注于整个软件生命周期管理作为另一种职业，也就是Google SRE。我们强调微服务生命周期过程中需要不同的角色来协同完成微服务生命周期管理过程，需要不同的人来参与，明确各角色的职责，尽可能的采用自动化和工具链，减少人的影响因素。DevOps和Google SRE的思想其实是相似的。都是强调不同组织不同角色不同流程之间的融合和协调，其实和微服务架构的思想也是相似的：协同、合作、融合。
微服务部署发布运营以镜像仓库为起点，避免频繁的构建，也避免代码分支的频繁迁移和合并。不同的代码分支标记不同的版本。

一、 角色定义

软件生命周期过程，人是决定因素。软件发展的短短几十年，可以很清楚的看到一个人往往能够指导一种软件的成功，带动一家软件企业的成长，引领一个时代的发展。软件研发其实是智力比拼，但软件发展到当前阶段，已经过了单打独斗的时代（单体向分布式微服务发展），成功需要的是一个高效的团队！所以我们并不认为开发运营一体化就是一个人干所有事情。
高效的团队需要合理的人员分工和角色定义，而DevOps生来就是了解决效率的问题，解决团队之间的协作和融合问题。人员分工和角色定义毋庸置疑的落在了DevOps的身上，为微服务生命周期过程中定义合适的角色和流程，协调各角色的任务以高效执行。
我们在DevOps探索一文中提到过，微服务部署发布运营阶段角色大致划分为业务应用运营、环境维护和资源运维三种角色。业务应用运营角色专注于业务应用的运维运营，使用基础设施平台和基础设施资源，关注点是业务应用，可能和业务应用开发团队、测试团队是一个团队（开发运维一体化）；环境维护角色专注于各个环境的正常运行，使用基础设施资源为业务应用团队提供应用运行必需的各种环境，其可能包括平台运营团队和中间件运营团队；资源运维则专注于基础设施资源的运维，为各种环境提供健康的基础设施资源。

图1 运维角色
资源、平台、应用角色职责清晰，而又能方便的整合企业的各类资源。也可以从一个部门甚至一个团队起步，实现部门内或团队内的资源整合。进而在合适的时机进行推广。

二、 平台支撑

这里的平台指的是托管运营运维业务应用/微服务的PaaS平台和基础设施资源平台等为保证企业业务应用正常运行所需的设施。基于平台思维，让技术回归到业务中心，让业务运营运维更敏捷，保持强竞争力和高效的交付能力。其建设思路就是企业统一服务中台的建设。
要实现这样的能力，首先要整合基础设施资源。计算资源（CPU、内存等）、存储资源、网络资源、云端资源、操作系统资源等都能整合，实现资源的自动管理、调度和分配。每种资源都有众多的类型和厂商提供，适用的场景也有不同，整合这些资源并不容易，需要有相应的专业人员来运维，确保资源的可用性。
PaaS平台或者容器平台需要基础设施资源的支撑，目前的容器调度管理框架并不具备完全的资源运维管理能力，需要借助于虚拟化或IaaS层，但通过采取相应的措施基本上可以满足大部分场景需求。平台提供业务应用和微服务托管、运营运维所需的环境、工具和资源。
PaaS平台就是一个云操作系统，在其上需要实现业务应用和微服务开发、运行、托管、运维、运营等所需的各种工具。所以PaaS平台建设并不容易。当然也很多仅实现单一功能也称为PaaS平台，不过我们觉得有点偷换概念。容器云平台是PaaS的一种实现，利用容器等技术支持业务应用和微服务的调度管理运营等能力。
微服务架构是云计算平台上业务应用重构或新业务应用（云原生应用）开发的便捷方法。要支持微服务化业务应用的部署运营，相应的服务注册发现、日志、监控、网关等基础组件必不可少，另外还需要众多的中台服务支持，比如计算引擎服务、搜索服务、消息服务等。这些服务和组件都是基于平台为微服务化业务应用提供运营支撑。
平台及平台之上的各种中台服务以及中间件服务都需要相应的人员来运维，在业务应用需要的时候以其支持的方式提供服务。而业务应用微服务只在需要的时候使用这些服务，按需使用，业务应用通过多租户机制进行业务隔离。
采用微服务还有个重要的组件API网关，通常包括API网关、API管理、API集市及API开发等工具。各种中台服务通过API网关提供标准API服务。API网关提供了一个稳定的可重用层，这是非常关键的。
最后我们还想着重强调一下“数据”，数据中台服务能力。我们也简称为数据中台服务，在平台上要实现企业唯一可信数据来源的中台数据服务能力。

三、 微服务部署发布

（一） 持续部署

我们也一直考虑了很久是否需要实现持续部署的能力。对于传统的行业来说，无论业务需求或者文化传统或者管理要求等，很难直接能持续部署。业务需要考虑至少“相对稳定”，版本更新也不是随意就打包部署，因此持续部署的场景需求并不迫切。

（二） 灰度更新

灰度在一些场景中还是需要的。为了和流控等机制配置，我们把同一服务的不同版本作为不同的服务来看待，在API网关层实现流量分流，分别引部分流量到不同的版本来实现生产验证。而在容器云平台则实现单一版本的自动的负载均衡和弹性伸缩能力。

（三） API接口

使用API网关我们把微服务接口映射为标准API，为业务应用提供了一个稳定的可重用接口，而映射的源微服务接口和版本可以改变，只要API不变，使用API的业务应用或业务服务就不会受到影响。

（四） 微服务发布

部署并经验证过的微服务可以发布新的API，或者替换已存在的API源服务实现（API路由地址配置更改）。发布的API可以在API门户中列示，用户可以查看或者测试API接口，申请API访问权限然后使用API接口实现自己的业务应用。

（五） 微服务部署发布流程

基于我们的思路，我们把部署发布过程定义为以下步骤：租户登录，进入应用管理中心启动应用发布流程；创建应用，从镜像仓库选择镜像，应用由服务编排而成，一个应用可能包含一到多个业务服务；从镜像仓库拉取镜像，服务的配置文件可能存在配置中心，根据系统设置从配置中心或镜像中获取服务配置参数列表；配置应用级、服务级和实例级运行参数；分配应用和服务运行所需资源和调度规则；确定部署并生成服务实例；每个服务有一个服务名（容器服务ServiceName）；多实例服务在容器平台内部自动实现负载均衡和弹性伸缩能力，对外有唯一的ServiceName映射为路由DNS地址；这个容器外可访问DNS地址注册到注册中心；在API管理端可以配置标准API及相应的访问控制、安全、流量控制、认证授权、熔断、路由等策略；然后发布到API网关；标准API自动发布到API portal供其他团队或合作伙伴业务应用开发人员使用；然后就是持续日常的监控、统计、日志管理等运营工作直至下线。部署发布过程有几个点可能需要注意：

图2 部署发布过程

1． 应用和服务创建。服务编排为应用有多种方式，需要根据平台的能力选择服务编排方式。一个服务可能是一个应用，也可能多个服务组成一个应用。目前我们简单把一组相关服务部署为一个应用来看待。
2． 服务配置。服务运行时一些参数可能会调整，我们在设置之初就考虑支持服务运行时参数更改需求。配置参数分为3层：应用层、服务层和实例层。如果实例层参数需要分别配置，其弹性伸缩能力可能受限。比如数据分库/表，不同实例访问不同的库/表。不同的场景可以选择合适的部署方式。
3． 资源调度配置。基础设施资源调度也需要考虑业务应用场景，比如亲和性调度、非亲和性调度等。通常基于标签来实现。
4． 容器内路由和负载均衡。我们考虑负载均衡和弹性都在容器平台实现，对外提供唯一的访问地址。再以DNS转换，提供给外部一个带域名的访问地址。上图2中的虚框部分是可以实现自动化，不需要手工配置操作。
5． 注册。注册中心位于容器平台外。对外的可访问地址注册到注册中心。
6． API管理。注册中心中的地址映射到API网关，提供标准API。配置相应的访问策略。
7． 灰度发布/灰度更新/版本管理。在多版本情况下可能需要灰度机制。

四、 微服务/业务应用运营运维

微服务是从技术角度来说的，而最终用户关注的是业务、业务应用。微服务运营也就是业务应用的运营。我们在设计容器云平台时强调业务应用的管理能力，因为平台是业务应用运营的支撑工具，提供应用注册、配置、日志、监控、告警、统计分析、弹性伸缩、负载均衡、API管理、中间件服务等能力。
开源Kubernetes很多操作是从命令行来执行的，容器的执行需要root权限，这很容易出现意外。“无论对一个软件系统运行原理掌握的多么彻底，也不能阻止人犯意外错误”。因此我们在提供平台服务时，禁用容器终端命令行操作，所有的容器操作都在管理界面来实现。容器是弱安全的，特别在生产环境，安全是重中之重，因此我们需要隔离容器平台潜在的一些安全问题，首先要实现应用管理运营层面的操作安全。其次屏蔽命令行操作，也免去了运维人员的学习成本，能更快的使用平台工具运维业务应用。
业务应用运维运营人员还要考虑可用性改进、延迟优化、性能优化、效率优化、变更管理、监控、紧急事务处理及容量规划与管理等职责，更好的保障业务应用的运行。这可能是在DevOps流程中需要考虑的一些规范和准则，在私有云环境有时候可能还需要跟平台和资源运维人员一起来调整改进性能和效率。

参考文献
Besty Beyer Chris Jones Jennifer Petoff Niall Richard Murphy著 孙宇聪译 SRE Google运维解密 电子工业出版社