数字时代应用可持续性架构与验证白皮书.pdf

数字时代应用可持续性架构与验证 白皮书 2022.12 iResearch Inc.2022 年数字时代应用可持续性架构与验证白皮书 1 目 录 第一章 数字化时代的应用可持续性.4 一、应用可持续性概述.4 二、应用可持续性背景.5 1、中国数字经济迅速发展.5 2、产业数字化进入了深水区.6 三、应用可持续性价值.7 1、应用故障为企业带来直接经济损失.7 2、政务、金融领域的应用可持续性关系国计民生.8 第二章 应用可持续性挑战.10 一、敏捷挑战.10 二、信创挑战.11 三、疫情挑战.12 第三章 应用可持续性架构设计思想与特征.14 一、应用可持续性架构设计思想.14 1、抽象与分层.14 2、不同层解耦.14 3、同层节点冗余、替换、水平扩展与异构.15 4、中间层和核心节点的稳定性保障.17 5、持久化存储且共享.18 二、应用可持续性架构特征.18 1、跨域协同与平滑迁移.18 2、多协议支持.23 3、与现代高可用架构无缝对接.26 4、可观测性和分析.27 5、负载可编排.30 6、主动韧性.32 7、开放与集成.33 第四章 应用可持续性架构验证指标体系.34 一、性能测试.34 1、四层吞吐性能测试.34 2、四层新建速率性能测试.35 3、四层并发性能测试.35 4、七层吞吐性能测试.36 5、七层新建事务速率性能测试.38 6、七层并发性能测试.40 二、基础功能测试.41 mNyQrMnPoOyQrOoQyRvNqN8OdN9PtRqQmOmOeRqRpNeRmOqPaQoOvNNZpMnQvPqMoR 2022 年数字时代应用可持续性架构与验证白皮书 2 1、网络端口聚合功能.41 2、基本负载均衡算法(IPv4/IPv6 双栈）.42 3、Virtual Server 功能.43 4、健康检查基本功能(IPv4/IPv6 双栈）.44 5、SNAT 池基本功能.45 6、Cookie 会话保持功能.46 7、HTTP header 会话保持功能.46 8、源地址插入和提取功能.47 9、连接镜像功能.48 10、服务器温暖上线.48 11、SSL 卸载功能.49 12、动态路由功能（IPv4/IPv6 双栈）.50 13、主备模式高可用功能.51 14、N+M 集群功能.52 三、超高可用架构场景测试.53 1、超高可用架构协同集成功能.53 2、Kubernetes 环境集成实现四层虚拟服务器自动创建.54 3、Kubernetes 环境集成实现七层虚拟服务器自动创建.54 4、Kubernetes 环境集成实现真实服务器自动扩容和缩减.55 5、集中管理平台统一纳管功能.55 6、TML-ADC/BIGIP 设备批量升级功能.56 7、TML-ADC/BIGIP 配置备份功能测试.57 8、NGINX/TML-ADC/BIGIP 日志管理功能.57 9、集中管理平台告警功能.58 四、管理功能测试.59 1、配置文件备份和恢复.59 2、数据统计和报表功能.59 3、网络管理扩展功能.60 4、运维管理工具.60 5、Syslog 功能.61 6、SNMP 与 NTP 功能.61 7、API 接口.62 8、Web/CLI/API 管理功能.62 第五章 展望.64 特别鸣谢.66 附录：应用可持续性架构测试示例.67 公司介绍/法律声明.79 版权声明.79 2022 年数字时代应用可持续性架构与验证白皮书 3 免责条款.79 合作说明.79 联系我们.79 微信公号.79 2022 年数字时代应用可持续性架构与验证白皮书 4 第一章 数字化时代的应用可持续性 一、应用可持续性概述 应用可持续是指企业利用 IT 资源，保障应用稳定运行，可持续地满足客户的需求与期望。应用可持续与高可用的联系与区别在于：高可用是应用可持续的必要非充分条件，而应用可持续不仅包括了基础设施侧的稳定性，还包括了用户侧的体验，是更为严苛的要求。应用可持续性仍然可以使用高可用的 SLI、SLO 和 SLA 等进行衡量，但 SLI 的具体指标可更宽泛。SLI（Service Level Indicator，服务水平指标），对于业务来说是最重要的指标，对于一般应用来说，是正常响应的百分比。SLO（Service Level Object，服务水平目标），是围绕 SLI 构建的目标。通常用 n 个 9 的百分比表示，并与一个时间范围挂钩，比如月度、季度、年度等。SLA（Service Level Agreement，服务水平协议）是企业围绕 SLO 发布的协议，它是要求在不满足 SLO 时向客户补偿的协议。需要强调的是，随着敏捷开发、CI/CD、DevOps 等理念的兴起与逐渐落地，应用可持续实际上需要在敏态中完成。比如，A/B 测试、灰度发布时，业务应是平滑的，客户是无感知的。应用可持续性架构，是指为了满足应用可持续，而采用的系统的、整体的 IT 架构，主要通过全生命周期健康检查与可观测、双活双轨、动态负载、主动韧性等手段，来摆脱对个别产品稳定性以及对个别运维人员的强依赖。应用可持续性架构，可以看作是软件工程 2022 年数字时代应用可持续性架构与验证白皮书 5 思想在 IT 运维领域的具体实践。应用可持续性架构验证，是指客户在选择应用可持续性架构及产品时，进行验证的方法论和具体指标。二、应用可持续性背景 1、中国数字经济迅速发展 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 年数字时代应用可持续性架构与验证白皮书 6 数字经济是当前经济发展的新动能，而数字基础设施是数字未来的坚实底座。截至 2022 年 6 月，我国累计建成开通 5G 基站达 185.4 万个；网络基础设施全面向 IPv6 演进升级，IPv6 地址数量为 63079 块/32，IPv6 活跃用户数达 6.83 亿；互联网宽带接入端口数量达 10.35 亿个，光缆线路总长度达 5791 万公里。数字基础设施建设实现跨越式发展。数字经济和数据量的快速增长，使得应用可持续性的重要性得到提升，原来作为辅助的数字世界和物理世界变得同样重要，而近几年的新冠疫情，使得数字的重要性进一步得到提升。另外，数字经济和数据量的快速增长，也使得应用可持续性面临前所未有的挑战：一方面原有的软硬件产品和架构难以承担数据量的爆炸式增长，而另一方面在老新迁移的过程中要求业务不能中断。2、产业数字化进入了深水区 产业数字化是在满足原有产业组成结构的前提下，传统产业通过数字技术进行升级改造或将数字技术应用至现有产业中，从而为产业带来产值增加和效率提升。近年来数字技术不断赋能传统行业产能增长，我国数字经济与实体经济融合发展也渐入佳境，作为推动数字经济发展的主动力，产业数字化在数字经济结构的比重连年上涨。根据中国数字经济发展白皮书（2022）数据，产业数字化较数字产业化始终占据绝对优势，2021 年产业数字化占数字经济比重达到 80.9%，同比增加 0.7 个百分点，较 2017年上涨 3.9 个百分点，我国产业数字化的转型持续往纵深发展。2022 年数字时代应用可持续性架构与验证白皮书 7 随着未来大数据、人工智能等新一代信息技术的发展，传统产业对数字化改造的需求日益增加，叠加新兴技术在各传统产业的批量应用，数字技术将与传统产业彼此融合，相互促进，进而持续推动实体经济转型升级，产业数字化在数字经济结构的比重有望继续上涨。产业数字化的主体是传统行业，相比于互联网等原生数字行业，IT 人员占比更少，技术水平更低。IT 也往往非其业务本身，而往往是保障性环节，因此，不可能无限制地增加开支。这些也都要求不能完全依赖于开发、运维人员本身的 IT 素养，而需要以更加健壮、简洁的架构，来保障应用的可持续性。三、应用可持续性价值 1、应用故障为企业带来直接经济损失 在数字化时代的今天，应用的稳定性和可持续性变得极为重要。早在 2018 年，保险公司劳合社与风险建模公司 AIR Worldwide 就联合发布了一份报告，预测了主要云服务器出现故障后可能带来的损失。报告表明，如果三大云供应商（Amazon，Google，Microsoft）发生一起 36 天的云故障，将导致 190 亿美元的损失。2021 年 10 月 4 日，Facebook 长达 6 小时的宕机，直接导致其股价暴跌 6%。2022 年数字时代应用可持续性架构与验证白皮书 8 除长时间宕机影响较大外，短时间的访问延迟，也会影响用户体验，并进一步带来经济损失。数据表明：74%的用户会离开 5 秒内未能打开的网站；86%的用户会卸载出现过3 次以上性能问题的应用。以上，还仅是在一般的社交、电商等领域，而在证券等领域，对延迟更为敏感，对可持续性要求更为严格。2、政务、金融领域的应用可持续性关系国计民生 随着数字化对人们生活的日益渗透，应用可持续性不仅在一般商业领域与经济效益直接相关，而且在公共服务领域关系国计民生。2021 年 12 月 20 日和 2022 年 1 月 4 日，西安一码通出现了两次崩溃，使得民众不得不挨个手动登记身份、重采核酸，带来很大的不便与混乱。与之类似，2022 年 9 月和 11 月，四川天府健康通也因为流量过大，出现部分用户暂时无法登录的现象。根据凤凰网信息，天津、杭州、哈尔滨、澳门等地也先后出现崩坏问题，这些，都暴露出系统架构不健壮的问题。2022 年数字时代应用可持续性架构与验证白皮书 9 公共服务，不同于电商等领域，不能单纯以 ROI 去衡量，去提供有损服务。未来，随着 5G、物联网在自动驾驶、远程医疗等领域的应用，应用的可持续性会更加重要，甚至关系到生命安全。2022 年数字时代应用可持续性架构与验证白皮书 10 第二章 应用可持续性挑战 不管是从经济效益、企业声誉，还是从社会价值来说，应用可持续性都极为重要，但是，应用可持续性的落地却并不容易，它要求从数据中心，到 IT 基础设施，再到容器、数据库等 PaaS 层，最后到应用，都可持续，而这一切，又是在用户数量、网络流量不断增加，应用复杂程度不断增加，IT 软硬件技术快速更新迭代的整体背景下。一、敏捷挑战 业务开发和运维支撑，本身需求就是天然相悖的。极端来说，研发部门想要：“随时随地发布新功能，没有任何阻拦”，而运维部门则想要：“一旦一个东西在生产环境中正常工作了，就不要再进行任何改动。”由于两个部门使用的语境不同，对风险的定义也不一致。在现实生活中，公司内部这两股力量只能用最传统的政治斗争方式来保障各自的利益。运维团队常常宣称，任何变更上线前必须经过由运维团队制定的流程，这有助于避免事故的发生。例如：运维团队会列出一个非常长的检查清单，历数所有以前曾经出现过的生产事故，要求研发团队在上线任何功能之前必须将所有这些事故模拟一遍，确保不会重现。这个清单通常没有任何标准，每项事故的可重现程度、问题价值并不一定是一致的。而开发团队吃过苦头之后也很快找到了自己的应对办法：开发团队宣称他们不再进行大规模的程序更新，而是逐渐转为功能开关调整、增量更新，以及补丁化。采用这些名词的唯一目的，就是为了绕过运维部门设立的各种流程，从而能更快地上线新功能。1 除以上人的因素外，软硬件的利旧和业务需求以及技术本身的飞速发展，也是一对稳与敏的矛盾。以银行业为例，国有银行和股份制银行普遍建设有动辄几十亿甚至上百亿的数据中心，并在软硬件资源上具有大量投资，它们不可能抛弃历史，直接做架构的硬切换，比如，即使不考虑安全、可控等要素，它们也不可能直接切换到公有云。与此同时，在互联网时代成长起来的客户，却迫使银行的业务侧增加了大量新的需求，比如小额支付、活动促销、秒杀等。在需求增加的同时，新技术也层出不穷，Docker 在 2013 年开源，Kubernetes 在 2014 年开源，而如今，它们已经是互联网领域的主流技术，另外，NGINX、Istio、Opentelemetry、Prometheus、Grafana、MongoDB、Redis、TiDB、OceanBase 等开源技术也不断降低开发运维难度、提升业务的敏捷性，并降低企业的运营成本。但是，这些新技术没有经历足够长时间的检验，并且个别点可能也不符合合规性要 1（美）BERSYBEYERCHIRISJONES（美）JENNIFERPETOFFNIALLRICHARDMURPHY 著；孙宇聪译.SRE Google 运维解密M.北京：电子工业出版社,2016.10.2022 年数字时代应用可持续性架构与验证白皮书 11 求。此时，银行便有了“既要跟上新技术，又要不直接放弃已有的数据中心和软硬件，还要稳定、合规，不出现闪失”的复杂性挑战。二、信创挑战 在业务需求和新技术均快速变化的同时，信创也为金融、能源等企业的 IT 系统引入了新的复杂性。信创，即信息技术应用创新，是我国企业为了应对国外技术限制（如美国“实体清单”）而自发组织的国产替代行为。我国的信创，大致可以分为四个阶段：第一阶段，大致为 1999-2010 年，当时仅可做到单品可用，以及面向特定场景，解决了有无的问题。第二阶段，大致为 2011-2013年，该阶段做到了系统可用和成体系试用，尤其是在办公自动化和经营管理类等系统中。第三阶段，大致为 2014-2017 年，当时叠加互联网企业的去 IOE 浪潮，开始向基础领域演进，此阶段实现了基本可用到好用。第四阶段，在 2018 年之后，在多场景中开始规模化应用。不过，在信创的高速发展中，仍面临着业务连续性、业务创新和安全防范的挑战。目前，在我国的诸多强 IT 依赖行业中，英特尔、英伟达、甲骨文、IBM、戴尔、威睿、红帽、SUSE、F5 等海外公司，各自在不同领域，为客户提供稳定的产品和优质的服务，而国内对应产品良莠不齐，平均水平跟这些公司还有一定差距。因此，我们应正视差距，并设立科学、严谨的验证标准：首先，在业务连续性方面，2022 年数字时代应用可持续性架构与验证白皮书 12 应设立各环节产品、服务的完整、科学的验证标准，在一个相对稳定的架构下先小规模试验、改进、扶持，动态调整信创业务比例，稳步扩大信创覆盖范围，面对业务不确定性，应可秒级恢复业务，并排除故障，找出故障原因。其次，在安全防护方面，面对黑客无差别攻击，需提高安全网关性能及可靠性，并采用异构能力，提高系统的对抗能力。再次，在业务创新方面，应积极地拥抱分布式、微服务等新兴架构以及开源生态，但又要通过镜像扫描、代码审计等，降低因开源带来的风险。三、疫情挑战 受疫情影响，IT 基础设施线下运维、巡检人员减少。疫情期间，为了避免聚集，运维领域出现了许多工作“新常态”，例如不少数据中心都采用 AB 岗轮班制、核心岗最小化办公或是工作方式转至“远距离、不接触”的线上办公模式，采取现场封闭办公、居家协同形式，到岗率从原先的 100%精简到 50%，甚至不到 10%。不少原来依赖于原厂运维或第三方运维的客户，为了避免人员的流动，降低人员感染风险，也在一定程度上失去外援，“孤军奋战”。而与此同时，互联网流量陡然增长。由于疫情反复无常，大众的办公、金融、医疗等生产、生活的各个方面，对线上、对网络的依赖程度明显增加，整个社会转入线上运行的趋势陡然加速，互联网流量也由此以倍数级大幅提升。根据国家发改委，2022 年 1-6 月我国移动互联网累计流量达 1241 亿 GB，较 2021 年 1-6 月的 1033 亿 GB 增长 208 亿GB，同比增长约 20.1%。线下运维、巡检人员的减少和互联网流量的陡然增长对服务器计算、存储和网络的水平扩展以及应用可持续性带来了新的需求与挑战。IT 基础设施管理人员对停电或极端天气事件等各种灾难有比较明确的应急预案，但前所未有的新冠疫情为数据中心等基础设施的部署和运维工作提出了更高的要求，诸多挑战“跃然纸上”，亟待解决。例如，如何确保系 2022 年数字时代应用可持续性架构与验证白皮书 13 统安全维护始终在线？当遇到大并发的外网访问时，如何对远程办公下的业务系统应用做好统一监控？当出现高流量访问引发系统卡顿和事件告警时，如何在海量数据中快速查找问题原因，保障运维效率？等等。2022 年数字时代应用可持续性架构与验证白皮书 14 第三章 应用可持续性架构设计思想与特征 一、应用可持续性架构设计思想 应用可持续主要由三个方面构成：控制和调度面的可持续，一般对应 Mater-Slave 或Controller-Worker 架构中的 Master 或者 Controller；执行面的可持续，一般对应上述架构中的 Slave 或者 Worker；数据面的可持续，一般利用共享且本身冗余的持久化存储（如 etcd、Redis）来实现。1、抽象与分层 完整的业务应用需求传递链条为：用户/客户公司业务侧公司业务开发侧运维侧，在单体架构以及瀑布流式开发中，这种需求的变动，缺乏在任何一层“消化”掉的能力，而是一传到底，因此，业务之敏和基础设施之稳成为矛盾。而从另一个视角来看，当把业务看作稳态时（假定业务需求一成不变），基础设施侧也并不能保证一成不变，数据中心需要扩容，存储、计算、网络设备需要淘汰和更新换代。在早期，往往通过深夜停服等方式来进行，但随着人们对 IT 依赖程度的逐渐加深，这种方式可行性越来越低，基础设施之敏和业务之稳也成为矛盾。也就是，链条的两侧，其实均不关心对方具体发生了哪些变化，只关心给自己带来了什么变化，并希望自己可自由变化。此时，便需要一个中间层，来将双方的变化相互“翻译”。这种“翻译”的过程就是抽象的过程，而中间层诞生，就是分层。在 IT 架构中，负载均衡、容器编排、数据中台等，都是这种抽象与分层而产生的中间层，只是应用的场景不同。2、不同层解耦 当中间层一旦产生，中间层的上下便会变得简单而自由起来。所有共性的东西，每个节点一律不再关心，因为中间平台层已经实现；与上下其他 N 多节点之间的对接，每个节点也不再关心，因为中间平台层已完成“翻译”和对接，原来复杂的乘积关系变成了只与中间层对接的加和关系。2022 年数字时代应用可持续性架构与验证白皮书 15 这一相对统一的中间层，由于作用如此重要，因此往往成为业界事实上的标准，也往往成为“兵家”必争之地，Kubernetes、Marathon（Mesos）、Swarm 之争便是如此。一旦其中一种真正胜出，标准便相对统一起来，上下层短时间之内会出现大繁荣。平台意义的中间层，被取代相对缓慢，即使在日新月异的 IT 界也是如此，这也就让稳态和敏态的结合有了抓手。当然，在实际中，往往存在多个类似意义的中间层，比如在应用可持续中，应用交付网络/负载均衡可以看作第一个中间层，其可一部分流量分给传统虚机，另一部分流量分给容器云，而在容器云中 Kubernetes/Openshift 又可作为第二个中间层。3、同层节点冗余、替换、水平扩展与异构 一旦实现了抽象与分层、不同层解耦，那么中间层也就成为了 IT 架构的核心，只要它是相对稳定的，上下层的变化便可在该层“消化”掉，也即上层的变化不影响下层，下层的变化也不影响上层，这是稳态与敏态能够统一起来，也是应用可持续性的关键所在。上下层的节点作用被降低，平行节点间可冗余、可替换、可水平扩展、可异构：冗余：设置两个或更多相同功能的同类节点，这里的节点可以是数据中心（如同城双数据中心，异地双数据中心），也可以是分区（例如最保守的做法是在早期，让整个信创区完成与非信创区完全相同的功能，也即不让其单独承担实际职责）。冗余是保证高可用与应用可持续较为稳妥的方式，但如果在多层上冗余，则实际上往往有 4 个、8 个甚至更多副本，成本较高。2022 年数字时代应用可持续性架构与验证白皮书 16 替换：因为中间层是稳定层，因此上下层的任何一个单一节点、甚至一块区域都不再不可或缺，而变成了可以热拔插的组件，但需要节点将健康状态上报（对应健康监测和可观测），一旦出现故障，立即切换到其他节点。动态负载即是通过这种方式实现。水平扩展：当将故障节点的任务动态切换到健康节点，有可能对健康节点造成负载冲击，此时，必须可以迅速补充新节点。水平扩展属于自动化运维范畴，在不同层级往往有不同手段：例如物理机可使用 Cobbler 基于 DHCP 服务器和 PXE 环境迅速安装操作系统，远程启动等；虚拟机可以使用 Ansible 进行自动化管理；而容器云则可以直接使用Kubernetes 进行 Node 中 Pod 的扩展以及 Pod 中容器的扩展。异构：平行节点间也不再追求统一。架构本身不仅兼容异构，因为当某种攻击只针对其中一种软硬件产品时，异构类型便可幸免于难，成为“有生力量”，并担起应用可持续的 2022 年数字时代应用可持续性架构与验证白皮书 17 重任。这种包容异构的特点，其实为平滑迁移奠定了基础，不管是从传统虚机向容器云和微服务，还是从非信创向信创，迁移的过程，必然是异构状态。其实，蓝绿发布、灰度发布、A/B 测试等，均是利用的节点间可自由替换的特性实现的，只不过其往往是以相同的基础设施节点来运行不同的应用（版本），而上云、信创替代，则可用不同的基础设施来运行相同的应用。4、中间层和核心节点的稳定性保障 在以上架构中，有一个显而易见的问题是，并没有考虑中间层和核心节点出现故障的情况，如果 DNS 解析节点、核心负载均衡器、容器编排平台等出现故障。核心节点或核心中间层的可用性一般通过以下手段进行保障。（1）节点本身稳定 生产系统中的核心节点一般采用成熟、稳定、久经考验的产品和技术，并且版本升级策略一般也相对保守。例如：硬件方面，成熟的 SLB、ADC 设备均具有非常强的稳定性与可靠性。软件方面：Kubernetes 在 2016 年便有大量企业进行尝试，但真正将其布到生产系统中则大多发生在 2019 年前后；NGINX，从其诞生到在各企业中广泛应用，经历了十几年时间，而为了保证稳定性，其支持 HTTP3 协议的 NGINX-QUIC 很长时间单独存在，直到现在仍未合并到 NGINX 主干中。（2）轻负载，只做核心任务 由于核心节点具有全局性意义，其稳定的性能往往比丰富的功能更加重要，因此，普遍的一种做法是只让其承担调度和控制层面的事项，并不承担具体的工作任务。例如，四层负载，只负责流量转发，TCP 的三次握手等直接分发到七层负载或应用节点。再比如，在不少银行中，SSL 卸载不再放入负载均衡设备中，而是前后各一层负载均衡，中间一层SSL 卸载，构成三明治结构。还比如，在早期的服务网格 MOSN 中，让 Sidecar 承担更多负载，而减少对中心节点的依赖。2022 年数字时代应用可持续性架构与验证白皮书 18（3）冗余 冗余，即主从架构。对于核心节点，比如负载均衡设备，一般均采用冗余的方式，来保障系统的高可用。负载设备本身之间的冗余可用 VIP 地址漂移来实现，也即只有一台物理设备来占用 IP，当该物理设备出现故障，IP 漂移到其他健康物理设备。（4）产生新主节点 产生新主节点，即集群架构。如果主节点并非采用专用设备，那么在主节点出现故障时，自动根据算法将某子节点提升为主节点，这也是严格意义上的分布式。目前，这种方式在大数据领域以及区块链领域应用更为广泛。相比于主从架构，集群架构是严格意义上的分布式架构。5、持久化存储且共享 节点的配置和服务发现数据通过高性能 Key-Value 内存数据库进行存储，并持久化到硬盘中，数据间通过 Raft 协议保持强一致性的共享。在控制节点，可使用 etcd；而在执行节点，可使用 Redis。通过以上几步，节点的网络可以通过 VIP 漂移或者上层负载/编排平台的控制切换到其他节点，节点的任务可以通过本来的冗余或快速启动实例切换到其他节点，节点的数据因落到了共享的持久化存储中，也可被其他节点无缝继承。系统的健壮性和应用的可持续性，不再依赖于任何单一节点自身的可靠性。二、应用可持续性架构特征 1、跨域协同与平滑迁移（1）跨域双活双轨 数据中心双活架构：双活，是一种节约资源的计算机灾备方案。其实现模式是让主备两个数据中心都同时承担用户的业务，此时，主备两个数据中心互为备份，并且进行实时备份。一般来说，主数据中心的负载可能会多一些，比如分担 6070%的业务，备数据中心只分担 40%30%的业务，保证了当其中一边发生故障时，不至于造成业务无法处理的情况。与双活近似的是热备份和冷备份。热备份：备用数据中心对主数据中心实时备份，但不承担业务，当主数据中心业务中断时，自动切换到备用数据中心，是一种高可用但浪费资源的备份方式。冷备份：备用数据中心不对主数据中心实时备份，只定期备份，当主数据中心业务中断，人工切换到备用数据中心，是一种非高可用的备份方式。2022 年数字时代应用可持续性架构与验证白皮书 19 双活数据中心要做到网络双活、应用双活和数据双活。金融等行业，为了追求更高的可用性，且考虑成本，一般在双活之外再加灾备数据中心（俗称“两个半数据中心”）。信创区和传统区双轨架构：利用和数据中心双活类似的原理，在同一数据中心中的信创区和传统区（非信创区）等不同模块之间实现热备或双活的方案，即为双轨运行。双轨架构相比于数据中心双活实现上更为复杂，这是因为双活数据中心，只是物理距离较远，但网络、计算、存储设备一般较为统一，所以组网相对容易，而双轨相当于异生态组网，需要更全面的软硬件生态屏蔽底层的异构和复杂。2022 年数字时代应用可持续性架构与验证白皮书 20 交叉双活双轨架构：同时实现数据中心双活，以及信创区和非信创区双轨的架构，一般由多层负载设备和更复杂的软硬件生态来实现。（2）双轨平滑迁移 双轨是指信创区和非信创区同时运行，具体有以下几种模式/步骤：完全复制：信创区对非信创区的流量完全复制，进行“陪跑”，类似于数据中心的热备 2022 年数字时代应用可持续性架构与验证白皮书 21 份。主要用于初期，对于某类型信创设备稳定性信任度较差的阶段。缺点是成本较高，造成大量的资源浪费。并且，这种方式，因为用户侧应用的响应其实还是完全依赖于非信创区，因此不便于将应用侧及信创区设备侧的指标做关联性分析。流量分担：通过加权轮询等方式，赋予信创区较少权重，让其承担少部分业务负载。相比于流量完全复制，其实际承担了部分业务负载，降低了部分成本。故障秒切：通过健康检查，当信创区出现业务故障，秒级切换回传统区，保障业务的可持续性。然后，根据健康检查参数和日志等，找出故障原因，进行恢复。2022 年数字时代应用可持续性架构与验证白皮书 22 平滑过渡：随着信创区稳定性逐步提高，其负载权重也逐步上升，直至占据大部分，甚至全部。协议互通：除了执行节点由传统区逐步过渡到信创区之外，控制/调度节点也应该平滑过渡，这就要求信创的调度、控制节点（负载均衡/应用交付）应与既有设备在协议上保持互通，可直接读取数据。体验一致：除底层协议之外，用户体验层也仍应关注，控制节点的操作体验应尽量与原有设备一致，从而使得客户/用户学习成本最低，迁移平滑。双轨平滑迁移的方式，在早期增大了基础平台层的适配工作量，但将应用和基础设施 2022 年数字时代应用可持续性架构与验证白皮书 23 完全解耦，使得行业客户在迁移时不再拘泥于“一个应用一个应用迁移”这种单一形式，将大幅降低迁移难度，提升迁移进度，并保障了迁移过程中的稳定性。2、多协议支持 应用可持续性，需要在不同层级支持多种主流协议，具体包括：（1）网络层（三层）协议 IPv4：互联网通信协议第 4 版（Internet Protocol version 4），是该协议第一个被广泛部署的版本。IPv4 是互联网的核心，也是目前使用最广泛的互联网通信协议版本。IPv6：互联网通信协议第 6 版（Internet Protocol version 6），是互联网工程任务组（IETF）设计的用于替代 IPv4 的下一代 IP 协议，其地址数量号称可以为全世界的每一粒沙子编上一个地址。IPv6 可避免必须经过多层路由和分发才能到达终端设备，是物联网快速发展的基础保障之一。（2）传输层（四层）协议 UDP：Internet 协议集的无连接的传输协议，该协议称为用户数据报协议（User Datagram Protocol）。UDP 为应用程序提供了一种无需建立连接就可以发送封装的 IP 数据包的方法。HTTP3/QUIC 协议，其传输层即是采用了 UDP 协议，避免了 TCP 协议头部拥塞问题。TCP：Internet 协议集的面向连接的、可靠的、基于字节流的传输协议，该协议称为传输控制协议（Transmission Control Protocol）。TCP 由 IETF 的 RFC 793 定义。TCP协议在应用层有着极为广泛的应用，HTTP1、HTTP2、FTP、SMTP、POP3 等，传输层均采用 TCP 协议。Fast TCP：TCP 协议的优化分为单边优化和双边优化，而单边优化又可以分为基于丢包的优化和基于时延的优化。Fast TCP 即属于基于时延的优化，与之类似的，还有Compound TCP。Fast TCP 对 TCP 协议的改善主要是在其流量控制方面作了优化：不修改 TCP 协议内包头(TCP Packet Header)的标准格式，只对 TCP 包头里的 Sequence Number,Window Scaling 等数值作修改，并且优化了流量控制的算法，大大提高了 TCP流量的效率，从而提高了广域网带宽的利用率。Fast TCP 对广域网和无线数据网络上的TCP 流量有显著的优化效果,特别在高时延，高丢包率的 TCP 网络环境里，可以减少应用的响应时延，提高 TCP 吞吐量和有效流量的速度，提高无线网络和广域网带宽的利用率。2022 年数字时代应用可持续性架构与验证白皮书 24（3）会话层（五层）协议 RPC：远程过程调用协议（Remote Procedure Call）是一个用于建立适当框架的协议。从本质上讲，它使一台机器上的程序能够调用另一台机器上的子程序，而不会意识到它是远程的。RPC 是一种软件通信协议，一个程序可以用来向位于网络上另一台计算机的程序请求服务，而不必了解网络的细节。RPC 被用来像本地系统一样调用远程系统上的其他进程。过程调用有时也被称为函数调用或子程序调用。（4）应用层（七层）协议 HTTP1.1：超文本传输协议-版本 1.1（Hypertext Transfer Protocol Version 1.1）。相比于 1.0 版本，它增加了长连接，也即在连接后并不立即中断 TCP 连接，之后一定时间之内的 HTTP 请求仍然可以复用 TCP 连接，这就避免了多次连接（尤其是 TCP 连接存在多次握手）的问题。在时间上来看，HTTP1.0 诞生（1996 年）不久之后的 1999 年即诞生，至今仍为全部浏览器及基于 HTTP 协议的应用支持（即使支持 HTTP3 的应用，因普及率问题，在首次请求中也使用 1.1，在响应头中给出自己支持 HTTP3 的说明，以便浏览器等在下次请求时直接使用）。HTTP2:超文本传输协议-版本 2.0（Hypertext Transfer Protocol Version 2.0）。HTTP2 标准于 2015 年 5 月以 RFC 7540 正式发表。相比于 HTTP1.1，主要有如下改进：（1）不再使用文本协议而使用二进制协议传输数据，解析效率更高。（2）多路复用，即多个 HTTP 请求可直接使用同一个 HTTP。如果说 HTTP1.1 实现了在时间的纵向上实现了TCP 连接的复用（长连接），那么 HTTP2.0 就是在同一时间节点的横向上实现了 TCP 连接的复用。（3）头部压缩，在客户端和服务器端使用“首部表”来跟踪和存储之前发送的键值对，对于相同的数据，不再通过每次请求和响应发送。HTTP3：超文本传输协议-版本 3.0（Hypertext Transfer Protocol Version 3.0）。HTTP3 起源于谷歌，原名为 HTTP over QUIC，而 QUIC 意为 QUICk UDP Internet Connections，可见其传输层不再基于 TCP，而是基于 UDP。在前文四层协议部分我们已知，UDP 为无连接直接传输的协议，其可靠性较差，于是 HTTP3 的 QUIC 层对 UDP 进行了大量改进，加入了 TCP-like 可靠特性，并提供与 TLS/SSL 相当的安全性。HTTP3 在经历了长达 6 年，34 个 Draft 版本后，最终在 2022 年 6 月以 RFC9114 发表。由于其终稿确定时间较晚，且牵涉传输层变化，因此当前不少路由和七层负载均衡设备还未能完全支持，但不少互联网厂商在其后期的 Draft 版本时就已经在做自己的开源实现。HTTP3 相比与 HTTP2 有诸多改进，其中比较重要的有：（1）因使用 UDP，彻底解决了 TCP 的头部阻塞问题。（2）不再使用四元组（源 IP、源端口、目的 IP、目的端口）来标识一条连接，2022 年数字时代应用可持续性架构与验证白皮书 25 而使用 Connection ID，也就是其长连接更加稳定，不受用户侧网络环境以及基础设施侧Pod 的变化影响，这在 5G、自动驾驶等频繁更换 IP 甚至网络环境的场景中将发挥重要作用。（3）TLS 单次握手，时延更短。2022 年数字时代应用可持续性架构与验证白皮书 26 FastHTTP：FastHTTP 是 基于 Go 语言 的一款不同于标准库 net/http 的 HTTP 实现，可实现服务器/客户端每秒处理上千个中小型请求，并且要求一致的毫秒级响应时间。3、与现代高可用架构无缝对接 我们可把 IT 架构分为四个阶段：第一个阶段为小型机，其特点是单点高可用，但设备昂贵、封闭，扩展能力有限。第二阶段为硬负载设备+X86 服务器，其特点是依赖硬负载，实现了单服务器节点的容错，通过冗余保障了高可用，同时扩展方便，但负载本身定制性较差。第三阶段为以 NGINX、LVS、HAProxy 为代表的软负载+物理机/虚机，特点是开源、定制性强。第四阶段是以 Kubernetes 为代表的云原生架构，其内部负载一般采用Kubernetes 原生功能，或使用 NGINX、Traefik、Envoy 等。其中，第三和第四阶段，因为符合软件定义基础设施的特点，均可视为现代架构。但在金融等行业中，存在大量的 IT历史包袱，四个阶段的架构和产品均在使用，因此，应用交付系统必须既能利旧，又能面向未来。具体的，应在纵向上，同时跨以下几个环节，实现对接：（1）全局负载均衡（GSLB）为了解决多区域数据中心流量分配而设置的负载均衡，一般有两种实现方式：基于DNS 和基于 HTTP(S)，其中后者主要解决 DNS 逐级递归解析过程中的劫持问题。（2）四层负载均衡 也被称为网络负载均衡，仅用于对 TCP、UDP 流量进行处理。四层负载均衡在转发中主要基于 IP 地址、端口等信息。四层负载均衡的开源软件包括 LVS、DPVS 等。NGINX和 HA