应用丨研究报告
导语：
*本报告为艾瑞咨询和神州云科、通明湖云和信创研究院、通明智云联合发布。
在数字化时代的今天，应用可持续性不仅在一般商业领域与经济效益直接相关，而且在公共服务领域关系国计民生。然而，在用户数量、网络流量不断增加，应用复杂程度不断增加，IT 软硬件技术快速更新迭代的整体背景下，应用可持续性的落地面临系列挑战。对此，本报告提出应用可持续性架构，对该架构的设计思想、特征以及验证指标体系进行了详细说明。
本报告内容着眼于应用可持续性架构，分为五个章节：第一章节阐释了应用可持续性的概念、发展背景以及在商业与公共服务领域的价值；第二章节对应用可持续性落地过程中面临的敏捷、信创和疫情等挑战进行了说明；第三章节描述了以抽象与分层、不同层解耦、同层节点冗余、替换、水平扩展与异构、中间层和核心节点的稳定性保障以及持久化存储且共享为要点的应用可持续性架构设计思想，并描述了跨域协同与平滑迁移、多协议支持、与现代高可用架构无缝对接、可观测性和分析、负载可编排、主动韧性、开放与集成等应用可持续性架构的特征；第四章节从性能测试、基础功能测试、超高可用架构场景测试和管理功能测试等维度详细说明了应用可持续性架构的验证指标体系；第五章节则对未来应用可持续性的发展方向进行了展望。
应用可持续性概述
应用可持续是指企业利用IT资源，保障应用稳定运行，可持续地满足客户的需求与期望。应用可持续与高可用的联系与区别在于：高可用是应用可持续的必要非充分条件，而应用可持续不仅包括了基础设施侧的稳定性，还包括了用户侧的体验，是更为严苛的要求。
需要强调的是，随着敏捷开发、CI/CD、DevOps等理念的兴起与逐渐落地，应用可持续实际上需要在敏态中完成。比如，A/B测试、灰度发布时，业务应是平滑的，客户是无感知的。
应用可持续性架构，是指为了满足应用可持续，而采用的系统的、整体的IT架构，主要通过全生命周期健康检查与可观测、双活双轨、动态负载、主动韧性等手段，来摆脱对个别产品稳定性以及对个别运维人员的强依赖。应用可持续性架构，可以看作是软件工程思想在IT运维领域的具体实践。
应用可持续性架构验证，是指客户在选择应用可持续性架构及产品时，进行验证的方法论和具体指标。
应用可持续性背景
中国数字经济迅速发展
2016-2021年，中国数字经济发展取得新突破，数字经济规模实现翻倍增长。2021年中国数字经济规模由2016年的22.6 万亿元增加至 39.2 万亿元，数字经济增加值占GDP 比重由 30.3% 上升至 39.8%。“数字中国”建设不断推进，在推动经济高质量发展、构建新发展格局中发挥了重要作用。
在数字经济迅速发展背景下，技术进步、数字适老化及信息无障碍服务持续完善等因素驱动我国网民规模稳步增长。根据《第50次中国互联网络发展状况统计报告》，截至2022年6月，我国网民规模为 10.51 亿，互联网普及率达 74.4%，较2021年12月提升 1.4个百分点。其中，手机网民规模为 10.47 亿，同比增长约4%。
随着数字化进程加快及互联网、移动互联网等信息通信技术的更迭，我国数据量呈爆发式增长态势。2020年我国年数据量为 12 ZB，占全球数据量 24%，预计到2030年数据量将增长至175 ZB，年复合增长率约 30.7%，占全球数据量比重将上升至 29%。数字时代已然到来。
数字经济和数据量的快速增长，使得应用可持续性的重要性得到提升，原来作为辅助的数字世界和物理世界变得同样重要，而近几年的新冠疫情，使得数字的重要性进一步得到提升。另外，数字经济和数据量的快速增长，也使得应用可持续性面临前所未有的挑战：一方面原有的软硬件产品和架构难以承担数据量的爆炸式增长，而另一方面在老新迁移的过程中要求业务不能中断。
产业数字化进入了深水区
产业数字化是在满足原有产业组成结构的前提下，传统产业通过数字技术进行升级改造或将数字技术应用至现有产业中，从而为产业带来产值增加和效率提升。
近年来数字技术不断赋能传统行业产能增长，我国数字经济与实体经济融合发展也渐入佳境，作为推动数字经济发展的主动力，产业数字化在数字经济结构的比重连年上涨。根据《中国数字经济发展白皮书（2022）》数据，产业数字化较数字产业化始终占据绝对优势，2021年产业数字化占数字经济比重达到80.9%，同比增加0.7个百分点，较2017年上涨3.9个百分点，我国产业数字化的转型持续往纵深发展。
产业数字化的主体是传统行业，相比于互联网等原生数字行业，IT人员占比更少，技术水平更低。IT也往往非其业务本身，而往往是保障性环节，因此，不可能无限制地增加开支。这些也都要求不能完全依赖于开发、运维人员本身的IT素养，而需要以更加健壮、简洁的架构，来保障应用的可持续性。
应用可持续性价值
应用故障为企业带来直接经济损失
在数字化时代的今天，应用的稳定性和可持续性变得极为重要。早在2018年，保险公司劳合社与风险建模公司AIR Worldwide就联合发布了一份报告，预测了主要云服务器出现故障后可能带来的损失。报告表明，如果三大云供应商（Amazon，Google，Microsoft）发生一起3~6天的云故障，将导致190亿美元的损失。2021年10月4日，Facebook长达6小时的宕机，直接导致其股价暴跌6%。
除长时间宕机影响较大外，短时间的访问延迟，也会影响用户体验，并进一步带来经济损失。数据表明：74%的用户会离开5秒内未能打开的网站；86%的用户会卸载出现过3次以上性能问题的应用。以上，还仅是在一般的社交、电商等领域，而在证券等领域，对延迟更为敏感，对可持续性要求更为严格。
敏捷挑战
业务开发和运维支撑，本身需求就是天然相悖的。极端来说，研发部门想要：“随时随地发布新功能，没有任何阻拦”，而运维部门则想要：“一旦一个东西在生产环境中正常工作了，就不要再进行任何改动。”由于两个部门使用的语境不同，对风险的定义也不一致。在现实生活中，公司内部这两股力量只能用最传统的政治斗争方式来保障各自的利益。运维团队常常宣称，任何变更上线前必须经过由运维团队制定的流程，这有助于避免事故的发生。例如：运维团队会列出一个非常长的检查清单，历数所有以前曾经出现过的生产事故，要求研发团队在上线任何功能之前必须将所有这些事故模拟一遍，确保不会重现。这个清单通常没有任何标准，每项事故的可重现程度、问题价值并不一定是一致的。而开发团队吃过苦头之后也很快找到了自己的应对办法：开发团队宣称他们不再进行大规模的程序更新，而是逐渐转为功能开关调整、增量更新，以及补丁化。采用这些名词的唯一目的，就是为了绕过运维部门设立的各种流程，从而能更快地上线新功能。
除以上人的因素外，软硬件的利旧和业务需求以及技术本身的飞速发展，也是一对稳与敏的矛盾。以银行业为例，国有银行和股份制银行普遍建设有动辄几十亿甚至上百亿的数据中心，并在软硬件资源上具有大量投资，它们不可能抛弃历史，直接做架构的硬切换，比如，即使不考虑安全、可控等要素，它们也不可能直接切换到公有云。与此同时，在互联网时代成长起来的客户，却迫使银行的业务侧增加了大量新的需求，比如小额支付、活动促销、秒杀等。在需求增加的同时，新技术也层出不穷，Docker在2013年开源，Kubernetes在2014年开源，而如今，它们已经是互联网领域的主流技术，另外，NGINX、Istio、Opentelemetry、Prometheus、Grafana、MongoDB、Redis、TiDB、OceanBase等开源技术也不断降低开发运维难度、提升业务的敏捷性，并降低企业的运营成本。但是，这些新技术没有经历足够长时间的检验，并且个别点可能也不符合合规性要求。此时，银行便有了“既要跟上新技术，又要不直接放弃已有的数据中心和软硬件，还要稳定、合规，不出现闪失”的复杂性挑战。
信创挑战
在业务需求和新技术均快速变化的同时，信创也为金融、能源等企业的IT系统引入了新的复杂性。信创，即信息技术应用创新，是我国企业为了应对国外技术限制（如美国“实体清单”）而自发组织的国产替代行为。
我国的信创，大致可以分为四个阶段：第一阶段，大致为1999-2010年，当时仅可做到单品可用，以及面向特定场景，解决了有无的问题。第二阶段，大致为2011-2013年，该阶段做到了系统可用和成体系试用，尤其是在办公自动化和经营管理类等系统中。第三阶段，大致为2014-2017年，当时叠加互联网企业的去IOE浪潮，开始向基础领域演进，此阶段实现了基本可用到好用。第四阶段，在2018年之后，在多场景中开始规模化应用。
不过，在信创的高速发展中，仍面临着业务连续性、业务创新和安全防范的挑战。目前，在我国的诸多强IT依赖行业中，英特尔、英伟达、甲骨文、IBM、戴尔、威睿、红帽、SUSE、F5等海外公司，各自在不同领域，为客户提供稳定的产品和优质的服务，而国内对应产品良莠不齐，平均水平跟这些公司还有一定差距。
因此，我们应正视差距，并设立科学、严谨的验证标准：首先，在业务连续性方面，应设立各环节产品、服务的完整、科学的验证标准，在一个相对稳定的架构下先小规模试验、改进、扶持，动态调整信创业务比例，稳步扩大信创覆盖范围，面对业务不确定性，应可秒级恢复业务，并排除故障，找出故障原因。其次，在安全防护方面，面对黑客无差别攻击，需提高安全网关性能及可靠性，并采用异构能力，提高系统的对抗能力。再次，在业务创新方面，应积极地拥抱分布式、微服务等新兴架构以及开源生态，但又要通过镜像扫描、代码审计等，降低因开源带来的风险。
疫情挑战
受疫情影响，IT基础设施线下运维、巡检人员减少。疫情期间，为了避免聚集，运维领域出现了许多工作“新常态”，例如不少数据中心都采用AB岗轮班制、核心岗最小化办公或是工作方式转至“远距离、不接触”的线上办公模式，采取现场封闭办公、居家协同形式，到岗率从原先的 100% 精简到 50%，甚至不到10%。不少原来依赖于原厂运维或第三方运维的客户，为了避免人员的流动，降低人员感染风险，也在一定程度上失去外援，“孤军奋战”。
而与此同时，互联网流量陡然增长。由于疫情反复无常，大众的办公、金融、医疗等生产、生活的各个方面，对线上、对网络的依赖程度明显增加，整个社会转入线上运行的趋势陡然加速，互联网流量也由此以倍数级大幅提升。根据国家发改委，2022年1-6月我国移动互联网累计流量达 1241 亿GB，较 2021 年 1-6 月的 1033 亿GB增长 208 亿GB，同比增长约 20.1%。
线下运维、巡检人员的减少和互联网流量的陡然增长对服务器计算、存储和网络的水平扩展以及应用可持续性带来了新的需求与挑战。IT基础设施管理人员对停电或极端天气事件等各种灾难有比较明确的应急预案，但前所未有的新冠疫情为数据中心等基础设施的部署和运维工作提出了更高的要求，诸多挑战“跃然纸上”，亟待解决。例如，如何确保系统安全维护始终在线？当遇到大并发的外网访问时，如何对远程办公下的业务系统应用做好统一监控？当出现高流量访问引发系统卡顿和事件告警时，如何在海量数据中快速查找问题原因，保障运维效率？等等。
应用可持续性架构设计思想
抽象与分层
完整的业务应用需求传递链条为：用户/客户→公司业务侧→公司业务开发侧→运维侧，在单体架构以及瀑布流式开发中，这种需求的变动，缺乏在任何一层“消化”掉的能力，而是一传到底，因此，业务之敏和基础设施之稳成为矛盾。
而从另一个视角来看，当把业务看作稳态时（假定业务需求一成不变），基础设施侧也并不能保证一成不变，数据中心需要扩容，存储、计算、网络设备需要淘汰和更新换代。在早期，往往通过深夜停服等方式来进行，但随着人们对IT依赖程度的逐渐加深，这种方式可行性越来越低，基础设施之敏和业务之稳也成为矛盾。
也就是，链条的两侧，其实均不关心对方具体发生了哪些变化，只关心给自己带来了什么变化，并希望自己可自由变化。此时，便需要一个中间层，来将双方的变化相互“翻译”。这种“翻译”的过程就是抽象的过程，而中间层诞生，就是分层。
在IT架构中，负载均衡、容器编排、数据中台等，都是这种抽象与分层而产生的中间层，只是应用的场景不同。
不同层解耦
当中间层一旦产生，中间层的上下便会变得简单而自由起来。所有共性的东西，每个节点一律不再关心，因为中间平台层已经实现；与上下其他N多节点之间的对接，每个节点也不再关心，因为中间平台层已完成“翻译”和对接，原来复杂的乘积关系变成了只与中间层对接的加和关系。
这一相对统一的中间层，由于作用如此重要，因此往往成为业界事实上的标准，也往往成为“兵家”必争之地，Kubernetes、Marathon（Mesos）、Swarm之争便是如此。一旦其中一种真正胜出，标准便相对统一起来，上下层短时间之内会出现大繁荣。平台意义的中间层，被取代相对缓慢，即使在日新月异的IT界也是如此，这也就让稳态和敏态的结合有了抓手。当然，在实际中，往往存在多个类似意义的中间层，比如在应用可持续中，应用交付网络/负载均衡可以看作第一个中间层，其可一部分流量分给传统虚机，另一部分流量分给容器云，而在容器云中Kubernetes/Openshift又可作为第二个中间层。
同层节点冗余、替换、水平扩展与异构
一旦实现了抽象与分层、不同层解耦，那么中间层也就成为了IT架构的核心，只要它是相对稳定的，上下层的变化便可在该层“消化”掉，也即上层的变化不影响下层，下层的变化也不影响上层，这是稳态与敏态能够统一起来，也是应用可持续性的关键所在。上下层的节点作用被降低，平行节点间可冗余、可替换、可水平扩展、可异构。
其实，蓝绿发布、灰度发布、A/B测试等，均是利用的节点间可自由替换的特性实现的，只不过其往往是以相同的基础设施节点来运行不同的应用（版本），而上云、信创替代，则可用不同的基础设施来运行相同的应用。
中间层和核心节点的稳定性保障
在以上架构中，有一个显而易见的问题是，并没有考虑中间层和核心节点出现故障的情况，如果DNS解析节点、核心负载均衡器、容器编排平台等出现故障。核心节点或核心中间层的可用性一般通过以下手段进行保障。
（1）节点本身稳定
生产系统中的核心节点一般采用成熟、稳定、久经考验的产品和技术，并且版本升级策略一般也相对保守。例如：硬件方面，成熟的SLB、ADC设备均具有非常强的稳定性与可靠性。软件方面：Kubernetes在2016年便有大量企业进行尝试，但真正将其布到生产系统中则大多发生在2019年前后；NGINX，从其诞生到在各企业中广泛应用，经历了十几年时间，而为了保证稳定性，其支持HTTP3协议的NGINX-QUIC很长时间单独存在，直到现在仍未合并到NGINX主干中。
（2）轻负载，只做核心任务
由于核心节点具有全局性意义，其稳定的性能往往比丰富的功能更加重要，因此，普遍的一种做法是只让其承担调度和控制层面的事项，并不承担具体的工作任务。例如，四层负载，只负责流量转发，TCP的三次握手等直接分发到七层负载或应用节点。再比如，在不少银行中，SSL卸载不再放入负载均衡设备中，而是前后各一层负载均衡，中间一层SSL卸载，构成三明治结构。还比如，在早期的服务网格MOSN中，让Sidecar承担更多负载，而减少对中心节点的依赖。
（3）冗余
冗余，即主从架构。对于核心节点，比如负载均衡设备，一般均采用冗余的方式，来保障系统的高可用。负载设备本身之间的冗余可用VIP地址漂移来实现，也即只有一台物理设备来占用IP，当该物理设备出现故障，IP漂移到其他健康物理设备。
（4）产生新主节点
产生新主节点，即集群架构。如果主节点并非采用专用设备，那么在主节点出现故障时，自动根据算法将某子节点提升为主节点，这也是严格意义上的分布式。目前，这种方式在大数据领域以及区块链领域应用更为广泛。相比于主从架构，集群架构是严格意义上的分布式架构。
持久化存储且共享
节点的配置和服务发现数据通过高性能Key-Value内存数据库进行存储，并持久化到硬盘中，数据间通过Raft协议保持强一致性的共享。在控制节点，可使用etcd；而在执行节点，可使用Redis。
通过以上几步，节点的网络可以通过VIP漂移或者上层负载/编排平台的控制切换到其他节点，节点的任务可以通过本来的冗余或快速启动实例切换到其他节点，节点的数据因落到了共享的持久化存储中，也可被其他节点无缝继承。系统的健壮性和应用的可持续性，不再依赖于任何单一节点自身的可靠性。
应用可持续性架构特征
跨域协同与平滑迁移
（1）跨域双活双轨
数据中心双活架构：双活，是一种节约资源的计算机灾备方案。其实现模式是让主备两个数据中心都同时承担用户的业务，此时，主备两个数据中心互为备份，并且进行实时备份。一般来说，主数据中心的负载可能会多一些，比如分担60~70%的业务，备数据中心只分担40%~30%的业务，保证了当其中一边发生故障时，不至于造成业务无法处理的情况。
双活数据中心要做到网络双活、应用双活和数据双活。金融等行业，为了追求更高的可用性，且考虑成本，一般在双活之外再加灾备数据中心（俗称“两个半数据中心”）。
信创区和传统区双轨架构：利用和数据中心双活类似的原理，在同一数据中心中的信创区和传统区（非信创区）等不同模块之间实现热备或双活的方案，即为双轨运行。双轨架构相比于数据中心双活实现上更为复杂，这是因为双活数据中心，只是物理距离较远，但网络、计算、存储设备一般较为统一，所以组网相对容易，而双轨相当于异生态组网，需要更全面的软硬件生态屏蔽底层的异构和复杂。
交叉双活双轨架构：同时实现数据中心双活，以及信创区和非信创区双轨的架构，一般由多层负载设备和更复杂的软硬件生态来实现。
（2）双轨平滑迁移
双轨是指信创区和非信创区同时运行，具体有以下几种模式/步骤：
完全复制：信创区对非信创区的流量完全复制，进行“陪跑”，类似于数据中心的热备份。主要用于初期，对于某类型信创设备稳定性信任度较差的阶段。缺点是成本较高，造成大量的资源浪费。并且，这种方式，因为用户侧应用的响应其实还是完全依赖于非信创区，因此不便于将应用侧及信创区设备侧的指标做关联性分析。
流量分担：通过加权轮询等方式，赋予信创区较少权重，让其承担少部分业务负载。相比于流量完全复制，其实际承担了部分业务负载，降低了部分成本。
故障秒切：通过健康检查，当信创区出现业务故障，秒级切换回传统区，保障业务的可持续性。然后，根据健康检查参数和日志等，找出故障原因，进行恢复。
平滑过渡：随着信创区稳定性逐步提高，其负载权重也逐步上升，直至占据大部分，甚至全部。
协议互通：除了执行节点由传统区逐步过渡到信创区之外，控制/调度节点也应该平滑过渡，这就要求信创的调度、控制节点（负载均衡/应用交付）应与既有设备在协议上保持互通，可直接读取数据。
体验一致：除底层协议之外，用户体验层也仍应关注，控制节点的操作体验应尽量与原有设备一致，从而使得客户/用户学习成本最低，迁移平滑。
双轨平滑迁移的方式，在早期增大了基础平台层的适配工作量，但将应用和基础设施完全解耦，使得行业客户在迁移时不再拘泥于“一个应用一个应用迁移”这种单一形式，将大幅降低迁移难度，提升迁移进度，并保障了迁移过程中的稳定性。
多协议支持
应用可持续性，需要在不同层级支持多种主流协议，具体包括：
（1）网络层（三层）协议：IPv4、IPv6
（2）传输层（四层）协议：UDP、TCP、Fast TCP
（3）会话层（五层）协议：RPC
（4）应用层（七层）协议：HTTP1.1、HTTP2、HTTP3、FastHTTP
与现代高可用架构无缝对接
我们可把IT架构分为四个阶段：第一个阶段为小型机，其特点是单点高可用，但设备昂贵、封闭，扩展能力有限。第二阶段为硬负载设备+X86服务器，其特点是依赖硬负载，实现了单服务器节点的容错，通过冗余保障了高可用，同时扩展方便，但负载本身定制性较差。第三阶段为以NGINX、LVS、HAProxy为代表的软负载+物理机/虚机，特点是开源、定制性强。第四阶段是以Kubernetes为代表的云原生架构，其内部负载一般采用Kubernetes原生功能，或使用NGINX、Traefik、Envoy等。其中，第三和第四阶段，因为符合软件定义基础设施的特点，均可视为现代架构。但在金融等行业中，存在大量的IT历史包袱，四个阶段的架构和产品均在使用，因此，应用交付系统必须既能利旧，又能面向未来。具体的，应在纵向上，同时跨全局负载均衡（GSLB）、四层负载均衡、七层负载均衡、kubernetes Ingress Controller等环节，实现对接。
可观测性和分析
（1）可观测性实现手段
日志：展现的是应用程序运行产生的事件或记录，可以详细解释其运行状态。日志描述了一些离散的、不连续的事件，对于应用程序的可见性是很好的信息来源，也为应用程序的分析提供了精确的数据源。日志的数据量较大，但价值密度较低，一般有两种使用方式：①事后进行定位分析。②依赖于指标，进行迅速抽取、聚合，并实时分析。
指标：与日志有所不同，日志提供的是显式数据，而指标是通过数据的聚合，对一个程序在特定时间内的行为进行衡量。指标数据是可累加的，它们具有原子性，每个都是一个逻辑计量单元。指标数据可以观察系统的状态和趋势，但对于问题定位缺乏细节展示。
追踪：面向的是请求，可以分析出请求中的异常点，但与日志有相同的资源消耗问题，通常需要通过采样等方式减少数据量。追踪的最大特点是它在单次请求的范围内处理信息，任何数据、元数据信息都被绑定到系统中的单个事务上。
在CNCF给出的云原生全景图中，将可观测性和分析放在了同一个维度。一方面通过实现可观测性的工具，获取系统中各个维度的运行数据，从而对整个云原生架构下的应用运行情况有全面深入的了解；另一方面，在拥有了这些数据之后，可以进行安全性分析、运维故障分析、性能分析等。另外，这些数据一般也会输出到包括应用交付系统中，以提供动态负载、智能决策等。
（2）具体观测内容
资源层监测：①高权重指标包括CPU使用率、GPU使用率、内存使用率、磁盘使用率、集群节点总数、Node使用、集群中调度完成Pod数、当前进程打开文件数。②中权重指标包括集群中处于Succeeded阶段的Pod数、集群中处于Running阶段的Pod数、当前内核空间占CPU百分比、磁盘每秒写入字节数、GPU显存空间量、过去五分钟系统平均负载。③低权重指标包括调度器调度频率、集群Job数、集群Secret数、调度器在线实例数、当前用户空间占用CPU百分比、集群Namespace数、集群Endpoint数。
网络监测：①高权重指标主要包括客户链接数、丢包率、流量、吞吐量、客户端延时、事件连接数、建连成功率。②中权重指标主要包括流出包数、网络评分、流出字节、服务器延时、包大小分布、建连成功率。③低权重指标主要包括带宽、流入吞吐量、大包占比、重传时延、流入字节、流出吞吐量、中包占比、0窗口。
中间件监测：①高权重指标主要包括消息订阅详情、消息阅读量、消息推送平均耗时、消息订阅平均耗时、消息推送详情、消息推送数量。②中权重指标包括Young GC平均数量、Eden平均使用情况、Full GC平均是量、老年代使用率、Eden使用率、Young GC平均时间、Full GC平均时间。③低权重指标包括OSS请求数量、OSS请求平均耗时。
数据库监测：①高权重指标包括查询响应时间、查询错误率、QPS、连接数、连接数利用率、健康度。②中权重指标包括数据库请求数、数据库请求平均耗时、SQL查询耗时排名、数据库请求详情。③低权重指标主要包括Tair内存数据库请求数、Tair请求详情、Tair请求平均耗时。
应用（Server侧）监测：①高权重指标主要包括健康度、Apdex、吞吐率、响应时间、错误率。②中权重指标主要包括慢请求次数、调用数据库错误率、慢请求占比、调用数据库次数、调用MQ次数、调用数据库响应时间。③低权重指标主要包括调用外部服务次数、调用外部服务响应时间、调用外部服务错误率、调用MQ错误率。
用户（Client侧）监测：①高权重指标主要包括可优化延时、体验评分、首屏时间、ANR、卡顿、整体性能、崩溃、可用性、白屏时间、通过率、可交互时间、首次渲染时间。②中权重指标主要包括活跃用户数、JS错误、请求错误率、请求错误、劫持比例、DNS时间。③低权重指标主要包括400错误率、ping耗时、SSL建连时间、响应时间、500错误率、TCP建连时间、信息量、设备型号、600错误率、CDN城市匹配率、CDN运营商匹配、CDN请求性能、应用安装耗时、首包时间。
负载可编排
如果把可观测比作感知神经，那么负载就是运动神经。它可将可观测系统的输出，直接转为自己的输入，进而动态调整，保障应用的可持续性。
（1）静态算法
静态算法中，下游节点业务负载占比是固定不变的，也即负载设备不根据可观测系统监测到的下游节点的性能指标进行动态调整，包含轮询、加权轮询、随机、目标IP哈希、源IP哈希、URL哈希等。
（2）基础动态算法
动态负载中，可观测系统将各种监测指标实时反馈给负载均衡，负载均衡根据这些指标，实时对下游节点间权重做出调整。具体算法包含最少连接、加权最少连接、基于局部性的最少连接、带复制的基于局部性最少连接、Fair调度算法等。
（3）动态算法扩展
除常见动态算法外，还可以自定义动态负载均衡算法，目前，在学术界，已经对遗传算法、领导者选举算法、布谷鸟搜索算法等在负载均衡中进行尝试，甚至将基于深度学习的流量预测用于负载均衡，但在生产中，这些应用仍较少。动态负载均衡算法扩展应考虑以下要素：（1）可观测系统的监测指标及其权重。（2）监测指标的离散程度：如节点的CPU利用较高，但磁盘利用较低，实际上已经产生资源碎片，并非单依靠负载均衡能解决。（3）算法本身的可靠性：在局部更优的算法有可能因过拟合，在更广泛的场景中性能较差。（4）算法本身的执行时间和性能损耗：如果将阈值设置较低，可能导致节点间权重频繁切换，产生不必要的性能损耗。
主动韧性
大多情况下，对于应用可持续性的关注点往往在于被动健壮，也即尽量“想”全所有的问题，但包括混沌工程在内的高可用测试，则直接以“试”的方式让架构实现主动健壮。其类似于“军演”，在对业务完全无影响，或者控制好爆炸半径的情况下，对架构发起计划的或随机的测试，从而使得架构更加稳定、健壮，具备韧性。
开放与集成
在开放性与集成性方面，应用可持续性产品应支持CLI、API和GUI等不同方式的操作，以真正实现基础设施即代码（IaC）。
（1）GUI：用户图形接口。目前一般为BS架构，也即支持H5的交互式操作、移动端可自适应。语言应支持多国语言，至少支持中英双语。
（2）API：应用程序接口。一般指通过HTTP协议传输的，以Json为请求体和响应体的Restful API，未来还包括GraphQL风格的API。API可摆脱数据、应用对接中对特定开发语言的限制。为了安全起见，API调用前一般还须进行鉴权，包括静态Appkey、动态Sign以及OAuth2.0认证等。
（3）CLI：命令行接口。尽管GUI更易理解，学习成本更低，但命令行仍在多场景下发挥作用，其资源开支更小，也更容易实现标准化与批量化，尤其在linux的开发和运维中，仍十分常见。
根据应用可持续性架构的整体设计思想和细分特征，结合金融、运营商、能源、政务等多个行业对应用可持续性架构的关注点，本章节从性能测试、基础功能测试、超高可用架构场景测试和管理功能测试等4个维度切入，详细说明了应用可持续性架构的37个通用验证指标，并给出了常规测试步骤。具体企业在实际测试时，可根据自身情况，对具体指标进行调整。
纵观应用可持续性架构的发展过程，从以“商务区—体验区”构建的双区运营的双活架构，到基于4/7层分离的双模IT架构，再发展至如今的以灰度割接构建的双轨信创架构，应用可持续性架构在每一阶段都不断夯实基础。未来以算力网络技术为主的云网融合网络架构演进将对应用交付高可用性提出更高的要求。
云网融合，是指云计算与通信网相融合，即将网络技术引入至云计算中，与此同时在通信网中引入云计算技术。算力作为推动数字经济发展的主引擎动力，成为数字化时代的基础设施。
在算力网络时代下，对应用可持续性架构提出了五个更高的要求：（1）可靠性方面，应保证应用服务在要求时间内始终处于可用状态；（2）可恢复性，当外界发生事故造成宕机时，应用需更快速恢复正常服务状态；（3）可伸缩性，由于算力网络的变化与增长迅速，应用具有更高的可伸缩性以适应算网的变化；（4）可监控性，应用运行情况复杂，需要持续并高频地监控及分析。（5）可维护性，应用的维护和升级频率将会更加频繁，因此需要应用具备更高的可维护性，以便应用迭代与维护。
这些都要求，在未来算力网络架构下的应用可持续要具有更强的软件定义特性、安全特性和AI特性。
