互联网多活技术架构及运维
211245008_多活数据中心分布式云网络架构设计与实践
智能运维AIOps832023 . 05 中国金融电脑本栏目由新华三技术有限公司独家冠名近年来，伴随云计算技术的快速发展和成熟，邮储银行积极推进私有云建设，并以此为基础，进一步搭建了可高效支持敏捷开发与快速上线的高可靠、高性能基础平台。
与此同时，随着多地多数据中心布局的稳步推进，为更好满足不同应用、数据库的分布式部署需求，邮储银行云平台建设也逐步开始向同城多活、异地灾备的分布式云方向演变。
一、多中心分布式云网络需求分析1.同城双中心是一个整体双活架构在架构方面，分布式云网络基于跨数据中心（DC）的二层互联网络，支持将同一个云区域（Region）部署于同城数据中心之间，并使用虚拟扩展局域网（VXLAN）技术实现端到端二层互通，进而形成低时延、大带宽的同城互联网络，以更好满足云管理需求、业务同城备份需求和主从Region 仲裁节点的较低时延需求。
2.同城中心之间提供双活出口在部署方面，主Region 管理面跨可用分区（AZ）同时部署于同城DC1与同城DC2。
在此模式下，针对多活数据中心分布式云网络架构设计与实践摘 要：面向数字化发展浪潮，邮储银行积极构建跨中心分布式架构体系，并成功搭建了同城双活、异地灾备的分布式云网络。
本文结合邮储银行实践，细化阐述了分布式云网络实现跨数据中心统一管理、同城数据中心双活出口控制、跨中心流量控制等功能的设计思路，并总结了实施层面的技术要点。
关键词：分布式；云计算；数据中心；可用分区中国邮政储蓄银行数据中心 黄海 林介渺 张治铧 郑立坤分布式云网络内的故障AZ 切换场景，以及DC1出口故障时保持对外管理地址不变等需求，同城DC 互联网络可对外提供双活接入，即确保DC1出口入云或DC2出口入云的效果一致，并全面覆盖云内切换及云外切换等多种场景的网络需求。
3.多中心之间大流量数据同步在传输方面，多中心布局在同城之间需要进行实时数据同步，异地之间则是进行异步数据同步（通常由广域网承载）。
F5双活数据中心解决方案
F5双活数据中心解决方案F5双活数据中心解决方案：提升业务连续性，降低运营成本随着企业业务的快速发展和信息技术的不断进步，数据中心已经成为企业运营的重要支柱。
然而，传统的数据中心架构往往面临着一系列挑战，如数据处理能力不足、资源利用率不高等。
为了解决这些问题，F5公司推出了一款双活数据中心解决方案，旨在提高业务连续性、降低运营成本，并为企业的数字化转型提供强有力的支持。
一、解决方案F5双活数据中心解决方案旨在提高数据处理能力、充分利用资源、降低成本，同时确保业务的高可用性和容错能力。
该方案采用了先进的技术，包括数据分流、资源调度等，以实现两个数据中心之间的协同工作。
在实际应用中，该方案可有效提高客户端性能、降低运营成本，并确保业务的高可用性。
二、技术原理F5双活数据中心解决方案基于负载均衡和流量管理技术，通过将流量分流至不同的数据中心，实现负载均衡和容错能力。
同时，该方案还采用了资源调度的技术，根据不同的业务需求和资源使用情况，动态地分配计算和存储资源，以提高资源利用率并降低成本。
三、实际应用某大型电商企业采用了F5双活数据中心解决方案，实现了两个数据中心的协同工作。
通过数据分流和资源调度，该企业的客户端性能提高了30%，运营成本降低了25%，同时业务的高可用性也得到了有效保障。
在遭遇故障或攻击时，该方案能够迅速将流量切换到另一个数据中心，确保业务的连续性和稳定性。
四、未来展望随着云计算和大数据技术的快速发展，双活数据中心解决方案将迎来更为广阔的应用前景。
未来，双活数据中心将更加注重智能化管理和自适应调节，以满足不断变化的业务需求。
同时，随着5G等新技术的普及，双活数据中心将在移动领域发挥更大的作用，为移动应用提供更稳定、更高效的支持。
五、结论F5双活数据中心解决方案为企业的业务连续性和数字化转型提供了强有力的支持。
通过提高数据处理能力、充分利用资源、降低成本，该方案能够有效应对各种挑战，推动企业的业务发展。
互联网公司的组织架构与管理模式
互联网公司的组织架构与管理模式随着互联网的迅速发展，互联网公司成为了现代商业领域中的重要一员。
互联网公司的组织架构和管理模式对于公司的运营和发展具有至关重要的影响。
本文将探讨互联网公司的组织架构和管理模式，并分析其优势和挑战。
一、组织架构互联网公司的组织架构通常分为多个部门，每个部门负责不同的职能。
以下是一个常见的互联网公司的组织架构示例：1. 高层管理层：包括董事会和执行团队，负责公司整体战略规划和决策。
2. 技术部门：负责公司产品的研发和技术支持，包括软件开发、测试和运维等工作。
3. 市场营销部门：负责市场推广、品牌建设和用户增长等工作。
4. 销售部门：负责产品销售和客户关系管理，与客户进行业务洽谈和合作。
5. 运营部门：负责公司的日常运营，包括人力资源管理、财务管理和行政事务等。
互联网公司的组织架构通常比较扁平化，强调团队协作和快速决策。
相比传统企业的层级结构，互联网公司更加注重创新和灵活性。
二、管理模式互联网公司的管理模式有其独特之处，以下是一些常见的互联网公司管理模式：1. 自我管理：互联网公司鼓励员工自主管理和自我驱动。
员工有更大的自由度来选择工作方式和解决问题。
2. 扁平化管理：互联网公司的组织结构通常相对扁平，减少层级，加快决策和执行的效率。
3. 开放沟通：互联网公司倡导开放和透明的沟通文化，鼓励员工提出意见和建议，并及时给予反馈。
4. 创新激励机制：互联网公司注重激励员工的创新和积极性，通过奖励和股权激励等方式激发员工的工作动力。
5. 灵活工作制度：互联网公司通常实行灵活的工作制度，如弹性工作时间、远程办公等，提升员工的工作生活平衡。
三、优势与挑战互联网公司的组织架构和管理模式带来了许多优势，同时也面临一些挑战。
1. 优势：a) 敏捷决策：扁平化的组织结构使得决策更加敏捷和迅速。
b) 创新能力：鼓励员工创新的管理模式促进了公司的创新能力。
c) 灵活性：灵活的工作制度提高了员工的满意度和工作效率。
云计算运维运营体系
云计算运维运营体系云计算是指通过网络来提供计算资源和服务的一种技术，它具有灵活性、可扩展性和低成本等特点，因此在近年来得到了广泛的应用和发展。
云计算运维运营体系是指在云计算环境下的运维和运营工作所建立的一套体系和规范，旨在保证云计算服务的稳定性和高效性。
1.云计算架构管理：云计算架构管理是指对云计算环境下的各种资源进行管理和规划。
包括对云计算平台的部署和维护、资源的分配和调度、网络的配置和管理等。
2.云计算安全管理：云计算安全管理是指对云计算环境下的安全问题进行管理和保护。
包括对用户数据的加密和隔离、网络的防护和监控、虚拟机的安全管理等。
3.云计算性能管理：云计算性能管理是指对云计算环境下的性能问题进行监控和调优。
包括对云计算平台的负载均衡、资源的动态调整、存储和网络的优化等。
4.云计算服务管理：云计算服务管理是指对云计算服务进行管理和监控。
包括对云计算服务的标准化和规范化、用户需求的分析和调研、服务质量的监控和评估等。
5.云计算容灾备份：云计算容灾备份是指对云计算环境下的数据进行备份和恢复，以保证服务的可用性和可靠性。
包括对数据的定期备份、容灾方案的制定和实施、灾难恢复能力的测试等。
云计算运维运营体系的建立和实施有助于提高云计算环境下的运维效率和服务质量。
首先，通过云计算架构管理的规划和管理，可以使得资源的利用率得到最大化，提高用户的满意度。
其次，通过云计算安全管理的监控和保护，可以减少安全事件的发生，保护用户的数据安全。
再次，通过云计算性能管理的优化和调整，可以提高系统的响应速度和性能稳定性。
最后，通过云计算服务管理的规范和标准化，可以提供高质量的服务，并通过服务质量的监控和评估，不断进行改进和优化。
需要指出的是，云计算运维运营体系的建立和实施是一个复杂的过程，需要集成多种技术和工具，并且需要针对具体的业务场景进行定制和调整。
同时，云计算运维运营体系的建立需要具备相关的专业知识和经验，因此组建一支专业的云计算运维团队非常重要。
互联网公司的组织架构和企业文化
互联网公司的组织架构和企业文化随着互联网的快速发展，互联网公司成为了当今社会中最具活力和创新力的企业之一。
互联网公司的成功离不开其独特的组织架构和企业文化。
本文将探讨互联网公司的组织架构和企业文化对其发展的重要性，并分析一些成功的互联网公司的案例。
一、组织架构互联网公司的组织架构通常以扁平化为主要特点。
相比传统企业的层级结构，互联网公司更注重快速决策和高效沟通。
在互联网公司中，常见的组织架构包括以下几个部分：1. 高层管理团队：互联网公司的高层管理团队通常由创始人、CEO和其他高级管理人员组成。
他们负责制定公司的战略方向和决策，并对公司的整体运营负责。
2. 产品部门：产品部门是互联网公司中最重要的部门之一。
产品经理负责产品的规划和设计，工程师负责产品的开发和测试。
产品部门与其他部门密切合作，确保产品的顺利上线和运营。
3. 技术部门：技术部门是互联网公司的核心部门之一。
技术团队负责开发和维护公司的技术平台，确保系统的稳定性和安全性。
技术部门通常由架构师、工程师和运维人员组成。
4. 运营部门：运营部门负责公司的日常运营和市场推广。
运营团队通过各种渠道获取用户，并与用户保持良好的沟通和关系维护。
运营部门与产品部门和技术部门密切合作，共同推动公司的发展。
5. 设计部门：设计部门负责公司的视觉设计和用户体验。
设计师通过创造性的设计和用户研究，提高产品的用户友好性和美观度。
设计部门与产品部门和技术部门密切合作，共同打造出优秀的产品。
二、企业文化互联网公司的企业文化是其成功的重要因素之一。
互联网公司的企业文化通常具有以下几个特点：1. 创新和开放：互联网公司鼓励员工提出新的想法和创新，倡导开放的工作环境和沟通方式。
员工可以自由地表达自己的观点，并参与到公司的决策和项目中。
2. 平等和合作：互联网公司强调平等和合作的价值观。
公司内部没有明确的等级制度，员工之间可以平等地交流和合作。
团队合作是互联网公司成功的关键。
云计算运维详述
云计算运维详述随着科技的飞速发展，云计算已经成为了当今企业进行IT建设的核心方式。
云计算能够为企业提供灵活、高效的IT资源，帮助企业更好地开展业务。
然而，如何有效地管理和维护这些云计算资源，确保其稳定运行，成为了云计算应用中的重要一环。
这就是我们今天要详细讨论的云计算运维。
一、云计算运维的定义云计算运维是指在云环境中，对各种软硬件资源进行规划、配置、优化和管理，以确保其稳定运行的过程。
这个过程需要运维团队对云计算环境进行监控、故障排除、系统升级、性能优化等工作，以确保云服务的连续性和稳定性。
二、云计算运维的主要任务1、资源管理：对云计算环境中的各种资源进行统一管理，包括计算、存储、网络等资源。
对资源的分配和调度进行优化，提高资源利用率。
2、故障排除：当云计算环境中出现故障时，运维团队需要及时发现并排除故障，确保业务的连续性。
3、系统升级：随着业务需求的变化和技术的发展，云计算系统需要进行升级和更新。
运维团队需要负责系统的升级和补丁更新，确保系统的安全性和稳定性。
4、性能优化：通过对云计算系统进行性能监控和优化，可以提高系统的运行效率，降低成本。
5、安全保障：保障云计算环境的安全性是运维的重要任务之一。
运维团队需要制定并实施安全策略，防止黑客攻击和数据泄露等安全问题。
三、云计算运维的优势1、降低成本：通过集中管理和优化资源配置，云计算运维可以降低企业的IT成本。
2、提高效率：云计算运维可以快速地部署和扩展资源，提高企业的业务响应速度。
3、增强安全性：通过统一管理和安全策略的实施，云计算运维可以增强企业的安全性。
四、总结云计算运维是确保云计算系统稳定运行的重要环节。
通过资源管理、故障排除、系统升级、性能优化和安全保障等措施，可以有效地管理和维护云计算环境，确保其稳定运行，为企业提供高效、安全的IT 服务。
随着云计算技术的不断发展，云计算运维也将面临更多的挑战和机遇。
云计算运维管理随着科技的快速发展，云计算已成为企业和组织中的重要技术，为其提供了一种更高效、更灵活和更具成本效益的IT解决方案。
安全运维服务方案
安全运维服务方案安全运维服务方案一、方案背景近年来，随着信息化进程的加速和互联网的发展，网络安全成为了越来越重要的话题。
各种恶意软件、网络攻击、数据泄露等安全问题频繁爆发，给企业生产、经营和安全带来了很大的风险。
为了保障企业信息系统安全和平稳运行，提供符合业务需求的安全运维服务是企业不可或缺的重要需求。
二、方案目标本方案主要针对企业信息系统安全运维服务需求进行分析和解决，旨在提供一套高效、可靠的安全运维方案，以确保企业信息系统的高可用性、高性能、高安全性、高稳定性和高可靠性。
具体目标如下：1、确保企业信息系统高可用性：采用负载均衡、高可用集群、多活数据中心等技术手段，实现信息系统的高可用性，并根据集群节点及应用状态进行自动动态管理和调度，确保用户的业务可用性。
2、提供高性能的信息系统资源：通过多维度的性能监测，包括服务器、网络、存储等方面，对信息系统的资源进行实时监测和优化，从而提高性能和可靠性，同时满足企业大数据计算的需求。
3、提升安全管控能力：采用特定的安全事件管理系统，对企业的信息系统进行安全事件监测和记录，为业务系统提供完整的安全管控功能，实现信息系统实时监控、预警提示和处理应急事件的能力。
4、保障信息系统稳定性：通过灵活的运维管理和及时的故障响应机制，为企业信息系统提供快速响应和故障处理的能力，同时通过有效的备份、容错、恢复等手段，实现信息系统的稳定性和安全性。
5、提高运维效率：通过标准化化的运维管理流程和工具自动化程度，使运维管理更为高效、实时、准确，并可以通过建立自动化工单流程和知识库，提高运维人员的工作效率和管理能力。
三、方案内容1、负载均衡与高可用集群为了确保信息系统的业务可用性，本方案提供负载均衡技术与高可用集群技术的支持：1.1、负载均衡技术：将客户请求分发到多个服务器上，防止单点故障，并根据不同的请求进行负载调度。
本方案将提供多种负载均衡产品选择，如F5、LVS等。
1.2、高可用集群技术：通过实现数据、应用、网络等多层次集群，提高系统可用性，并能实现快速故障转移和灵活扩容。
云平台运维与运营服务方案
云平台运维与运营服务方案一、需求分析随着云计算技术的飞速发展，越来越多的企业开始将自己的业务迁移到云平台上，以提高运行效率和灵活性。
然而，在云平台的运维与运营方面，很多企业面临着各种挑战，包括系统稳定性、数据安全性、性能优化等问题。
因此，为了帮助企业克服这些挑战，本文将提出一个云平台运维与运营服务方案。
二、方案介绍1.云平台运维服务（1）系统监控与运维：提供全天候的系统监控服务，及时发现并解决运行故障和性能问题，确保系统的稳定运行。
（2）安全管理：建立完善的安全策略和体系，包括数据加密、身份认证、访问控制等，确保云平台的数据和用户的隐私安全。
（3）容灾备份：建立高可用性的架构，实现故障自动切换和数据备份，确保业务的连续性和数据的可恢复性。
（4）性能优化：对云平台的硬件和软件进行性能监测和调整，优化系统的响应速度和资源利用率，提升用户体验。
2.云平台运营服务（2）数据分析与优化：通过对用户数据的收集和分析，了解用户需求和行为习惯，优化产品的功能和用户体验，提高用户留存率和转化率。
（3）市场推广：制定云平台的市场推广策略，包括广告投放、社交媒体营销、合作伙伴推广等，扩大用户规模和品牌影响力。
（4）合规管理：根据当地的法律法规和行业标准，制定合规管理措施，确保云平台的合法合规运营。
三、服务流程1.服务准备阶段（1）需求收集与分析：与客户充分沟通，了解其云平台运维与运营的需求和目标，并进行详细分析和规划。
（2）解决方案设计：根据客户需求，制定相应的云平台运维与运营解决方案，并进行技术评估和成本估算。
（3）合同签订：与客户签订服务合同，明确双方的权利和义务，保证服务的可持续性和稳定性。
2.服务执行阶段（1）基础设施建设：根据解决方案，进行云平台的基础设施建设，包括服务器架设、网络配置、安全控制等。
（2）系统配置与部署：根据客户需求，配置并部署相关系统和应用程序，确保云平台的正常运行。
（3）数据迁移和备份：将客户的数据迁移到云平台上，并进行定期备份，以防止数据丢失和风险。
多活切换时长标准-概述说明以及解释
多活切换时长标准-概述说明以及解释1.引言1.1 概述多活切换是指在系统或网络环境中，当主要的活动节点或服务器遇到故障或不可用时，能够快速无缝地切换到备用节点或服务器进行继续工作或服务的一种技术手段。
多活切换的目的是为了提高系统的可用性和容错性，减少因单点故障导致的业务中断或数据丢失。
在现代IT系统中，多活切换已经成为了一种十分重要的技术需求。
随着大型系统和网络的复杂性不断增加，单节点的故障或不可用性往往会给整个系统带来巨大影响。
通过实现多活切换，系统能够在主节点故障时自动地将工作负载转移到备用节点上，从而实现业务的连续性和数据的可靠性。
多活切换时长标准是为了确保系统在切换过程中能够在合理的时间内完成切换并继续提供服务。
这一标准的制定是基于对业务需求、系统性能和切换过程的全面考虑。
标准的制定应该综合考虑切换所需的时间、数据同步的延迟、用户体验的影响等因素，以便提供一个合理的切换时长限制。
多活切换时长标准的意义在于为系统设计和运维提供一个规范和参考。
合理的时长标准可以引导系统设计者在系统架构和应用部署上做出适当的决策，以确保在切换时能够在可接受的时间范围内完成，避免过长的切换时间给用户带来不便或影响系统的正常运行。
因此，制定多活切换时长标准是为了提高系统的可用性和可靠性，确保系统在切换过程中能够快速、安全地完成切换，并为系统设计和运维提供一个参考指导。
随着技术的不断发展和应用需求的变化，多活切换时长标准也需要不断调整和改进，以适应不同系统和应用场景的需求。
1.2 文章结构本文主要分为三个部分：引言、正文和结论。
在引言部分，我们将对多活切换时长标准进行概述，介绍文章的结构以及阐明研究的目的。
这一部分的目的是引起读者对多活切换时长标准的重要性和意义的关注，同时也帮助读者了解本文的主要内容和框架。
接下来，在正文部分，我们将从三个方面探讨多活切换时长标准的问题。
首先，我们将对多活切换的定义进行解释和阐述，明确其指的是什么。
腾讯TBase运维平台架构详解
每 个 节 点 独 立 机 架 ，独 立 供 电
机器类型
物 理 机 ，如 果 只 能 CVM, 则 需要控制节点不要存放于 同一台母机上
网络要求
双网卡高可用bond
单中心部署规范
E tc d L e a d er C e n ter S l a ve Confdb Slave
机器 1
01
02
性能指标参考
配置
3 2 Core
128G
2TSSD
机器数 200
节点数 1000
存储周期 3个月
多可用区统一入口部署
广州机房
可用区一
广州机房
可用区二
广州机房
可用区...
谢谢！
20
异地双活四中心部署规范
南生产中心
机 器1：ConfdbMaster+EtcdNode+CenterSlave 机 器2：Confdb Slave + Etcd Leader + Center Master 北中 心机器 5：Etcd Node
北同城中心
机器 3：Confdb Slave + Etcd Node + Center S lave 机器 4：Confdb Slave + Etcd Node + Center Slave
可用性及性能
一主多从，故障时自动选主，访问到 备时自动转发，支持高并发，低延迟
故障管理
crontab定时脚本监控拉起，告警
部署要求
2个以上，对于生产系统建议3节点， 与etcd共用机器部署
扩展性
可扩容，也可以缩容
承担功能
运营平台大脑，接收运维指令，派发 任务给Agent,调度任务
云计算平台的架构与运维技巧
云计算平台的架构与运维技巧云计算平台架构的意图是提供高效的资源管理和灵活的服务交付模型。
在云计算平台的架构设计中，需要考虑到以下几个关键方面：可扩展性、高可用性、安全性和成本效益。
本文将介绍云计算平台的主要架构组件和运维技巧。
一、云计算平台架构的主要组件1. 虚拟化技术虚拟化技术是云计算平台的基础，它通过将物理资源（如服务器、存储和网络设备）抽象为虚拟资源，提供了弹性和资源共享的能力。
常用的虚拟化技术包括服务器虚拟化（如VMware和KVM）、存储虚拟化（如Ceph和GlusterFS）和网络虚拟化（如Open vSwitch和OpenFlow）等。
2. 分布式存储系统分布式存储系统用于存储和管理云平台中的大量数据。
它能提供高可用性、持久性和可扩展性。
常用的分布式存储系统包括Hadoop分布式文件系统（HDFS）、分布式块存储系统（如Ceph和GlusterFS）以及对象存储系统（如OpenStack Swift和Ceph Rados）等。
3. 负载均衡技术负载均衡技术用于分发用户请求到多个服务器上，实现资源的均衡利用和高可用性。
常用的负载均衡技术包括硬件负载均衡器（如F5Big-IP和Cisco ACE）和软件负载均衡器（如Nginx和HAProxy）等。
4. 容器化技术容器化技术是一种轻量级的虚拟化技术，它可以在操作系统级别实现资源的隔离和管理。
常用的容器化技术包括Docker和Kubernetes等。
二、云计算平台的运维技巧1. 自动化运维自动化运维是提高云平台运维效率的重要手段。
通过使用自动化工具和脚本，可以实现自动化的资源调度、故障排查和配置管理等操作，减少人工操作的工作量。
2. 监控与告警监控是保障云平台正常运行的关键环节。
运维人员应该建立完善的监控系统，实时监测云平台各个组件的运行状态和资源利用情况，并设置合理的告警规则，及时发现和解决问题。
3. 弹性伸缩云平台的弹性伸缩能力是应对高峰时段访问量增加和资源需求变化的重要手段。
阿里云云原生异地多活解决方案
降本增效
有效分摊各个数据中心 成本，实现成本小于 200%冗余
用户自行实施异地多活的难点
流量管理难度高
✓ 需要对接入层、服务层、数据层等的流量规则进行 统一管理。
✓ 在分发规则时，需要保障众多节点规则的一致性。 ✓ 需要具备多维的分流能力，和动态调配能力。
数据同步策略复杂
?数据库冗余4份数据主库备库主库备库容灾能力计划外切换?支持az级故障rto分钟级rpo0dts双向同步?region级故障rto分钟级rpo0多活中不同的服务类型单元化服务中心化服务普通服务中心单元中心单元中心单元单元化服务单元化服务中心化服务中心化服务普通服务普通服务读写读写读写读写读写读写db双向同步dbdb单向同步dbdb双向同步db?多活主要面向的服务类型?数据有强中心要求通常提供全局业?不做任何改造的服务就近访问本地?单元内封闭调用不依赖其他单元务服务?能容忍同步延迟写入后往往不需要?非本单元的流量纠错到对端单元?仅中心提供服务各单元读写请求均立即读取路由到中心?主要面向读服务不建议写场景使用?单元数据仅提供灾备服务缺少单元写保护跨云数据同步copy类型非多活类型应对中心化服务和普通服务数据单向同步单元只可读不可写?同步任务配置使用白名单ddl放行方式?跨城同步异步复制unit类型适配单元化服务和普通服务数据双向同步各单元均可读写?防循环机制通过事务表threadid方式实现?通过全局sequence避免冲突防循环sequence防循环sequence事务表方式
同城容灾/双活
用户
随机访问
随机访问
同城数据中 心A
读写
同城数据中 心B
读写
优势： • 部署简单，接入成本低 • 灾备环境可用性强，数据质量有保障 缺点： • 仅提供同城保护，容灾等级低
新一代“两地三中心” 多活系统规划设计
新一代“两地三中心” 多活系统规划设计作者：张晓丹来源：《中国金融电脑》 2016年第1期2000 年开始，我国商业银行IT 系统大多经历了从分散数据中心到集中式数据中心的第一阶段建设，在享受数据集中带来的管理和运维收益的同时，各银行也意识到数据集中带来的业务连续性问题，因此，开启了以同城或异地灾备系统为核心内容的第二阶段建设。
近年来，随着互联网的崛起，以阿里、腾讯、百度等为代表的互联网公司在广泛使用开源技术的基础上，建设了高效、灵活的全新的IT 系统架构，以及同城多活、异地多活的数据中心架构。
互联网浪潮中云计算、分布式、多活等技术潮流也在冲击着银行IT 系统的建设思路。
恒丰银行作为12 家全国性股份制商业银行之一，近年来在盈利能力和资产质量实现跨越式发展的同时，在IT 系统建设方面明确了科技引领、跨越式发展的战略方向，学习和吸收互联网和开源技术思路，以服务水平管理为目标，完成了新一代“两地三中心”多活系统规划设计和建设，以期全面提升IT 系统连续性和可用性水平，为全行业务快速创新发展提供有力支撑。
本文就恒丰银行“两地三中心”多活系统建设的策略和方案进行介绍。
一、基于IT 成本控制和服务水平管理的规划设计策略在进行“两地三中心”架构规划设计之前，恒丰银行组织业内专家进行了充分的分析讨论。
分析、明确了影响“两地三中心”设计的主要问题，包括连续性、可用性、安全性、容量性能、建设和运维成本等，以及传统数据复制技术和应用多活设计局限性等。
恒丰银行明确IT 财务成本控制和IT 服务水平管理为新一代“两地三中心”多活系统规划设计总体目标和指导原则。
通过对IT 基础设施的服务对象——银行应用系统进行服务水平（连续性、可用性、容量、服务时间等）分级管理，在产品技术选型和规划设计方案的源头，为不同级别应用配备不同可靠性的产品设备、不同标准的冗余备份设计，不同比例的多中心容量配置，以及不同级别的自动化运维设计，以控制IT 基础设施建设成本和运维成本。
中国移动数据中心SDN网络架构及关键技术
中国移动数据中心SDN网络架构及关键技术随着云计算和大数据的快速发展，中国移动数据中心的规模和复杂性也在迅速增加。
为了应对这一挑战，SDN（软件定义网络）技术被引入到数据中心网络中。
本文将探讨中国移动数据中心SDN网络的架构和关键技术。
一、SDN网络架构概述SDN是一种网络架构和技术，通过将网络控制平面与数据平面分离，实现对网络资源的灵活管理和配置。
在中国移动数据中心，SDN网络架构采用了集中式的控制器和分布式的交换机结构。
1. 控制器SDN网络的控制器是整个网络的大脑，负责集中管理和控制网络中的交换机。
在中国移动数据中心，SDN控制器可以根据实际需求来调整网络的流量分配和路径选择，从而提高网络的灵活性和性能。
2. 交换机SDN网络中的交换机负责实际转发数据包。
在中国移动数据中心，交换机被部署在各个服务器和设备之间，通过与控制器的交互，来接收并执行网络策略和配置。
二、SDN网络关键技术1. OpenFlow协议OpenFlow是SDN网络的一种重要协议，用于控制器和交换机之间的通信。
在中国移动数据中心中，使用OpenFlow协议可以实现网络的灵活性和可编程性，同时减少了对交换机的修改和配置。
2. 虚拟化技术在中国移动数据中心的SDN网络中，虚拟化技术起到了至关重要的作用。
通过将物理网络资源划分为多个虚拟网络，可以实现对网络的动态分配和管理。
这种虚拟化技术可以提高数据中心的资源利用率和性能。
3. 多路径技术为了提高中国移动数据中心SDN网络的可靠性和性能，多路径技术被引入到SDN网络中。
通过使用多条路径来传输数据，可以有效地避免网络拥堵和故障，提高网络的吞吐量和可用性。
4. 安全性技术中国移动数据中心SDN网络中的安全性是一个重要的考虑因素。
为了保护网络免受恶意攻击和入侵，采用了各种安全性技术，如访问控制、加密和入侵检测等。
这些安全性技术可以有效地保护数据中心的网络安全。
5. 动态网络管理技术中国移动数据中心的SDN网络需要具备动态管理和配置的能力。
算网融合发展，运力承载筑基
37Internet Technology互联网+技术一、算力网络发展现状2022年全国两会召开后，建设数字信息基础设施成为强烈政策信号。
《政府工作报告》中提到，建设数字信息基础设施，围绕国家重大战略部署和“十四五”规划，适度超前开展基础设施投资。
2月底，国家发展改革委等多部门联合印发通知，启动建设全国一体化算力网络国家枢纽节点，“东数西算”工程正式启动。
同时，算力网络作为重要的信息基础设施有望迎来加速跑，如何加快推动算力网络创新发展也成了热议的话题。
算力即计算能力，是通过对信息数据进行处理实现目标结果输出的计算能力。
在不同的场景下，算力可以用不同单位来衡量。
例如，在加密数字货币场景下，算力的衡量单位是每秒哈希运算次数（Hash/s）；在AI 和图像处理等场景下，算力的衡量单位是每秒浮点运算次数（FLOP/s）。
算力网络是应对算网融合发展趋势提出的新型网络架构，以算为中心、网为根基，网、云、数、智、安、边、端、算网融合发展，运力承载筑基算力路由协议技术要求、交易平台技术要求、管理与编排要求等标准的研究[1]。
图1为中国移动算力感知网络参考架构。
基于网络无处不在的算力资源，算力平台层完成对算力资源的控制和管理，并通知算力路由层，综合考虑网络状况后，将服务应用调度到合适的节点，以实现资源利用率最优。
然而，当前传统网络结构在向算力网络演进过程中，仍存在许多不足。
在算力方面，由于平台过于集中、时延难以进一步优化，算力类型单一、无法满足新型业务模型需求，云边协同的统一调度能力依然为技术难点等问题；在网络方面，有应用层和网络层解耦、应用感知能力弱，网络资源利用不充分、不均衡，网络内化经济模型缺失等问题。
二、算力网络发展需求全新的信息化场景对算力网络提出了更高的要求。
（一）激增的网络计算能力需求AI 模型训练、高性能计算、多源数据一体化分析等大量计算需求融入业务中，对网络计算能力需求增大。
摘要：2021年，国家发展改革委等四部委联合发布了《全国一体化大数据中心协同创新体系算力枢纽实施方案》，明确提出在多个地区布局全国算力网络国家枢纽节点，启动实施“东数西算”工程，构建国家算力网络体系，算力和网络融合发展已成为重点关注方向。
ai数字化中台技术架构方案
业务流程管理与优化措施
采用业务流程管理工具，实现业 务流程的可视化和可配置化。
对业务流程进行持续优化，提高 业务处理效率。
通过数据分析和挖掘，发现业务 流程中的瓶颈和问题，为优化提
供数据支持。
05
技术中台建设方案
技术选型及原因阐述
选用先进的大数据技术
01
如Hadoop、Spark等，处理海量数据，满足实时性和扩展性需
对系统的响应时间、吞吐量、并发用户数等关键性能指标 进行测试，确保系统能够满足业务需求。
安全测试
对系统的安全性进行全面测试，包括身份认证、访问控制 、数据加密等方面，确保系统的安全性和稳定性。
验收标准
制定明确的验收标准和流程，包括功能验收、性能验收、 安全验收等方面，确保系统能够满足业务需求并顺利上线 。
数据治理与安全保障措施
数据治理策略制定
制定完善的数据治理策略，包括 数据标准制定、数据质量监控、 数据安全管理等，确保数据的规
范性、准确性和安全性。
数据安全保障措施
采用多种数据安全保障措施，如数 据加密、访问控制、安全审计等， 确保数据不被泄露、篡改或损坏。
数据合规性审查
定期进行数据合规性审查，确保企 业数据处理活动符合法律法规和监 管要求。
通过引入AI技术，构建智能化中台，实 现业务、数据和技术的全面融合。
提升运营效率
借助中台的共享服务和标准化流程，降 低企业运营成本，提高运营效率。
加速创新迭代
通过中台提供的灵活可扩展的技术架构 ，支持企业快速响应市场变化，加速产 品和服务创新迭代。
增强企业竞争力
通过数字化转型和中台战略实施，提升 企业整体竞争力，实现可持续发展。
07
系统集成与测试方案
IT网络运维工程师应具备的知识体系图谱
对象存储 - GlusterFS、MooseFS、Ceph、FastDFS（非对象存储）
DAL
数据访问层
应用层分片、淘宝TDDL、开源：360（Atlas）、阿里（Cobar）、MyCat、MySQL-Proxy、根据业务开发
数据库服务
数据存储
分布式缓存
Memcached、Redis（客户端分片、Redis Cluster、Twemproxy、Codis）
运维相关
项目管理（Redmine、Jira、知识库、Bugzilla、CodeReview）、工单系统、运维操作平台、监控平台
应用相关
持续集成、日志收集平台（ELKStack）、自动化部署平台、Job管理（调度）平台、安全扫描平台
系统相关
LDAP、内部DNS、DHCP、Mail、SMS、Gitlab、Yum仓库、操作审计（xenapp）、堡垒机
IDC托管
需求分析、IDC选型、网络测试、谈价格、签合同、设备采购（原厂vs渠道）、机柜和机位规划
运维产品化
基于DevOps产品思路
项目管理（类似Jira）、Bug管理、代码托管（类似Gitlab）、持续交付（类似Jenkins的构建、测试、部署）
监控平台、看板
软件定义数据中心
DevOps产品
自动化运维产品思路
容器层
容器编排
Mesos（Marathon、Chronos）、Kubernetes（SKYDNS）、Docker Swarm、CoreOS（fleet）、OpenStack（Magnum）
Docker Stats
cAdvisor
DataDog
Zabbix
Docker Swarm
Mesos
运维工作中如何提高灵活性
运维工作中如何提高灵活性在当今数字化的时代，运维工作扮演着至关重要的角色。
它确保了系统的稳定运行，为业务的顺利开展提供了坚实的支撑。
然而，随着技术的快速发展和业务需求的不断变化，运维工作面临着越来越多的挑战。
在这种情况下，提高运维工作的灵活性变得尤为重要。
一、深入理解业务需求要提高运维工作的灵活性，首先需要深入了解业务需求。
运维人员不能仅仅局限于技术层面的操作，而要对业务的流程、目标和关键指标有清晰的认识。
只有这样，在面对突发情况或业务调整时，才能迅速做出准确的判断和决策。
例如，一家电商公司在促销活动期间，流量会大幅增加。
如果运维人员不了解促销活动的时间、规模和预期的流量峰值，就无法提前做好服务器资源的扩充和优化，可能导致网站崩溃，影响用户体验和业务收入。
为了更好地理解业务需求，运维人员应该与业务部门保持密切的沟通。
参加业务会议，了解业务规划和发展方向；与业务人员建立良好的合作关系，及时获取业务变化的信息。
同时，通过对业务数据的分析，挖掘潜在的需求和问题，为运维工作提供前瞻性的指导。
二、建立灵活的技术架构一个灵活的技术架构是提高运维灵活性的基础。
传统的僵化架构往往难以适应快速变化的业务需求，而采用云计算、微服务、容器化等新兴技术，可以大大提高系统的弹性和可扩展性。
云计算平台提供了按需分配资源的能力，运维人员可以根据业务的实际负载，快速调整服务器的配置和数量。
微服务架构将复杂的应用拆分成多个独立的服务，每个服务可以独立部署和扩展，降低了系统的耦合性，提高了运维的灵活性。
容器化技术则实现了应用的快速部署和迁移，使得运维工作更加高效便捷。
此外，建立自动化的部署和管理工具也是必不可少的。
通过脚本和工具实现服务器的配置、应用的部署和监控的自动化，可以大大减少人工操作的时间和错误，提高运维效率，同时也为快速响应业务变化提供了技术支持。
三、强化监控和预警机制实时有效的监控和预警是运维工作中提高灵活性的关键环节。
单体应用高可用方案
单体应用高可用方案单体应用高可用方案是指采取一系列技术手段和管理策略，确保单体应用在面对各种意外事件和故障时能够保持高可用性和稳定运行的能力。
在当今互联网应用的开发和运维中，单体应用的高可用性显得尤为重要，因为一旦单体应用出现故障或不可用，将对业务造成严重影响，甚至导致财务损失。
设计和实施一套高可用方案对于保障单体应用的稳定性和可靠性至关重要。
一、架构设计1. 异地多活架构采用异地多活架构是实现单体应用高可用性的重要手段。
通过在不同地理位置部署多个运行环境，保证即使某一地区出现故障，其他地区可以继续提供服务。
在异地多活架构中，需要考虑数据同步、负载均衡、故障切换等方面的技术实现。
2. 容灾备份建立完善的容灾备份机制，包括数据备份、应用程序备份以及灾备运行环境的建设。
定期进行数据备份，并在备份数据中心部署应急运行环境，以应对主数据中心出现故障时的快速切换和恢复。
3. 弹性伸缩利用云计算等技术实现单体应用的弹性伸缩，根据业务负载的变化自动扩充或减少运行资源，确保在高峰时段能够满足用户需求，而在低谷时期也能够降低成本。
二、故障监控与自动化运维1. 监控报警建立全面的监控体系，监控单体应用的关键性能指标、运行状态和业务流程。
一旦发现异常，及时通过报警系统通知相关运维人员，以便及时采取措施进行故障排查和处理。
2. 自动化运维通过自动化运维工具和技术，实现对单体应用的自动化部署、配置管理、故障恢复等运维工作。
使用DevOps工具进行持续集成、持续部署，实现快速迭代和自动化测试，提高运维效率和反应速度。
三、负载均衡与容错机制1. 负载均衡采用负载均衡技术，将用户请求均匀分发到不同的服务器上，避免单一服务器负载过重，提高系统整体的稳定性和可用性。
2. 容错机制在单体应用中引入容错机制，比如断路器、限流等，防止某一部分故障导致整个系统崩溃，提高系统的鲁棒性和稳定性。
四、安全防护与灰度发布1. 安全防护加强对单体应用的安全防护，包括DDoS防护、漏洞扫描修复、安全审计等措施，确保单体应用在面对网络攻击和数据泄露时能够有效防范和应对。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
互联网多活技术架构及运维饿了么多活系统架构饿了么业务快速发展，给技术带来了海量请求和高并发、微服务的挑战，同时开发团队快节奏的版本迭代和服务快速上线的要求也驱动运维团队提供稳定、高效的运维服务。
我是饿了么的技术运营负责人，见证了饿了么业务的飞速发展。
记得2015 年加入饿了么的时候，我们的日订单量只有30 万笔；而到了2017 年，我们的日订单量已经超过1000 万笔。
考虑到我们在整个市场的体量和单个机房至多只能处理2000 万笔订单的上限，我们逐步推进了面向百分之百冗余多活的新规划。
今天的分享主要分为三个部分：•多活场景及业务形态•饿了么多活运维挑战•饿了么运营体系探索多活场景及业务形态饿了么多活的现状首先介绍一下饿了么整个多活的现状：我们在北京和上海共有两个机房提供生产服务。
机房和ezone 是两个不同的概念，一个机房可以扩展多个ezone，目前是一对一关系。
我们还有两个部署在公有云的接入点，作为全国流量请求入口。
它们分别受理南北方的部分流量请求，接入点都部署在阿里云上面，同时从运维容灾角度出发。
我们考虑到两个云入口同时“宕掉”的可能性，正在筹建IDC 内的备用接入点，作为灾备的方案。
多活从2017 年 5 月份的第一次演练成功到现在，我们经历过16 次整体性的多活切换。
这16 次切换既包含正常的演练，也包含由于发生故障而进行的真实切换。
其中，最近的一次切换是因为我们上海机房的公网出口发生了故障，我们将其所有流量都切换到了北京。
实现多活的背景下面我从五方面介绍实施多活之前的一些背景状况：•业务特点•技术复杂•运维兜底•故障频发•机房容量业务特点：我们有三大流量入口，分别是用户端、商户端以及骑手端。
一个典型的下单流程是：用户打开App 产生一个订单，店家在商户端进行接单，然后生成一个物流派送服务的运单。
而该流程与传统电商订单的区别在于：如果在商城生成一个订单，后台商户端可以到第二天才收到，这种延时并无大碍。
但是对于饿了么就不行，外卖的时效性要求很高，如果在10 分钟之内商户还未接单的话，用户要么会去投诉，要么可能就会取消订单，更换美团、百度外卖，从而会造成用户的流失。
另外，我们也有很强的地域性。
比如说在上海生成的订单，一般只适用于上海本地区，而不会需要送到其他地方。
同时，我们的业务也有着明显的峰值，上午的高峰，一般在11 点；而下午则会是在5 点到 6 点之间。
我们通过整个监控曲线便可对全链路的请求一目了然。
这就是我们公司乃至整个外卖行业的业务特点。
技术复杂：上图是流量请求从进入到底层的整个技术架构。
SOA（面向服务的体系结构）系统架构本身并不复杂，其实大部分互联网公司的技术架构演进到最后都是类似的。
我们真正的复杂之处在于：各种组件、基础设施以及整个的接入层存在多语言的问题。
在2015 年之前，我们的前端是用PHP 写的，而后端则是Python 写的。
在经历了两年的演进之后，我们现在已把所有由PHP 语言写的部分都替换掉了。
而为了适用多种语言，我们的组件不得不为某一种语言多做一次适配。
比如说：我们要跟踪（trace）整个链路，而且用到了多种语言，那么我们就要为之研发出多种SDK，并需要花大量的成本去维护这些SDK。
可见，复杂性往往不在于我们有多少组件，而是我们要为每一种组件所提供的维护上。
我们当前的整个SOA 框架体系主要面向两种语言：Python 和Java，逐渐改造成更多地面向Java。
中间的API Everything 包含了许多为不同的应用场景而开发的各种API 项目。
而我们基础设施方面，主要包括了整个存储与缓存，以及公有云和私有云。
运维兜底：在业务飞速发展的过程当中，我们的运维团队做得更多的还是“兜底”工作。
最新的统计，我们现在有将近16000 台服务器、1600 个应用、1000 名开发人员、4 个物理IDC、以及部署了防护层的两朵云。
也有一些非常小的第三方云服务平台，包括AWS 和阿里聚石塔等。
在业务增长过程当中，基于整个IDC 的基础设施环境，我们对交付的机型统一定制，并且改进了采购的供应链，包括：标准化的整机柜交付和数据清洗等。
对于应用使用的数据库与缓存，我们也做了大量的资源拆分与改造工作，比如数据库，改造关键路径隔离，垂直拆分，sharding，SQL 审核，接入数据库中间件dal，对缓存redis 使用治理，迁移自研的redis cluster 代理corvus，联合框架实现存储使用的规范化，服务化。
曾经面临比较大的挑战是数据库DDL，表设计在每家公司都有一些自己的特点，例如阿里、百度他们每周DDL 次数很少。
但是我们每周则会有将近三位数的DDL 变更，这和项目文化以及业务交付有关。
DBA 团队以及DAL 团队为此做了几件事情：表数据量红线，基于Gh-OST 改进online schema change 工具，Edb 自助发布。
这样大大减少了数据库DDL 事故率以及变更效率。
在多活改造过程中，工具的研发速度相对落后，我们在运维部署服务，组件的推广和治理过程中，大部分都还是人工推广、治理。
我们还负责全网的稳定性，以及故障管理，包括预案演练、故障发现、应急响应、事故复盘等，以及对事故定损定级。
故障管理并不是为了追责，而是通过记录去分析每一次故障发生的原因，以及跟进改进措施，避免故障再次发生。
我们还定义了一个全网稳定性计数器，记录未发生重大事故的累计时间，当故障定级应达到P2 以上时清零重新开始。
历史上我们保持最长的全网稳定性纪录是135 天，而美团已经超过了180 天，还有一些差距。
故障频发：根据上图“故障频发”所反映的数据，大家可以看到，2015 年和2016 年的数据惨不忍睹。
按天计算，我们经常会出现P2 级别以上的事故，最短的是隔 1 天就出现 1 个P2 以上事故。
我们不得不进行改进，于是我们组建了一个叫NOC（Notification Operation Center）的团队。
这个是参照Google SRE 所建立的负责7*24 应急响应团队，以及初步原因判断，执行常规的演练，组织复盘，跟进复盘改进落地情况。
NOC 定义公司通用故障定级定损/定责的标准：P0—P5 的事故等级，其参照的标准来自于业务特性的四个维度，它们分别是：•在高峰期/非高峰期的严重影响，包括受损时间段和受损时长。
•对全网业务订单的损失比。
•损失金额。
•舆情的影响。
包括与美团、百度外卖、其他平台的竞争。
不过区别于外卖食材的本身品质，我们这里讨论的是技术上的故障。
比如商家无缘无故取消了客户的订单，或是由于其他各种原因导致客户在微博、或向客服部门投诉的数量上升。
上述这些不同的维度，结合高峰期与低峰期的不同，都是我们定级的标准。
根据各种事故运营定级/定责的规范，我们建立了响应的排障SOP（标准操作流程），进而我们用报表来进行统计。
除了故障的次数之外，MTTR（平均恢复时间）也是一个重要的指标。
通过响应的SOP，我们可以去分析某次故障的本身原因，是因为发现的时间较长，还是响应的时间较长，亦或排障的时间比较长。
通过落地的标准化流程，并且根据报表中的MTTR，我们就可以分析出在发生故障之后，到底是哪个环节花费了较长的时间。
提到“故障频发”，我们认为所有的故障，包括组件上的故障和底层服务器的故障，都会最终反映到业务曲线之上。
因此我们NOC 办公室有一个大屏幕来显示重要业务曲线，当曲线的走势发生异常的时候，我们就能及时响应通知到对应的人员。
在订单的高峰期，我们更讲求时效性。
即发生了故障之后，我们要做的第一件事，或者说我们的目标是快速地止损，而不是去花时间定位问题。
这就是我们去实现多活的目的，而多活正是为我们的兜底工作进行“续命”。
原来我只有一个机房，如果该机房的设施发生了故障，而正值业务高峰期的时候，后果是不堪设想的。
机房容量：我们再来看看整个机房的容量，在2015 年之前，当时订单量很少，我们的服务器散落在机房里，机型也比较随意。
而到了2015 年，我们大概有了1500 台服务器；在2016 年间，我们增长到了6000 台；2017 年，我们则拥有将近16000 台。
这些还不包括在云上的ECS 数量。
有过IDC 相关工作经历的同学可能都知道：对于大型公司的交付，往往都是以模块签的合同。
但初期我们并不知道业务发展会这么快，服务器是和其他公司公用模块和机架，服务器也是老旧而且非标准化，同时组网的环境也非常复杂。
甚至有一段时期，我们就算有钱去购买服务器，机房里也没有扩容的空间。
为什么要做多活为什么要做多活，总结一下有四个方面：容灾续命、服务扩展、单机房容量、和其他的一些原因。
如上图右侧所示，我们通过一个类似X/Y 轴的曲线进行评估。
随着业务规模的增长，技术投入，服务扩展，故障损失已不是一种并行增长的关系了。
饿了么多活运维挑战下面分享一下我们当时做了哪些运维的规划，主要分为五个部分：•多活技术架构•IDC 规划•SOA 服务改造•数据库改造•容灾保障多活技术架构我们通过设置既可把昆山划分到上海，又可以划到苏州（这与行政区无关、仅关系到外卖的递送半径）。
因此我们提出了地理围栏的概念，研发了GZS 组件。
我们把全国省市在GZS（globalzone service）服务上区分地理围栏，将全国分成了32 个Shard，来自每个Shard 的请求进入系统之后，通过GZS 判断请求应该路由到所属的机房。
如图最下方所示，对于一些有强一致性需求的数据要求，我们提出了Global zone 的概念。
属于Global zone 的数据库，写操作仅限于在一个机房，读的操作可以在不同zone 内的local slave 上。
多活技术架构五大核心组件：•API Router：流量入口API Router，这是我们的第一个核心的组件，提供请求代理及路由功能。
•GZS：管理地理围栏数据及Shard 分配规则。
•DRC：DRC（Data replication center）数据库跨机房同步工具，同时支持数据变更订阅，用于缓存同步。
•SOA proxy：多活非多活之间调用。
•DAL：原本是数据库中间件，为了防止数据被路由到错误的机房，造成数据不一致的情况，多活项目中配合做了一些改造。
整个多活技术架构的核心目标在于：始终保证在一个机房内完成整个订单的流程。
为了实现这个目标，研发了 5 大功能组件，还调研识别有着强一致性的数据需求，一起从整体上做了规划和改造。
IDC 规划在2016 年底启动多活项目，确定了南北两个机房，以及流量入口，开始进行IDC 选型，实地考察了几家上海的IDC 公司，最终选择了万国数据机房。
同时结合做抗100% 流量服务器预算、提交采购部门采购需求。
规划多活联调测试环境，模拟生产双ezone、划分vpc，以及最后的业务同期改造。