评估容器云平台生产就绪的八个标准

本文主要是介绍评估容器云平台生产就绪的八个标准，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

生产就绪包括软硬件就绪。本文定义了功能性、可用性、伸缩性、高性能、容错能力、灾备能力、日志监控告警能力、及文档可用性八个生产就绪标准来评估容器云平台生产就绪能力和水平，从而更好的指导容器云平台建设和支撑业务微服务应用架构和设计。

关键字：容器云、生产就绪、生产就绪标准、服务中台

一、 生产就绪

当前虽然不少企业采用了容器云平台，但真正上生产的不多，而把重要业务部署到容器云平台的更少。大家更多的还是处于PoC（Proof of Concept）概念验证测试阶段，对上生产缺乏必要的信心。对于我们证券企业来说，安全可靠等是我们不得不考虑的重点，因此我们尝试探讨容器云平台生产就绪标准及条件，来确保建设的容器云平台是生产就绪的，并尝试探讨和建议采用容器云平台后生产就绪参考指南。

（一） 生产就绪标准

我们在建设云计算平台的时候，更多关注的是功能的实现，很少从整体上去看是否满足生产就绪标准，很多同行也使用容器很长时间，容器数成千甚至上万，跑了不少业务，但在整个容器云平台建设，容器、资源调度管理和应用管理方面未能系统化，大家更关注的是容器技术而不是业务应用本身；另外容器的弱安全性也是一个潜在的问题。国内几大公有云厂商的连续重大事故也让我们开始关注容器云生产就绪能力，也让我们考虑要满足生产就绪的要求，需要具备哪些能力，满足什么条件，有什么标准可以量化评估等。依据我们过往的实践经验以及对容器技术、容器云平台等的理解来看，我们总结了以下八个方面标准：功能性、可用性、伸缩性、高性能、容错能力、灾备能力、日志监控告警能力、及文档可用性八个生产就绪标准，并尝试使其能够量化、可评估、可操作。量化、可操作的标准有助于我们理解容器云平台，提高容器云平台的可用性，所以我们尝试定义了每个标准的详细的检查列表。

1. 功能性

容器云平台生产就绪，首先要满足我们在《容器云平台设计》中提到的平台各项功能需求标准。功能就绪是最基本的要求，完成功能并不一定满足生产就绪标准，平台的架构、设计、实现、部署等都会影响到其整体能力以及后续扩展能力。

在我们调研交流的过程中，也发现了一些问题，比如每个厂商都声称支持多租户机制，但如果认真的深入了解其实现的多租户能力，可能完全不是那么回事。多租户跟多租户千差万别，大家没有一个标准或规范去遵守，完全是各想各的，各做各的。也因此我们整理发表《多租户权限中心设计》讨论多租户的问题。其实每个功能点都面临这同样的问题。功能的实现依赖于研发人员的技术修养和理解，对于大部分客户来说，对容器或容器云也是一知半解，无法提出合理可行的需求，所以也就依赖于厂商的引导，这也是容器云平台研发在当前面临的一个问题，厂商无法对你的业务场景有过深的理解，也就无法规划设计出符合预期的产品，也因此整个容器云市场虽然经过几年的发展，依然无法生产就绪。

功能的通用性和便利性对产品设计的基本要求，这要求产品经理有需求分析、整合、提炼、概括、方案设计、沟通、实现评估等能力和技巧。产品经理需要有较高的技术修养和工程组织能力，以及哲学认知，知道并理解用简单的方法去解决复杂的问题，具备剥茧抽丝、化繁为简的能力。功能的设计需要服务人们的日常操作习惯和认知。产品最终是给终端用户使用的，不是给研发人员自己使用的，因此要求可能是不一样的，不能让客户去遵守自己的习惯。

总的来说容器云平台功能就绪检查列表可以考虑以下几个方面：

1) 实现功能与需求匹配。

2) 功能设计符合人们的习惯和认知。

3) 功能操作便利。

4) 已知缺陷中不存在关键或重大缺陷（缺陷分：关键、重大、中度、轻微、改进五个级别），产品缺陷中大部分有明确可行的临时解决方案，不影响实际业务，我们可以认为是功能性生产就绪的。

5) 平台生态系统组件功能齐备。

2. 可用性

可用性是在要求的各项资源得到保证的前提下，产品在规定的条件下和规定的时刻或时间区间内处于可执行规定功能状态的能力。它是产品可靠性、可维护性和维修保障性的综合特性。衡量可用性通常只考虑三个指标：uptime（正常运行时间）和downtime（无法正常运行的时间），总运行时间（uptime + downtime）。可用性指标就是uptime除以总的运行时间（uptime + downtime）。

可用性一般通过“9”的个数来衡量，也就是系统或平台或服务可用时间的百分比。9的个数越多说明可用性越高。对于容器云平台，不同组件可用性要求可能是不一样的，因此在设计实现的时候需要考虑各组件的可用性及实现和部署方式。

整个平台的可用性是靠平台各个生态组件的可用性来保证的。不是每个组件都必须实现较高的可用性，这依赖于平台的架构设计和平台各组件之间的通信方式等。松耦合的设计会让组件之间相对独立，一个组件不可用并不会对其他组件造成致命影响。但核心的组件必须实现高可用，比如Master节点，ETCD。如果某个组件的缺失会导致整个平台或整个容器云生态系统陷入瘫痪，那就是关键组件，需要考虑高可用。

高可用

我们已经习惯于在交流过程中说“高可用”，但多高算是高可用？或者几个“9”的可用性是高可用？似乎也没有什么标准。基本上大家都只不过是通过冗余的集群部署来提高可用性。但是可用性往往是多方面因素影响的，所以可能需要从不同的角度考虑：

1) 资源高可用，说到底容器云平台提供的就是资源。但资源有很多种，我们先看基础设施资源，如果基础设施资源出现故障，需要保证业务应用不受影响。这个太关键了，所有组件和业务都依赖于基础设施资源。传统单体应用，如果磁盘损坏，那可能就导致关键数据丢失。在分布式系统中，通常要考虑冗余副本。如果整个节点故障，就需要考虑多实例不同节点上的部署以及迁移恢复机制。虚拟机能比物理机更快的恢复和就位，这也是容器云平台使用虚拟化的一个好处。

2) 集群主节点高可用以及ETCD高可用，这是资源调度层必须保证的能力。否则整个集群就可能瘫痪。

3) 业务服务高可用，这是从业务角度来说的，但平台需要提供支撑业务服务高可用的基础设施资源能力。

一个平台的高可用不是由某个组件来保证的，而是整个平台的高可用来保证的。就像木桶原理中木桶能盛水的量取决于最短的那块木板，因此要实现平台的高可用需要考虑平台中每个组件及组件依赖的高可用性。不过采用分布式松耦合的架构中，一些组件的由于运维等因素短时间的中断是可以忍受的，比如日志中心组件，只要日志数据被发送到消息队列，消息队列可以暂存日志，所以日志中心可以忍受中断，但需要根据日志的级别来考虑是否需要日志的持久化及队列的高可用配置等。

总的来说可用性可从平台的四层架构来检查，评估组件之间的依赖性、依赖程度，找出关键组件，实现高可用，其他组件则按需配置，辅以日志监控告警，确保整体可用性。

3. 伸缩性或弹性

采用分布式架构的系统，弹性是其价值所在。采用容器云，很重要的一点就是其弹性伸缩的特性，以支持并发流量的突然爆发，以及充分利用资源。比如经常需要推出的促销、秒杀等业务活动，在某一时点并发流量可能会突然爆发，需要基础设施平台支持业务的快速扩展。弹性或伸缩性不只是提供可扩缩的资源，也包括业务应用的可伸缩性，如果业务应用不支持弹性伸缩，即便部署到容器云平台，也无法实现弹性的伸缩，因此，我们需要从不同的层次来考虑支持弹性。

资源弹性需求是基础的需求，包括基础设施资源和容器资源。基础设施资源中虚拟机比物理机能更快的部署和就位，在满足业务应用资源弹性需求方面更便捷，虽然有性能方面的部分损失，但也能满足大部分业务的性能需求。云计算平台的目的是实现基础设施资源的有效利用，但在云计算平台资源量小的情况下可能无法达成目的，甚至更浪费资源，因为没有充足的资源类型可以调度，也很难实现资源在租户之间的错峰共享。因此在私有化容器云平台建设初期，可能是会付出更高的资源成本，也比较难实现资源的弹性。在达到一定的业务规模，具备一定的节点数量（具体的量比较难评估，不同业务需求会有差异）后，有了足够多的资源类型和资源量可供调度，实现资源弹性就相对容易。

除了资源弹性，业务弹性应该是更重要的方面。目前很多人关注的是业务迁云，很多人都问什么业务适合迁云？我们觉得具备弹性且需要弹性的业务最需要迁云。如果不具备弹性，最好做业务应用改造，采用微服务架构，分拆为微服务。业务应用的弹性还取决于其依赖的服务或应用的弹性。比如某业务依赖的数据库无法支撑扩展，即便利用容器云平台扩展业务应用，也无法实现弹性伸展。

伸缩性或弹性生产就绪标准可考虑以下几个方面：

1) 基础设施平台支持弹性伸缩

2) 业务应用具备弹性

3) 业务应用依赖的服务或应用具备弹性

4) 资源和业务应用的弹性能力满足业务弹性的增长需求

5) 没有伸缩瓶颈，整个链路是可伸缩的。

4. 高性能

伸缩性指的是对并发请求量的扩展处理能力的方面，高性能则是指对请求的处理时间低延迟要求。性能指标是评判一个系统处理能力的关键指标。很多时候不是功能不行，而是性能达不到要求，不得不忍痛放弃，寻找其他解决方案。比如ESB集成，往往由于中间集成的层次过多，整体响应时间过长，性能看起来就差，所以大多数只能解决管理类系统集成，无法实现交易系统的集成。这也是ESB实施被诟病的原因之一。所以要满足高性能，需要尽可能降低链路长度，减少处理时间，提升响应速度。
性能指标通常用延迟、响应时间、吞吐量、并发用户数、资源利用率等来描述。延迟越小、响应时间越快，吞吐量越大，性能就越高。所支持的并发用户数和业务服务的线程数及资源配置有关，不同业务应用所需资源会有差异，比如有做大量运算的，有大量数据加载内存的，有频繁IO读写的等等，这就是我们关注资源种类和资源调度能力的一个原因。在高并发的情况下，资源利用率通常要合理，否则的话可能需要调整资源配置。

请求的处理时间包括执行时间和等待时间，等待时间越长，说明任务在线程之间处理的切换过于频繁，会导致性能下降。

另外，每个系统都有其最大容量，在业务应用部署时可能需要考虑其流量增长趋势，以及每个业务服务的最佳资源配置。在容器平台，不合理的资源配置可能会导致严重的问题，比如导致容器数量无限的扩展，如果放任最终可能会导致资源耗尽而崩溃。因为没有满足容器的资源需求，它会一直的扩展。

高性能指标生产就绪标准可考虑以下几个方面：

1) 服务调用链路长度尽可能的短

2) 服务依赖的高性能，没有瓶颈点

3) 延迟和响应时间短

4) 吞吐量大

5) 并发用户数和资源利用率合理

6) 执行时间和等待执行的时间短

7) 流量增长趋势及平台容量合理

5. 容错性

容错也就是Fault Tolerance，是在系统发生软硬件故障时恢复或者故障转移的能力，其是保证系统可靠性、可用性的一项重要措施。计算机系统在运行过程中总会出现这样那样的故障，比如磁盘损坏、网络中断、软件缺陷等，会导致系统运行异常。在关键的业务系统中我们需要考虑容错性，提高其可用性、可靠性。

容器云平台是一个生态系统，拥有众多的服务组件，在容器云平台的四个层次中每个组件每个点都可能出现异常，这就需要考虑容错配置。容错配置不是越多越好，越复杂的系统出错的机会越多，运维就越困难，因此我们通常只考虑关键节点的容错性。比如消息中间件采用FT模式，共享同一磁盘数据（同时做好数据的自动化灾备工作），在一个节点出现异常的情况下，另一节点可以快速恢复并接管请求流量，并恢复正在处理的请求。在基础设施资源层采用虚拟化也是为了更快更方便的调度资源，在容器云节点资源不足时快速的分配扩展节点资源。

容错性在容器云平台是为业务应用提供可靠的基础设施平台。同时支持业务应用在容器云平台的容错，以提高业务应用的可用性。我们建议缩短业务应用链路长度不但是为了性能，也是为了减少故障点。通常可以通过测试评估等识别出潜在的故障点，关键节点避免单点故障。在有异常的情况下可以通过测试评估快速定位故障，解决故障。

容错生产就绪标准可考虑以下方面：

1) 已排除已知故障

2) 识别出潜在故障并有解决方案

3) 没有单点故障场景，关键组件实现了容错配置

4) 提供了对业务应用的容错支持机制

6. 灾备能力

云端风景很美，但也高处不胜寒，如果没有完备的灾难备份和恢复机制，一旦有什么意外，就可能损失惨重。传统数据中心建设通常采用两地三中心，云计算可能也需要考虑这种实现方式。但对于初始的容器云平台，在量的规模尚未上去之前，可能无法实现多数据中心的建设，那就需要考虑其他方式尽可能保证数据的安全。比如基于资源的标签来实现容器部署的亲和性和反亲和性策略资源调度。另外组件的松耦合和高可用部署以及容错机制等也是数据安全的一种实现方式。

灾备另外需要考虑的是快速恢复机制，比如在出现意外故障时，能够迅速的切换恢复。容器云平台有蓝绿部署方式，也可以作为一种灾备模式。如果业务应用程序由于缺陷引起异常，首先应考虑回退到稳定版本，而不是热修复补丁。这样不但更快，也避免了缺乏充分测试可能引入新的缺陷的可能性。

灾备生产就绪标准可考虑：

1) 平台不同层次、不同组件的灾难备份机制

2) 灾备快速恢复机制

7. 日志、监控和告警能力

日志、监控的重要性不言而喻，没有日志和监控能力，就如同两眼一摸黑，无法知晓业务应用的运行状况。日志是对业务逻辑执行顺序的跟踪，监控是对业务应用运行状态和趋势的追踪，告警则如同有了千里眼顺风耳，可以快速的了解和追踪重点事件。

日志通常需要实现TrackingID全链路跟踪能力，ParentLogID确定调用次序，Timestamp确定调用时间（在分布式系统中无法通过Timestamp来确定调用次序，各个节点时间会有差别，只在同一节点有效）。

日志记录通常是监控的源数据之一，另外容器云平台自身的健康检查数据是监控的重点来源，还有其他用于监控而采集的数据。监控通常要实现一个Dashboard，来展示平台及业务应用当前的运行状况，资源使用等。这个Dashboard所展示的内容是相互关联的、容易理解的、有明晰的层次关系。

通过设置监控项的阀值来定义告警规则。告警通常可以分为若干级别，比如提示、警告、严重警告等级别。在定义告警阀值时确定告警范围，以确保告警是有效的，避免无效的告警淹没有用的告警，无法实现告警目的。要实现有效告警，需要为每个度量指标设置一个合理的阀值和告警线，但这个阀值的选择有时可能比较困难，需要根据实际情况及时调整，比如CPU利用率。80%？90%？100%？ 还是150%？ 200%？这可能需要根据实际的资源配置等来确定。

另外告警频度也是一个需要考虑的问题，有时一个告警可能无法确定就是有问题了，比如定时任务在某一时刻发布了几十万甚至上百万的记录到Queue或Topic上，从而触发告警，但这个告警是可接受的，如果持续的告警显示Pending的消息数据持续增加，那意味着Consumers可能有问题了，需要介入处理了。

日志、监控和告警生产就绪标准可以考虑以下方面：

1) 日志、监控、告警基础设施组件已分离并具备能力

2) 业务应用只需要按照接口定义使用日志采集接口

3) 日志格式等标准化、监控、告警标准化已生产就绪

4) 监控Dashboard监控内容合理有效

5) 告警多渠道支持，比如邮件、短信、微信等

8. 文档可用性

虽然我们一再诟病别人的文档写的很烂或没有文档，但技术人员的通病似乎都是不在意文档，具有良好的文档且为人所理解，是生产就绪很重要的一个方面。虽然DevOps提倡开发运维一体化，但也无法保证我们开发的服务一直由我们自己运维。因此拥有详尽的文档定期更新，将有助于DevOps的实现。文档可以从不同视角，不同层面画出架构图，包括逻辑架构、组件架构、部署架构等，然后对每个部分进行细致的描述。

文档可以有正式文档和非正式文档，正式文档按照文档规范去书写，非正式的主意、想法、随笔、感想等都可以记录作为文档的一部分，以协助理解正式的文档。或者从非正式的文档总结输出为正式文档。需要说明的是，代码里面的注释不是文档，写文档可能挺枯燥的，或者无法有效表达自己的想法。所以写文档并不受欢迎。可以把文档作为服务输出的一部分，在提服务代码的时候一起提交。

1) 良好的文档且为人所理解

2) 详尽的文档且定期更新，可能但并不限于详尽的需求分析、设计、架构、实现、使用开发指南或手册、运维手册等。

3) 作为服务的一部分一起提交

生产就绪标准之间是相关关联，相辅相成的。每个标准都不是彼此独立的，就像缩短调用链路是为了高性能的同时也减少了故障点；日志监控为平台及时获取其他方面的能力状况提供了支持；弹性扩展的同时也提高了容错性，实现了某种形式的灾备；文档是理解并运用好这些能力的帮手，等等。总的目的是为了整个平台的可用性及其支撑业务应用的可用性。

（二） 生产就绪准备

标准只是理论上的参考，真正部署业务应用到生产，还是有很多工作需要去做去准备，需要持续不断的改进优化。例如说容器云平台组件部署，可能不同的环境是不一样的。可以选择容器化部署，简单快捷；也可能选择非容器化部署，更稳定可靠，运维更简化。这些都不是某个就绪标准所能覆盖的，更多的是基于实际场景和具体实践来确定的。生产准备就绪才能真正的支撑业务应用的研发、部署和运营。

二、 支持业务应用研发部署

在实现容器云平台的生产就绪之后，才真正可以部署实际的业务应用到容器云平台。这样业务应用的运行才是可控的，比如我们非常关注的弹性伸缩能力，伸展相对容器，扩资源扩容器扩实例就行了；但在收缩的时候就需要考虑相应的收缩策略，否则可能被回收的容器还在处理业务请求，强制收回可能导致数据丢失，数据不一致等问题，特别涉及资金、钱的问题，多给人算10万八万人家可能不在乎，如果少给人家算10块八块，那人家就可能会不同意、不厌其烦的来投诉、要解释。所以平台就绪就是这些支撑能力的就绪，就可以支持业务应用的运营。

目前我们的客户中心、服务中心业务应用系统已经部署运行于容器云平台，容器云平台提供基础设施资源和平台基础组件的支持能力，业务应用研发人员可以专注于业务应用的研发，从而提升研发速度，加快研发进度。客户中心、服务中心应用目前已部署了20余个业务微服务，业务应用采用微服务架构。微服务架构一定程度上是为了解决伸缩性问题、运行效率问题和开发效率问题。微服务在实现弹性、高性能、容错、可用性等方面具备先天的优势。其轻量、自治的特性非常适合容器云平台上的部署和运行。微服务通常用于重构业务应用或新建业务应用，可以横向和纵向两个维度伸缩，由于其专注于某一方面的功能，开发速度也会大幅提升。微服务架构的挑战在于实现服务的标准化，标准化接口、标准化通信、标准化数据等等，接口的标准化等可以方便使用新技术替代旧技术。

微服务的基本原理是让一个小型应用专注地做好一件事情。微服务架构的目标是创建一组具备自治能力和自包含能力的独立应用，他们各自负责提供某一方面的功能。所有的微服务共同组成容器云平台生态系统，包括容器云平台的公共微服务组件，比如日志、监控、注册发现、网关、负载均衡等。整个容器云平台生态系统来支撑业务应用的研发、部署、运营和持续改进。

三、 远景目标——建设企业服务中台

容器云作为基础设施平台，用来承载企业业务应用，如果仅仅停留在业务应用迁云，依然无法解决众多单体应用面临的问题，依然无法有效的整理企业数据、应用、业务等资源，微服务架构提供给我们了一个更好的选项：业务应用重构。与其修修补补艰难爬行，不过换个思路，重构业务应用服务。重构并不意味着全部推倒重来，而是有计划有步骤有选择性的构建微服务组件服务，在某个单体应用的功能被微服务组件全部实现之后，可以替换掉此单体应用，也就是说这个单体应用被重构了，随着微服务组件的增加，越来越多的单体应用会完成重构，被替换掉，公用、可共享的微服务组件逐步增加和完善，共同构成企业服务中台系统。

图 1 服务中台架构

服务中台的建设是个长期过程，需要持续的构建、不断的改进。不过贵在坚持，坚持就能有所收获。

这篇关于评估容器云平台生产就绪的八个标准的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！