手机网站
手机网站
本文主要分为五个部分
整个平台建设的里程碑，有助于大家对建设过程有全面的认识
总体设计目标，说明我们的总体设计思路
关键技术实现方案主要是关键组件的切换方式
平台建设完成后的收益状况
未来陆金所许多活机房建设的长期规划。
一、里程碑介绍
2012年陆金所开始对外服务，经历了前后约7次的机房搬迁，到2017年底，陆金所真正完成了该城的共活基础设施建设。 2018年初，我们改造了整个网站结构。 2018年2月，陆金所真正以双重生活的形式对外提供相关服务。
为了应对未来的双重生活、多元化的运营场景以及相关课题，我们开始了在平台之间切换的建设。 整个平台建设周期约为3个月，基于陆金所自行研究的DevOps流水线和自动运输技术系统。 2018年6月，第一期平台功能开发和在线工作完成，2018年7月，通过非核心业务、霸权套件的5%相关组件的切换场景，验证了整个切换平台。
从那以后，我们每月都有一次定期的切换训练过程，从非核心、非重要的业务开始，慢慢训练所有的组件和服务。 半年来，陆金站进行了6次较大的切换，2018年12月，陆金站正式完成了复盖所有服务的切换验证，12月底，通过切换平台，陆金站完成了第一次主机房的正式切换，总体上需要4分38秒的时间，值得期待 但是，由于我们也发现了一些问题，2019年3月，我们在此基础上重复版本，将整体时间从4分38秒缩短到4分5秒。
二、总体设计目标
接下来介绍陆金所的总体设计目标。
众所周知陆金所现在的技术框架大部分是在云计算、集装箱、微服务等技术环境中进行的。 因此，数据中心复用和双工的核心问题是解决状态服务的高可用性管理。 陆金所称有状态服务的机房为主房，与之相对应的不是有主服务的机房而是子房。
因此，在平台切换初期，对于平台的使用场景和建设目标，在主机室发生大面积服务故障时，可以通过切换平台，在5分钟内切换主机室内各组件和服务的主要角色，实现迅速的故障
陆金所是一个庞大的系统，至今已有1400多个子应用程序、120个DB实例、300个大网关、3000个作业调度、非自主研究、不能进行非采购双重活动的主备份系统、基于状态的核心组件，例如分布式 根据这样巨大的应用系统，想在5分钟内完成主机房全部组件的角色切换，难度很明显。
我们用以下八个词来解决这些问题。 又大又小，分开放置。 我们的总体目标是在5分钟内完成整个机房服务的角色转换，这一大目标可以分解为一些重要的核心指标:时效性、独立性、壮健性和数据闭环。 然后逐步分解这些关键指标，派遣需要服务切换的团队进行相应的指标达成率细分设计、反复优化和改进，通过小演习、大演习、小切换和大切换方式反复优化实现整体平台设计目标
三、关键技术实现方案
下面是一些具体的实现技术方案。 我提取一些代表性的核心组件。
GTM用户引流方案，GTM是一个基于F5设备的互联网域名管理平台，我们基于此解决方案进行二次封装和开发，开发基于互联网用户流量的白屏化工具，并
许多人可能不知道大网关是什么，但这其实是互联网金融的核心特征，陆金所作为拥有许多金融品种的在线资产管理平台，本身就有许多外部服务的对接需求，所以内部应用当然是外部服务 在陆金所的内部运营系统中，我们将这些链接资源与大网关统一。
在大网关的情况下，由于陆金所本身存在金融行业属性，有严格的监管合规要求和自我安全需求，因此无论是接入互联网，还是通过合作伙伴专线接入合作伙伴服务，都必须通过中间的GW集群。
所有的应用都不能直接对外访问，对外访问的需求适应点对点开放策略，但是这些策略不适用于直接GW应用。 因为群集本身的横向扩展和高可用性的导入受到限制。 因此，我们的解决方案是在GW应用和防火墙之间添加逻辑F5的接入策略，并将与所有安全网络策略相关的网络映射策略置于该层。
这种方法的优点在于，所有GW应用的状态都可以无状态配置，并且所有合作伙伴的服务健康检查也可以在F5端配置，因为可以在大型网关的物理线路上进行冗馀配置。 可以在切换过程中改变为整个网络的链路切换，类似于路由切换、防火墙策略切换以及与互联网域名相关联的DNS切换。
到2016年，陆金所的一切应用都是相互依存的，应用之间的依存关系非常复杂，系统之间的结合程度也很重，给运营和管理带来了很多问题。
为了解决这些问题，2017年陆金所进行了全站层域的结构改造。 改造完成后，陆金所子系统从外部访问基础设施，分为7到8层，各层按业务模型和依赖关系可分为一百多个域，其中各域代表一个虚拟应用组合和应用组，具有较高的团结性，域之间的松散耦合 所有域都有自己的数据库，同层域之间尽可能不依赖，同层或不同层域之间只能单方面依赖。
体系结构改造后的优点是，许多复杂的应用程序管理现在可以转换为逐域虚拟团队各部门角色的管理维。 例如，在多元化、监视、运输等方面，虚拟团队负责人负责反复的优化和功能改善。
同时，每个域都有自己的数据库，因此在数据库级别按域进行了划分。 在分割之前，陆金所是按域划分的单实例百TB级库，分割后变成100多个小库，最大库也是5 TB级，为后续数据库的切换提供了有利条件。
这是陆金访问的链接框架，上图正好是我们的正常情况，两个双人房分别运送50%的流量。 外部要求通过一个机房落地后，通过安全设备和防火墙后，先到达的是Web层的F5，但我们Web层的F5只负荷4层。 此后，通过体系结构的流量控制—— Nginx集群，上述图以我们集群的默认形式显示，默认主室流量在现场，一旦细分为按应用程序的流量监视和切换，我们就根据此层的分发策略进行流量切换 这允许直接切换内部业务，并且能够避免可能在GTM切换中发生的域名分析的延迟，并提高切换效率。
此外，以相对标准的形式，在Web层Nginx负载变为平衡的7层负载之后，Web层应用调用App层中的F5和负载，触摸真实的App应用，完成与数据库的交互访问。
值得注意的是，陆金的一切标准应用都必须以这种标准化的方式严格引进交货。 这样做的好处是，所有标准化应用程序都是无状态的，支持水平扩展，并且不需要在特别复杂的操作之间切换流量。
在日常活动中，我们经常遇到的切换场景是核心部件的切换，相对特征性的场景是数据库AI切换。 陆金所期望的数据库发生故障时，无需人工干预，就能够智能地发现问题的原因，实现快速的切换。
陆金所DBA团队研究了数据库AI交换机平台，在线后，数小时前的数据故障恢复时间可以减少到1-3分钟，Redis库可以在30秒内完成AI交换机，MySQL实例可以在1分钟内完成AI交换机
AI切换平台在线后，我们在生产环境中至少发生了12次真实情况的切换场景，数据库故障恢复的时间基本上在1分钟以内，为陆金站的整个站点的利用率做出了巨大贡献。
当发出换手指令时，AI Master向每个AI Proxy返回所有换手指令，而AI Proxy向其下管理的数据库实例返回相应的换手状态和返回消息，以及AI Master
上图是交换平台整体的框架，特别是不复杂，基本上分为3层，第一层是交互层，主要由Phoenix平台和LuGrafana构成，分别执行交换操作和交换磁盘的业务层 服务总线、API网关。最后一层是基本层，包括CMDB配置中心、统一权限验证管理PASSPORT、平台PAVO和配置版本中心LuGIT。
陆金所核心交换基本上由七个核心组件的交换组成，每个核心组件的交换都有个性化的交换逻辑。 在设计交换平台时，我们希望交换服务目录能够更抽象、共享，因此采用上图的设计模型，一个交换服务由一个或多个服务目录构成，一个交换服务目录由自己的 可分为一个或多个原子交换服务，一个原子交换服务由一个工作任务和工作参数的组合构成。 当此任务组在运行之前明确了工作任务和工作参数时，系统将生成一组可执行实例，并在流程引擎中调度所有概念。
根据技术运营和日常运输的情况，陆金站独自开发分布式作业平台，基于微服务框架，组合多个角色节点的容器，各角色节点可以根据自己设定的监视阈值水平动态伸缩，各服务组件负责的作业具有作业特性
每个作业组的运行基于七个步骤，首先提交CMDB主机任务。 其中一个关键点是，数据闭环从CMDB中检索所有交换机作业或日常更改的数据，并将最终更改结果的状态还原为CMDB。 然后，初始化相应的后续作业任务，通过获取的主机任务和作业任务，将相应的任务推入任务队列，通过任务调度器执行每个任务的串行或并行任务调度和执行，任务调度结束 这样，总结整个任务的运行状态并将其反馈给调用方，直到在作业调度级别发现所有任务组都已运行。
在日常工作中，机房级别的切换实际上很少，因此除了机房级别的单击切换服务外，还提供各个核心组件的切换服务。 在发现日常运输或故障时，这些组件的切换服务最常用。
上图表示我们切换平台的主接口，左侧表示具体的服务目录，右上表示整体的可视化流程，右下表示执行任务的具体的各执行节点、执行时间、状态的进展等。
上图显示了交换组件交换的详细信息。 我们的公司内部业务叫做交换计划。 主要指示了组件的开关类型、开关操作、开关资源和开关参数，以及相应的CMDB闭环原始数据更新逻辑。
此外，对于每个组件，除了提供正常的切换数据外，还要求在生成切换计划时提供在组件切换异常时回滚的参数。 进行切换前，反复确认各资源的所属组，切换原始数据的准确性，确保切换动作的可靠性。
上图是切换进度页面，主要用于对应的切换资源的所属组。 在切换过程中，每个切换的所属组都可以查看此页面以获得核心组件的整体切换状态和组件切换里程碑。 进一步细分，可以快速查看相关组件的子分类和子任务的执行情况和执行时间，在发现切换问题时首先发现并处理。
上图是切换日志的接口，如果切换正常，则不会去看日志，但是在切换过程中一部分组件和动作发生错误时，切换作业人员首先根据错误信息的指示快速打开日志，找到与错误对应的任务，展开详细的日志，发生错误 当前支持的行为包括重试、回滚、忽略、暂停和退出。
机房水平的切换过程主要分为前、核、后三个部分。
前置主要任务包括:第一个全站点的维护页面，在开始切换时发出在陆金外部的Nginx上将业务切换为运维的命令，向用户传递明确的信息页面，防止切换中外部业务流入，第二，在双人房建设中流动 默认策略是流量控制层流量下降到总室，无法交叉访问。 否则，如果流控制层将流量引入原始室，则切换将失败，第三，准备后续核心部件和DB交换机及DNS交换机。
核心交换主要是七个核心组件的并行交换过程，总体交换内容必须严格符合ITIL实现标准，还必须注意数据闭环，所有数据都必须与数据存档、CMDB的数据闭环兼容
在设计初期，我们需要一个相对简单、粗鲁、全面的并行切换，所有组件都互不相依。
但是，在不断的演习实践中，我们做了更细分的工作，每个组件依赖于不同的资源切换，但是有些资源可能是类似的，因此我们将不同的核心组件共享的资源放在一起，只切换了一次。 由此，不会在每次切换时并行进行DNS切换或Nginx相关的构成变更。 虽然已知DNS交换和Nginx布置的改变在理论上是同时进行的，但是在真正的分发过程中是串联的，以确保布置的可靠性，如果我们将相同类型的资源放置在一个环境中，则可以提高总体效率并将交换时间从4分5秒减少到4分钟。
后向交换机易于理解，整个核心交换机完成后，接下来对所有站服务进行自检。 完成后备服务的自检任务和后备服务、流限制等动作后，完成整体的切换作业。
不仅要切换平台，切换磁盘也很重要。 在转换之前，除了转换操作员外，参加日常转换演习的其他同学，如开发、测试、结构、运输相关的同学，实际上在转换平台上没有使用，大部分都是转换的大关。 更换的大盘子在更换之前展示着详细的更换日历。 主要目的是确保所有参与转换的同学都了解转换的细节，并且在转换过程中同步大家的信息。
通过核心组件切换模块，用户能够直观地获知各组件的切换进度、整体切换状况等。
后交换机主要完成陆金所全站服务可用性的自我诊断。 自检的结果是生成可用性报告，目的是让相关的转换同学直观地看看这次转换的结果是否与预想一致。
不仅是切换工具，在整个切换过程中也贯穿了事前、事后三个步骤。 我们要求的是，事前做好充分准备，在事件中采取统一行动，事后进行持续的监视、观察和总结。
如果在切换过程中发现问题，请继续跟踪，直到下一个切换优化并解决问题。 以此方式，希望在切换过程中完善所有相关组件和服务，并尽可能地优化关键指标。
刚才提到的DevOps流水线和自动运输技术框架，不仅在服务之间切换，在陆金所技术运营的其他场合也被使用。 我们的标准化变更、监视、故障分析和自我修复、DevOps的全过程是基于该技术体系构建的，该技术体系是陆金运营的中心子系统。
四、平台建设收益
简要介绍平台建设完成后的收益。
在平台在线交换后，陆金所整体技术运营能力明显提高。 不仅适用于陆金所内部的场景，安全系统内部也具有很大的普遍性。 现在，我们也在推进框架，希望在金融领域的兄弟企业中发挥模范作用。
上图为直接收益数据，陆金本身的业务也每年几何增长，但我们服务的支持、可用性在2018年达到了较好的水平，这完全依赖于交换服务和体系结构的改造。
五、陆金所许多活机房的规划
最后，让我们一起分享陆金所众多活跃的机房整体规划方向。
陆金所现在正在建设2块土地的3个中心，是该城的共生、异地灾害准备。 异地灾害准备和同城共活的现在流量分配是50:49:1，我们将近1%以下的流量分成河北廊坊的机房，这个灾害准备机房永远是热的，但是承载了比较少的流量，在真的需要启用灾害准备的时候，能够迅速引出服务
2020年，我们希望陆金所整体的服务状态达到以二地四为中心的服务多元化形态。 此外，我们还将重点放在“o”和去库列表的工作上。 因为只有达到这个目标，才能真正完成我们期待的多元化的服务管理形态。 整个服务切换平台也考虑更多的异常情况。 例如，在真正的极限情况下，切换是我们最优先考虑的方案，但是如果存在可能没有达到切换条件的异常情况，我们将激活，激活不是角色切换，而是直接从服务管理的一部分集群中排除原主机室的主服务 这是集群的损失方案，如果自动判定战略还没有达到移交效果，我们就采用这种方式。
此外，我们现在正在使用像Oracle、MySQL这样的数据库。 在金融界，我们现在看到的瓶颈和桶原则最短的主板是数据库，同行的大多数公司都不能使用像BAT这样纯分布式数据库体系结构来支持。 我们现在认为，更具普遍价值的是去“o”，去自己的“o”，将Oracle的切换效率差、切换操作复杂、容易出错的场景降到最低。 前往o可让您建立使用者层级的储存库表格。 这样，即使在超越地域的情况下，也能够切换为不因延迟而无法利用服务或者服务的性能降低。
