应用研究报告介绍：*本报告由艾瑞咨询咨询与神州云科、童鸣湖云和新创研究院、童鸣智云联合发布。在当今数字化时代，应用可持续性不仅直接关系到一般业务领域的经济效益，还关系到公共服务领域的国计民生。然而，在用户数量、网络流量、应用复杂性不断增加以及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%。随着数字化的加速和信息的变化

随着数字经济和数据量的快速增长，应用程序可持续性的重要性已经增强。原本的数字世界和物理世界，作为辅助，变得同等重要。然而，近年来的新冠肺炎疫情进一步增强了数字的重要性。此外，随着数字经济和数据量的快速增长，应用可持续性面临着前所未有的挑战：一方面，原有的软硬件产品和架构难以承受数据量的爆炸式增长，另一方面，新旧迁移过程中需要业务不间断。

工业数字化已经进入深水区。在满足原有产业结构的前提下，通过数字技术提升传统产业或将数字技术应用于现有产业，从而为产业带来产值和效率的增加。近年来，数字技术不断让传统行业产能提升，我国数字经济与实体经济融合越来越好。作为推动数字经济发展的主要动力，工业数字化在数字经济结构中的比重逐年上升。从《中国数字经济发展白皮书（2022）》的数据来看，工业数字化相对于数字工业化一直占据绝对优势。2021年，工业数字化占数字经济的比重为80.9%，同比提高0.7个百分点，比2017年提高3.9个百分点。中国工业数字化转型持续深入发展。

数字化的主体是传统行业。与互联网等原生数字行业相比，IT人员占比更少，技术水平更低。往往不是业务本身，而是保障环节，不可能无限增加支出。所有这些需求都不能完全依赖于开发和运营人员本身的IT素养，而需要一个更加健壮和简洁的架构来保证应用的可持续性。

可持续价值的应用失败会给企业带来直接的经济损失。在当今的数字时代，应用程序的稳定性和可持续性变得极其重要。早在2018年，保险公司劳合社和风险建模公司AIR Worldwide联合发布报告，预测了各大云服务器故障可能造成的损失。报告称，如果三大云提供商(亚马逊、谷歌、微软)发生3-6天的云故障，将导致190亿美元的损失。2021年10月4日，脸书6小时的宕机直接导致其股价暴跌6%。

除了长的时间停机，短的时间访问延迟也会影响用户体验，进一步带来经济损失。数据显示：74%的用户会在5秒内离开无法打开的网站；86%的用户会卸载遇到3个以上性能问题的应用。以上，只是在一般社交和电商领域，而在证券等领域，对延迟更敏感，对可持续性要求更严格。

挑战敏捷业务开发和运维支持，其自身需求自然是相悖的。极端的情况下，R&D部门希望“随时随地毫无障碍地发布新功能”，而运维部门希望“一旦某个东西在生产环境中正常工作，就不要做任何改变。”由于两个部门使用的上下文不同，风险的定义也不一致。在现实生活中，公司内部的这两股势力只能用最传统的政治斗争方式来维护各自的利益。运维团队往往声称任何改动都要经过运维团队制定的流程才能上线，有助于避免意外。例如，运营和维护团队将列出一份很长的清单，列出所有以前的生产事故，并要求R&D团队在启动任何功能之前模拟所有这些事故，以确保它们不会再次发生。这个列表中通常没有标准，每个事故的重现性和问题值也不一定相同。痛苦过后，开发团队很快找到了自己的解决方案：开发团队宣称他们不再进行大规模的程序更新，而是逐渐转向功能切换调整、增量更新、打补丁。使用这些术语的唯一目的是绕过运维部门设置的各种流程，以便更快地推出新功能。除了人的因素，软硬件的优势，业务需求和技术本身的快速发展也是一个稳定性和灵敏性的矛盾。以银行业为例。国有银行和股份制银行一般建设数据中心都是几十亿甚至几百亿，在软硬件资源上投入很大。他们不可能抛弃历史，直接切换架构。比如他们即使不考虑安全性、可控性等因素，也无法直接切换到公有云。同时，互联网时代成长起来的客户，也迫使银行的业务端增加了很多新的需求，比如小额支付、活动推广、秒杀等等。随着需求的不断增加，新技术层出不穷。Docker在2013年开源，Kubernetes在2014年开源。现在，它们是互联网领域的主流技术。此外还有NGINX、Istio、Opentelemetry、Prometheus、Grafana、MongoDB、Redis、TiDB、OceanBase等开源技术。也不断降低开发运营和升级的难度。但是这些新技术都没有经过长时间的测试时间，个别点可能达不到合规要求。此时，银行面临着“跟上新技术，不直接放弃现有的数据中心、软件和硬件，还要稳定、合规、不出错”的复杂挑战。

在业务需求和新技术快速变化的同时，新创也给金融和能源企业的IT系统带来了新的复杂性。创新，即信息技术应用创新，是中国企业为应对国外技术限制(如美国的“实体清单”)而自发组织的国内替代行为。中国的新创大致可以分为四个阶段：第一阶段，大致从1999年到2010年，只有单品可用，针对特定场景解决可用性问题。第二阶段，大致从2011年到2013年，实现系统可用和系统试用，尤其是办公自动化和管理系统。第三阶段大致是2014年到2017年。当时叠加了互联网公司去IOE的浪潮，开始向基础领域演变。在这个阶段，它基本上是可用的，并且易于使用。第四阶段，2018年后，多场景开始大规模应用。然而，在新创的快速发展中，它仍然面临着业务连续性、业务创新和安全性的挑战。目前国内众多IT依赖型行业中，海外公司如Intel、Nvidia、甲骨文、IBM、戴尔、Veritas、红帽、SUSE、F5等。在不同领域为客户提供稳定的产品和优质的服务，而国内相应产品良莠不齐，平均水平仍落后于这些公司。因此，我们应该正视差距，建立科学严谨的验证标准：一是在业务连续性方面，对产品和服务的各个环节建立完整科学的验证标准，进行小规模试验，在相对稳定的框架下进行完善和支撑，动态调整新创业务的比重，稳步扩大覆盖范围，面对业务不确定性能够秒级恢复业务，排查并找出故障原因。其次，在安全防护方面，面对黑客的无差别攻击，我们需要提高安全网关性能和可靠性，采用异构能力，以及提高系统对抗能力。再次，在业务创新方面，要积极拥抱分布式、微服务等新架构，以及开源生态，但也要通过图片扫描、代码审计等方式降低开源带来的风险。

挑战受疫情影响，IT基础设施线下运维、巡检人员减少。疫情期间，为了避免聚集，运维领域出现了很多工作“新常态”。例如，许多数据中心采用了AB轮班制，最大限度地减少了核心岗位，或者将工作模式改为“远程、无接触”的在线办公模式，采用现场封闭办公和家庭协作的形式，出勤率从原来的100%降低到50%甚至不到10%。很多以前依赖原厂运维或者第三方运维的客户，为了避免人员流动，降低感染风险，也在一定程度上失去了外援，“孤军奋战”。与此同时，互联网流量急剧增加。由于疫情的反复无常，公职、金融、医疗等生产生活各方面对互联网的依赖程度明显增加，全社会转向线上运营的趋势骤然加快，从而互联网流量成倍增长。国家发改委数据显示，2022年1-6月中国移动互联网累计流量达1241亿GB，较2021年1-6月的1033亿GB增长208亿GB，同比增长约20.1%。线下运维，巡检人员的减少，互联网流量的骤增，给服务器计算、存储、网络的横向扩展和应用的可持续性带来了新的需求和挑战。IT基础设施管理者对停电或极端天气事件等各种灾害有明确的应急预案，但前所未有的新冠肺炎疫情对数据中心等基础设施的部署和运维提出了更高的要求，许多挑战“跃然纸上”，亟待解决。比如，如何保证系统安全维护始终在线？如何统一监控远程办公下的业务系统应用

应用可持续性架构设计思想抽象且分层，完整的业务应用需求传导链为：用户/客户公司业务端公司业务开发端运维端。在单一架构和瀑布流开发中，这种需求变化缺乏在任何层面“消化”的能力，而是传递到最后。所以业务的敏感性和基础设施的稳定性就成了矛盾。从另一个角度来看，当业务被视为稳态时(假设业务需求不变)，基础设施端无法保证不变。数据中心需要扩展，存储、计算和网络设备需要淘汰和更新。早期往往是通过半夜停止服务来完成，但随着人们对它的依赖逐渐加深，这种方式的可行性越来越低，基础设施的敏感性和业务的稳定性就产生了矛盾。也就是链条的两边其实都不在乎对方发生了什么变化，只在乎给自己带来了什么变化，希望自己能自由改变。此时，需要一个中间层来“翻译”双方的变化。这个“翻译”的过程是一个抽象的过程，中间层的诞生就是分层。在IT架构中，负载均衡、容器安排、数据处理等等都是这种抽象和分层产生的中间层，只是应用场景不同。

不同层的解耦一旦产生了中间层，中间层的上下两层就会变得简单自由。一切共通，每个节点不再关心，因为中间平台层已经实现；每个节点不再关心与上下其他N个多节点的对接，因为中间平台层已经完成了“翻译”和对接，原来复杂的产品关系变成了只与中间层对接的加法关系。

这种相对统一的中间层，因为其重要的作用，往往成为行业内事实上的标准，也往往成为“兵家必争之地”，如Kubernetes、Marathon(Mesos)和Swarm。一旦其中一方真的胜出，标准就会相对统一，上下层次都很短时间内会有大繁荣。平台意义的中间层被替代的速度相对较慢，即使在瞬息万变的IT世界也是如此，这使得稳态和敏感态的结合有了把握。当然，在实际操作中，往往会有很多含义相似的中间层。比如在应用可持续性中，应用交付网络/负载均衡可以看作是第一中间层，可以将一部分流量分配给传统虚拟机，另一部分分配给容器云，Kubernetes/Openshift可以作为容器云中的第二中间层。

一旦同一层节点的冗余、替换、横向扩展、异构被抽象分层，不同层被解耦，那么中间层就成为IT架构的核心。只要相对稳定，上下两层的变化都可以在这一层“消化”，即上层的变化不影响下层，下层的变化不影响上层。这是稳定状态和敏感状态的统一，以及应用程序的可持续性的关键。上下节点功能减少，并行节点可以冗余、可替换、可水平扩展、异构。

其实蓝绿出版，灰度出版，A/B测试等。都是利用节点可以自由更换的特性实现的，但是往往使用同一个基础设施节点运行不同的应用(版本)，当云和新创更换后，可以使用不同的基础设施运行相同的应用。

在上述架构中，有一个明显的问题是没有考虑中间层和核心节点的故障，比如DNS解析节点、核心负载均衡器、容器编排平台等的故障。核心或核心中间层的可用性通常通过以下方式来保证。(1)节点本身是稳定的。生产系统中的核心节点一般采用成熟、稳定、经过时间考验的产品和技术，版本升级策略一般相对保守。比如在硬件方面，成熟的SLB和ADC器件都有非常强的稳定性和可靠性。软件方面：Kubernetes在2016年有大量尝试，但Kubernetes实际部署到生产系统大多发生在2019年前后；NGINX，从诞生到广泛应用于各类企业，经历了十几年时间。保证稳定性，其支持HTTP3协议的NGINX-QUIC很长时间单独存在，直到现在也没有并入NGINX的主干。(2)轻负荷，只做核心任务。由于核心节点具有全局意义，其稳定的性能往往比丰富的功能更重要。因此，通常的做法是只让它承担调度和控制问题，而不承担具体的工作任务。比如四层负载只负责流量转发，TCP的三次握手直接分配给七层负载或者应用节点。比如很多银行不再把SSL offload放入负载均衡设备，而是前后两层负载均衡，中间层是SSL offload，构成了三明治结构。例如，在早期的服务网格MOSN中，Sidecar被用来承担更多的负载，并减少对中心节点的依赖。(3)冗余，即主从架构。对于负载均衡设备等核心节点，一般采用冗余来保证系统的高可用性。设备之间的冗余可以通过VIP地址漂移来实现，即只有一个物理设备占用IP，当该物理设备出现故障时，IP漂移到其他健康的物理设备。(4)生成新的主节点生成新的主节点，即集群架构。如果主节点不是专用设备，当主节点出现故障时，会根据算法自动将一个子节点提升为主节点，这是严格分布的。目前，该方法在大数据和区块链领域应用较为广泛。与主从体系结构相比，集群体系结构是严格的分布式体系结构。

持久化存储和共享节点的配置和服务发现数据存储在高性能的键值存储数据库中并持久化到硬盘上，通过Raft协议实现数据的强一致性共享。在控制节点，etcd可以用；在执行节点，可以使用Redis。通过以上步骤，节点的网络可以通过VIP漂移或上层负载/调度平台的控制切换到其他节点，节点的任务可以通过原有的冗余或快速启动实例切换到其他节点，节点的数据由于落入共享的持久存储中，可以被其他节点无缝继承。系统的健壮性及其应用的可持续性不再取决于任何单个节点的可靠性。

应用可持续架构特点跨域协作、平滑迁移(1)跨域双活双轨数据中心双活架构：双活是一种节省资源的计算机容灾方案。其实现方式是主数据中心和备用数据中心同时承担用户的业务。此时主用数据中心和备用数据中心互为备份，做实时备份。一般来说，主用数据中心的负载可能更多，比如分担60-70%的业务，而备份数据中心只分担40-30%的业务，这就保证了当一方出现故障时，业务无法处理。主动数据中心应该在网络、应用和数据方面都是主动的。在金融行业，为了追求更高的可用性和考虑成本，一般会在双活岗位中加入容灾数据中心(俗称“两个半数据中心”)。

创意区和传统区双轨架构：双轨运行是利用类似数据中心双活运行的原理，实现同一数据中心内创意区和传统区(非创意区)等不同模块之间的热备或双活运行的方案。双轨架构比双活数据中心实现更复杂，因为双活数据中心只是物理距离远，但网络、计算、存储设备一般是统一的，所以组网相对容易，而双轨架构相当于异构组网，需要更全面的软硬件生态屏蔽底层的异构性和复杂性。

交叉主动双轨架构：数据中心双轨架构和信息与非信息创造区双轨架构一般通过多层负载设备和更复杂的软硬件生态来实现。

(2)双轨平稳迁移双轨是指创意区和非创意区同时运行。有以下几种模式/步骤：完全复制：创意区完全复制非创意区的流量，“随用随跑”，类似于数据中心的热备份。主要用于初始阶段，对某类信息创新设备稳定性的信任较差的时候。缺点是成本高，造成大量资源浪费。而且这样一来，由于应用在用户端的响应实际上完全取决于非信息创建区，所以不方便分析应用端和信息创建区设备端的指标之间的相关性。

流量共享：通过加权轮询等方式。新创区被赋予较少的权重，使其可以承担一小部分业务负荷。相对于流量的完全复制，实际上承担了一部分业务负载，降低了一部分成本。

秒断：通过健康检查，当新创区出现业务故障时，秒切换回传统区，保证业务可持续。然后根据健康检查参数和日志，找出故障原因，进行恢复。

平滑过渡：随着信息创新区的稳定性逐渐增加提高，其负载重量也逐渐上升，直至占据大部分甚至全部。

协议互通：除了执行节点从传统区域逐渐过渡到新创区域，控制/调度节点也要平滑过渡，这就要求新创的调度和控制节点(负载均衡/应用交付)要保持与现有设备的协议互通，并能直接读取数据。体验一致性：除了底层协议，用户体验层还是要重视的，控制节点的操作体验要尽可能与原设备一致，让客户/用户的学习成本最低，迁移顺畅。平滑双轨迁移增加了前期基础平台层的适配工作量，但将应用与基础设施完全解耦，使得行业客户在迁移时不再拘泥于“一个应用一个应用迁移”的单一形式，这将大大降低迁移难度，提高迁移进度，保证迁移过程中的稳定性。

多协议支持应用可持续性，需要支持多种不同层次的主流协议，包括：(1)网络层(三层)协议：IPv4和IPv6(2)传输层(四层)协议：UDP、TCP、FastHTTP(3)会话层(五层)协议：RPC(4)应用层(七层)协议：HTTP321.1

无缝连接现代高可用架构，我们可以把IT架构分为四个阶段：第一阶段是小型机，特点是单点高可用，但设备昂贵且封闭，扩展能力有限。第二阶段是带硬负载设备的X86服务器，特点是依靠硬负载，实现单个服务器节点的容错，通过冗余保证高可用性，扩展方便，但负载本身定制性差。第三阶段是以NGINX、LVS、HAProxy为代表的软负载物理机/虚拟机，特点是开源、定制性强。第四阶段是云原生a

可观测性与分析(1)可观测性实现的日志手段：它展示了应用程序运行所产生的事件或记录，能够详细说明其运行状态。日志描述了一些离散的和不连续的事件，这对于应用程序的可见性是一个很好的信息来源，并且为应用程序的分析提供了一个准确的数据源。日志数据量大，但价值密度低。一般可以用两种方式：事后定位分析。根据指标快速提取、汇总、实时分析。指标：与日志不同，日志提供的是显性数据，而指标是通过数据聚合来衡量一个程序在特定时间中的行为。指标是累积性的，它们是原子性的，每个指标都是一个逻辑度量单位。数据可以观察系统的状态和趋势，但缺少问题定位的细节。跟踪：是针对请求的，可以分析请求中的异常点，但是和日志一样有资源消耗问题，通常需要通过采样来减少数据量。跟踪的最大特点是处理单个请求范围内的信息，任何数据和元数据信息都绑定到系统中的单个事务。

在CNCF给出的云原生全景图中，可观测性和分析被放在同一个维度。一方面，通过可观测性这一工具，可以获得系统中各个维度的运行数据，从而对整个云原生架构下的应用运行情况有一个全面深入的了解；另一方面，有了这些数据之后，我们可以做安全性分析、运维故障分析、性能分析等。此外，这些数据通常会输出到应用交付系统，以提供动态负载和智能决策。(2)具体观察内容资源级别监控：高权重指标包括CPU利用率、GPU利用率、内存利用率、磁盘利用率、集群节点总数、节点使用率、集群中调度的pod数、当前进程中打开的文件数。中等权重指标包括成功阶段的pod数、运行阶段的pod数、当前内核空间占CPU的百分比、每秒写入磁盘的字节数、GPU内存空间量、过去五分钟的平均系统负载。低权重指标包括调度器调度频率、集群作业数、集群秘密数、调度器在线实例数、当前用户空间占用CPU百分比、集群命名空间数、集群端点数。网络监控：高权重指标主要包括客户链接数、丢包率、流量、吞吐量、客户端延迟、事件连接数、连接建立成功率。中等权重指标主要包括外发包数、网络得分、外发字节数、服务器延迟、包大小分布、连接建立成功率。低权重指标主要包括带宽、入局吞吐量、大包比、重传时延、入局字节、出局吞吐量、中包比、0窗口。中间件监控：高权重指标主要包括消息订阅详情、消息阅读量、消息推送平均耗时、消息订阅平均耗时、消息推送详情、消息推送次数。中权重指标包括年轻GC平均数量、Eden平均使用量、满GC平均量、老年使用率、Eden使用率、年轻GC平均时间、满GC平均时间。低权重指标包括OSS请求数量和OSS请求平均耗时。数据库监控：高权重指标包括查询响应时间，查询错误率，QPS，连接数，连接利用率，健康。中权重指标包括数据库请求数量、数据库请求平均耗时、SQL查询耗时排名、数据库请求细节。低权重指标主要包括Tair内存数据库的请求数、Tair请求的明细、Tair请求的平均耗时。应用(服务器端)监控：高权重指标主要有健康、Apdex、吞吐量、响应时间、错误率。中权重指标主要包括慢请求数、数据库调用出错率、慢请求比例、数据库调用数、MQ调用数、数据库调用响应时间。低权重指标主要包括调用外部服务的次数、调用外部服务的响应时间、调用外部服务的出错率、调用MQ的出错率。用户(客户端)监测：高权重指标主要有可优化延迟、体验评分、首屏时间、ANR、卡顿、整体性能、崩溃、可用性、白屏时间、通过率、交互性时间、首次渲染时间。中等权重指标主要包括活跃用户数、JS错误、请求错误率、请求错误、劫持率、DNS时间。低权重指标主要包括400错误率、ping耗时、SSL连接时间、响应时间、500错误率、TCP连接时间、信息量、设备型号、600错误率、CDN城市匹配率、CDN运营商匹配、CDN请求性能、应用安装耗时等。

如果把可观察物比作感觉神经，那么负荷就是运动神经。它可以直接将可观测系统的输出转化为自身的输入，然后进行动态调整，保证应用的可持续性。(1)静态算法在静态算法中，下游节点的业务负载比例是固定的，即负载设备不根据可观测系统监测的下游节点的性能指标进行动态调整，包括轮询、加权轮询、随机、目标IP哈希、源IP哈希、URL哈希等。(2)基本动态算法在动态负载中，可观测系统将各种监测指标实时反馈给负载均衡，负载均衡根据这些指标实时调整下游节点的权重。该算法包括最小连接、加权最小连接、基于位置的最小连接、基于位置的最小连接和复制、公平调度算法等。(3)动态算法扩展除了常见的动态算法，还可以自定义动态负载均衡算法。目前学术界有遗传算法、领袖选举算法、布谷鸟搜索等。已经在负载均衡方面进行了尝试，甚至基于深度学习的流量预测也已经用于负载均衡，但是这些应用在生产中还是很少的。动态负载均衡算法的扩展需要考虑以下因素：(1)可观测系统的监控指标及其权重。(2)监控指标不符：如果一个节点的CPU利用率高，但磁盘利用率低，实际上已经产生了资源碎片，单纯依靠负载均衡无法解决。(3)算法本身的可靠性：局部较好的算法，在更大范围的场景下可能会因为过拟合而表现不佳。(4)算法本身的执行时间和性能损失：如果阈值设置得较低，可能会导致节点之间频繁切换权重，造成不必要的性能损失。

主动弹性在大多数情况下，对应用程序可持续性的关注往往是被动健壮性，即试图“思考”所有问题。而包括混沌工程在内的高可用性测试，可以通过“尝试”直接使架构主动健壮。它类似于“军事演习”，在不影响业务或处于爆炸半径控制下的情况下，对架构发起有计划或随机的测试，从而使架构更加稳定、健壮和有弹性。

开放与融合。在开放性和集成性方面，应用可持续性产品要支持CLI、API、GUI等不同的运行方式，真正实现基础设施即代码(IaC)。(1)GUI:用户图形界面。目前一般是BS架构，即支持H5的交互操作，移动终端可以自适应。语言要支持多种语言，至少中文和英文都要支持。(2)API:应用程序接口。一般是指通过HTTP协议传输的Restful API，以Json作为请求体和响应体，未来还会包括GraphQL风格的API。API可以在数据和应用对接上摆脱特定开发语言的限制。出于安全考虑，API调用前通常需要进行认证，包括静态Appkey、动态Sign和OAutp.0认证。(3)CLI:命令行界面。虽然GUI更容易理解，学习成本更低，但是命令行仍然在多个场景中发挥作用，其资源支出更小，更容易实现标准化和批量生产，尤其是在linux的开发和运维中。

根据应用可持续架构的整体设计思路和细分特点，结合金融、运营商、能源、政府等行业对应用可持续架构的关注，本章从性能测试、基础功能测试、超高可用架构场景测试和管理功能测试四个维度入手，详细阐述了应用可持续架构的37项通用验证指标，并给出了常规测试步骤。在实际测试中，企业可以根据自身情况调整具体指标。

纵观应用可持续架构的发展历程，从“商务区-体验区”构建的双区运营双活架构，到基于4/7层分离的双模式IT架构，再到灰度割接构建的双轨信息创造架构，应用可持续架构在每一个阶段都一直在夯实基础。基于未来计算网络技术的云融合网络架构的演进，将对应用交付的高可用性提出更高的要求。云融合是指云计算与通信网络的融合，即将网络技术引入云计算，同时将云计算技术引入通信网络。作为推动数字经济发展的主要引擎驱动力，计算已经成为数字时代的基础设施。在计算网络时代，对应用可持续性架构提出了五个更高的要求：(1)在可靠性方面，应用服务应在要求范围内始终可用时间；(2)可恢复性，当外部事故导致停机时，应用需要更快地恢复到正常服务状态；(3)可扩展性，由于计算网络的快速变化和增长，应用具有更高的可扩展性以适应计算网络的变化；(4)可监控性，应用和操作复杂，需要持续、高频的监控和分析。(5)可维护性，应用维护和升级的频率会更频繁，所以需要应用具有更高的可维护性，这样应用才能迭代和维护。所有这些需求都要求未来计算网络架构下的应用应该是可持续的，具有更强的软件定义特性、安全特性和AI特性。