基于云架构的业务稳定性建设思路

作者：方沛

      在当下云化和云原生的浪潮催化下，越来越多的传统企业也开始进行着系统架构升级，传统架构正在不断的被云化架构所替代。云从最早的虚拟机资源厂商，逐渐演变成了具备上百个云服务，海量计算资源和计算类型，支持跨越金融、电信、游戏、视频、医疗、教育等社会各行各业发展的商业智能引擎。那么，如何保障云上服务的稳定运行也就变成了所有上云客户关注的问题。

      云上服务与传统软件差异

      很多文章都曾分析过云上软件与传统软件在研发和运维上的差别，在分析之前，我们首先要理解云上的租户和应用的概念。租户是指使用云资源的用户，可以是个人，可以是企业或任何团体组织。个人和企业都以租户的身份在云上使用云资源和服务来研发应对自己业务场景的软件，我们把这些软件都叫做应用。

      首先，云是“器”。工欲善其事，必先利其器。而传统软件多数都是为特定业务场景服务的，大部分都直接有业务属性，例如教育、电商、股票、游戏等软件或网站，一般不能通用于多行业。而云并不直接解决特定业务场景问题，却可以赋能租户快速解决这些特定业务场景的问题，例如你可以随时使用华为云直播服务快速的构建媲美大型互联网公司构建的视频直播应用。从这个角度讲，云就是一个包容软件世界基础能力的大型中间件服务，更好更丰富的“器”加速着各行各业的快速发展。

      其次，研发责任主体不同。传统软件由软件厂商独立研发完成，研发责任方由企业自己负责。在云上则完全不同，应用的研发深度依赖云基础设施和云服务，利用云原生能力加速研发与迭代以更快应对市场变化，这些都是云带来的生产力。在这种情况下，应用的研发责任主体已经变成了租户+云提供商，例如云提供商对其提供的基础设施和服务接口的安全，成本，容灾，并发性能，时延和向前兼容等能力的承诺是企业在其上构建应用的关键假设。云上的应用需要权衡以上多个能力纬度（主要是成本与其他纬度的权衡）以达成预期目标。

      再次，维护责任主体不同。由于研发责任主体的不同，自然会想到在维护责任主体上的差异。在传统软件上主要由厂商或其他特定外包团队承担针对性的运维维护责任，这种模型下软件维护成本非常高。而上云后，关键高可靠，高难度的IT能力已经被云服务解决，虽然仍有自研的部分应用需要维护，但云的成本低廉，且无需维护已经让上云的运维成本优势明显。因为标准化的云服务，海量的规模，海量的用户，让云有了实现海量低成本运营的前提。所以既然上云，更多的依赖云自身能力，是逐步降低租户运营运维成本的关键思路。

      最后，但也是对用户最关键的改变，即得益于云提供了底层通用的技术能力，企业将更加聚焦商业成功的实现。服务器，网络设备硬件/机房等非软件问题上，云上具有绝对的优势，不仅不需要运维，也不需要考虑损坏，更换，扩容，固件升级等问题，总体来看不仅便宜还简单易用。从租户的视角，上云与传统软件研发对于需要提供给最终用户的服务并没有发生改变，但是上云能让研发团队更聚焦于应用业务的目标实现，而将与业务无关的稳定性部分交给云来解决。通过这种组合可以让不同领域，不同规模的企业快速突破关键IT能力瓶颈，为其用户提供更稳定可靠的应用服务，且快速迭代。在经济学十大原理中，贸易能使每个人情况变得更好，而其根因也是因为贸易让每个国家，每个企业，每个人做自己擅长的东西，优化配置，实现整体收益最大化。

      云自身稳定性也面临挑战

      稳定性对于所有云上租户来说是重要的，对于云服务来说更是关键生命线。在云服务的软件设计和研发过程中，满足功能性需求是设计需要考虑的主要目标，同时还必须衡量到底哪些可靠性能力在这个过程中需要得到同样的关注和完善。这里以简单性，韧性，线性扩展，弱依赖以及可度量五个纬度来举例说明：

      Simple: 在软件架构设计中，最顶级的设计原则莫过于简单，尤其是复杂系统的逻辑简单化是需要精心设计的，简单架构相当于能用几句话描述一个复杂云系统的设计，而这几句话可能就是这个云系统世界里不变的真理。例如分层架构和领域建模就在努力让软件逻辑变得清晰简单；Actor模型的简单架构约束让简单就像积木一样拥有无尽可能。简单最大的价值是让人容易理解，人能够理解的东西其实都是简单的（在有限维内逻辑清晰的事物），没有人能像计算机一样无限维递归迭代，并行处理。因此，让架构持续简单是软件可靠性，更是可维护性的关键目标。

      Simple维度中的例子：

      Actor设计模式：所有的系统中业务流程都通过一个个Actor实现，Actor可以处理输入，给出输出，创建新的Actor。该架构下系统将天然具备大规模，易负载均衡，高并发，爆炸半径可控，无全局状态易迁移等特征。如下是一个下单业务的例子，其中涉及到了订单管理，库存和费用结算三个Actor，每一个Actor都有明确的输入输出定义，可以注意到在该架构下消息流是单向的，同时相同的消息类型可以由多个Actor实例处理。

      Resilience: 韧性是系统架构设计中的关键考量，因为云服务所要面对的外部环境和业务场景都不可预期，风险随时都会来。也许下一秒的请求数瞬间增长了几倍，也许网络的抖动导致实际获得服务的客户体验大幅下降，也许当前的一个依赖服务出现了不可用状态导致本服务不可用，这些都需要我们精细化考量的。我们需要通过类似限流，负载调度，队列控制，缓存，有回退避让机制的重试等方案优化系统韧性能力，但是你会发现韧性设计往往很难简单，所以一般我们还需要度量韧性设计成本与收益并控制韧性设计带来的复杂度来评估合理的韧性架构设计。

      Linear Scalable：可线性容量扩展是云服务的典型特征，可以保障云服务应对海量波动业务流量下持续稳定。我们在传统软件，开源社区等场景下能明显的感知到软件支撑的业务规模上限。但在云服务场景则需要线性可扩展无上限限制，让服务可以运行在海量物理机之上。在如此大规模场景下确保其稳定性也变得更加挑战。这需要如高可用网络与负载均衡，去中心化设计，爆炸半径设计等来支持服务的线性扩展能力，同时对应的集成测试，仿真验证技术都需要增加对规模化场景的支持能力。

      Low Dependence：减少依赖或弱依赖，尤其对任意硬件设施的依赖都应该明确假设硬件存在故障风险。一旦存在具体的实体硬件依赖，那么出问题就成了必然事件。对建立在大规模硬件基础上形成的逻辑硬件，即抽象资源的依赖是提升依赖可靠性的关键方法之一，如OBS的对象存储就是典型的逻辑资源。最高可靠性级别的依赖管理是标准依赖，而不是具体服务依赖。

      Measure & Inspect：在现网中不管是什么原因导致的不可靠，都需要能够发现根因问题以改进，这需要有精心设计过的指标和日志来支撑的。持续的度量和分析是我们将系统的简单性，韧性，线性扩展等等上面提到的能力持续构建和优化的前提。

      除了举例的设计和度量相关的纬度外，云厂商还需要在设计，研发，发布变更和运行维护等多个阶段中深入思考云服务自身稳定性能力建设，尤其是面对多租户，多地域与多场景化诉求，这需要非常专业且深入的规划和设计才能逐步建立和完善。

     持续设计迭代

      对设计的宏观思考是思路，而持续实践迭代就是我们保障架构持续稳定可靠的有效方法，因为没有一个好的设计是想出来的。在16年的一次公开tech talk中，Linus直言直到现在linux也没能达到他在1990年开始构想的一样。是不是那个时候21岁还在赫尔辛基上大学的Linus已经能够凭空猜想出完善操作系统雏形了？其实Linus从11岁开始已经从事编程，以此为乐，并创作了非常多的个人软件项目，这个Linux的项目只是其中一个模仿MINIX(类UNIX)的兴趣项目。良好的设计是需要持续的设计实践来让我们理解设计的未来，就好像过去的尝试都是在脑海中训练设计模型，而在脑中的模式足够多了后，优秀的设计就成了必然。

      当然，也没有一个好的设计只是靠实践的，这并不是要与上一个观点唱反调。实践告诉我们，需求往往不能引导软件设计优化，反而让软件持续迭代堆砌功能特性，越来越难于维护，设计越来越混乱和臃肿。让业务目标与技术目标的协同一致总是困难的，我们需要时常回望项目之初制定的愿景和目标，记得当时做的架构设计是为了特定业务目标服务的，业务目标在持续迭代中发生了变化，我们也要持续思考如何伴随的从全局视角更新架构设计。

      例如以下几个问题可能在开始设计时就要分析清楚：

      ·顶层架构该如何抽象和分层？

      ·这个业务流程到底应该在微服务内直接闭环还是应该将其中的一部分逻辑放入另一个做类似业务处理的微服务中？

      ·在哪些组件或微服务间放缓存和消息队列，是否会贡献没必要的消息处理延时？

      ·到底这两个服务或组件之间通信采用拉取模式还是推送模式？

      ·这个前端获取的JSON数据中包含多个业务模块的数据，是应该前端调用多个接口还是应该后端有一个数据聚合接口来降低前端请求数和复杂度？

      这些问题不仅在不同的服务中会不同，就算在相同的服务中不同的阶段，答案也会不同。相比于相信自己直觉的认知，持续总结经验教训并思考做出架构选择的影响因素（最好这些因素又是直接能够从业务目标推导出来），会让架构设计和优化改进更可控和高效。当然，还有一些通用的设计思维在云领域也达成了共识，应该在架构应用时考虑到，比如：

      ·自动从故障中恢复：通过监控业务的关键绩效指标 (KPI)，可以在指标超过阈值时触发自动化功能。这些 KPI 应该是对业务价值的一种关键度量指标，如客户购买，流量，在线人数等。在超越阈值后自动发送故障通知并通过监控和日志跟踪故障，以逐步建立自动恢复流程。在实践自动化故障恢复的能力后，才能够思考在故障发生前的故障预测和故障修复的可行方案。

      ·测试恢复过程：在本地环境中，经常会通过测试来证明工作负载能够在特定场景中正常运作，不会利用测试来验证恢复策略。在云中，可以测试工作负载的故障情况，并验证恢复程序。可以采用自动化方式来模拟不同的故障，也可以重现之前导致故障的场景。此方式可以测试故障恢复方案，从而降低临场风险。

      ·利用云的自动扩容能力：传统软件系统出现故障的常见原因之一是过载，过载可能因为业务洪峰，也可能是DDOS攻击。在云中，可以监控工作负载与KPI的变化，自动化管理资源变更，以保持满足需求的最佳水位，不出现超额预置或预估不足的情况。

      ·管理自动化变更：应利用自动化功能（尤其是云原生变更自动化）对基础设施进行更改。需要管理的变更包括对自动化本身的变更，以便对其进行跟踪与审查。

持续设计迭代看起来是一件费时费力且痛苦的事情，但持续几个周期的全局思考和迭代后，会有惯性让软件系统的设计迭代越来越来容易，而且能让在设计之初考虑的复杂架构随着业务的发展反而越来越简单，因为在这个过程中架构师逐步思考清楚了上面提到的那些在第一次设计时没考虑清楚的问题。

      持续发布

      持续发布（continuous delivery）能有效的降低业务变更风险，保障系统稳定性。通过管理工具和持续发布在一起协同，建立业务研发体系内的快速业务反馈闭环，促使业务及时自适应调整以加速业务发展。持续发布能够保障业务稳定性的最主要原因是每一次的变更影响都是可控可度量的，所以伴随着持续发布的是持续的跟踪度量变更为服务带来的影响。软件是无法割裂的看各个功能特性的，今天变更的一个次要feature很有可能就导致了主要特性的不可用。所以在持续发布中，不仅需要关注新feature的状态度量，同时要持续关注已有主干feature的新不稳定因素。无法持续度量，就无法做到低风险持续发布。

      大家都了解被广泛认知的DevOps的大流程，并参考着进行敏捷迭代发布。但我们也要深入思考为何需要敏捷迭代，这个问题对研发活动组织有深远的影响。在实际的研发活动中，开发团队设计架构并实现，同时与Ops团队一起制定为监视上线后稳定性的监控，日志等标准能力，但这必须在研发周期的中后期才能开始生产Ops阶段工作，且大部分运维能力建设需要等待实际现网反馈。在这样一个Dev+Ops的软件生命周期内，让Dev与Ops工作的实施阶段越接近，互相反馈越及时，越能够让大家都保持对现网的一致理解，也越容易保障面向客户的稳定性承诺结果（SLA = Service Level Agreement）。

      例如在图示中，通过架构能力保障现网事件的快速恢复（如面向故障快速恢复的容灾架构设计），通过监控指标和trace等数据持续支持运维工作流伴随服务升级而迭代，持续的保持这个循环的快速闭环能够有效的持续维护现网稳定性。要注意，持续设计迭代是持续发布的前置动作，否则很难形成真正的DevOps衔接循环，流于形式。

      建设可度量业务稳定性的监控体系

      我们常用可用性（Availability）描述来衡量服务是否可提供服务，可用性计算方法按照不可用时间来计算：

      而用可靠性（Reliability）描述用于衡量服务是否会频繁发生故障(Mean Time Before Failure)以及故障恢复时长(Mean Time To Repair)度量：

      从以上的定义看，明确度量稳定性需要明确度量不可用时间和定义故障事件。而度量不可用时间需要我们清晰的定义怎样的情况发生就是不可用，例如如下描述：

      5min内的API响应正常业务结果的占比 > 99%

      这就是一个对系统的可用定义。但是如果平台可用，用户感知的不可用是因为客户侧异常连接、异常请求或DDos攻击（这里的假设场景是能够正常响应业务流量同时对DDos流量异常返回或限流）等外部因素导致计算结果是不可用的，其实也不合理。这时候需要标准化接口响应，明确哪些出错是服务侧异常导致的故障：

5min内的非 502, 500 http code的API响应占比 > 99%

这样的定义能够更清晰化的代表服务自身可用性状态。而这样的定义又如何落实到实践中？一方面，要标准化系统接口，数据处理和数据结构的设计；另一方面，要迭代建立关键设计逻辑的指标体系。需要建立指标体系而不仅是针对可用性目标搞定一两个监控，是因为：

      ·可用性度量不仅为了了解可用性风险，更为了解可用性风险背后存在的设计缺陷。

      ·参照设计演进的监控体系化指标不仅为了可用性度量，同时可以为容量规划，APM, 运营，安全等领域提供从设计上考量的指标能力支撑。

      ·明确清晰的监控指标体系将能够让服务在错综复杂的调用逻辑中清晰化表达系统边界状态，进而明确问题边界定位，自证清白。

      ·提供持续发布的变更影响度量能力。

      充分利用云服务能力提升业务稳定性

      有状态类数据的管理（缓存，长连接等），传输（消息队列，发布订阅等）、存储（数据库，文件系统等）和高可用能力等往往都是一些业务应用的关键难题。相比于在云上自己搭建相关的缓存、流计算、数据库等开源软件等，利用云上提供的服务化能力来管理这些状态数据会更加稳定可靠，省时省力的帮助业务提升稳定性。

      充分利用云服务能力也并不意味着完全没有边界的集成，我们需要将对云服务的交互部分集中在部分逻辑层内，让上层业务架构中尽量少感知底层的能力实现细节。在这样的架构下，不管是从传统机房迁移到云上，还是从一朵云换到另一朵云，都不会影响业务自身的可持续发展，同时在发生故障时也容易通过监控发现故障边界，加速恢复和分析定位。

      而对于特定复杂业务场景上云，云上也存在很多已经被验证过的依靠云上能力建立的场景化服务能力。这不是简单的将基础云服务进行拼凑，而是由有行业背景的专家注入行业经验，分析行业对IT系统，运算，可靠性，数据安全等关键特性要求而设计的，同时也优化了针对这个场景的后台基础设施全链路保障，如下面的华为云针对生物医药中基因测序场景的解决方案，多服务协同的业务场景解决方案其实就是在这个行业或场景已经得到验证的信息化、智能化变革的最佳实践。

      合理的组合创新将让我们的应用不仅能获得更高的稳定性提升，在深度整合和梳理自身业务后，可以进一步对流程和成本进行优化，让企业运作更加稳定可靠。例如传统企业生产流水线场景，需要测试、质检和生产统计等过程来保障产品质量，保障生产和供应周转效率。下图是一个选择工厂生产质量保障相关的部分流程：

      在以上流程中，越是大规模生产，这里的节点流程的人员和数据汇聚管理的复杂度越高，标准也会参差不齐，进而导致不同的人员手工或Excel化采集汇总后的信息的质量，标准和最终反馈回生产中的价值无法保障。在上云过程中，我们可以先确保生产数据报的上来，这需要引入IOT和数据流处理服务能力；如果希望收集的数据能够输入到多个企业生产管理平台并完成相应平台的业务属性价值，则需要引入数据湖探索DLI和ModelArts等数据存储和智能业务模型化分析平台；如果希望这些指标数据与自身已有的业务系统能够联动管理，自动化改进，则需要引入实时流数据分发DIS，数据可视化DLV以及应用集成服务（ROMAConnect），如下图所示。

      以上都为场景假设和云商应对方案的举例，实际场景需要灵活采取应对措施，尽量让流程尽可能标准化，高效运行，让自运维IT服务的复杂度低，无状态且业务强相关等都是云上业务流程质量优化的关键目标。

      如何利用好华为云服务架构师们对云自身的领域知识，结合业务场景，产出精准行业数字化解决方案来为任何行业内企业带来商业变现的支撑能力，也是华为云持续发展优化的关键驱动力。

      总结

      业务稳定性一直都是软件系统关注的核心问题之一，尤其在云上场景中，我们需要关注服务的持续迭代设计和持续发布，建立完善的监控体系，同时在研发过程中也要更多的利用云上资源服务特性进行架构和业务优化，将有助于快速实现业务结果，提升服务和业务的整体质量。