移动环境下多模式注册中心架构切换方法与流程

[0001]
本发明涉及一种主要应用于移动环境下的多模式注册中心切换算法，用于对移动环 境下(如无人车、无人船、无人机等)的服务注册中心的注册中心架构模式进行决策和切换， 尤其是可用于移动环境下的面向服务架构的分布式注册中心的实现与开发领域。


背景技术：

[0002]
目前的网络架构是每个主机都有一个独立的ip地址，服务发现基本上都是通过某种 方式获取到服务所部署的ip地址。优秀的服务框架往往会支持多种配置中心，但是注册中 心的选择依然与服务框架强关联，普遍的情况是一种服务框架会带一个默认的服务注册中心。 这样虽然免去了用户在选型上的烦恼，但是单个注册中心的局限性，导致用户使用多个服务 框架时，必须部署多套完全不同的注册中心，这些注册中心之间的数据协同是一个问题。服 务注册中心是服务发现中不可缺少的一部分。通俗来讲，服务注册中心是一个存储网络实例 的网络地址和数据库。作为默默支持的产品，服务注册中心往往隐藏在服务框架背后。服务 注册中心(下称注册中心)是微服务架构非常重要的一个组件,在微服务架构里主要起到了协调 者的一个作用。注册中心的核心数据是服务的名字和它对应的网络地址，当服务注册了多个 实例时，我们需要对不健康的实例进行过滤或者针对实例的一些特征进行流量的分配，那么 就需要在实例上存储一些例如健康状态、权重等的属性。在微服务架构中，注册中心是核心 的基础服务之一。在微服务架构流行之前，注册中心就已经开始出现在分布式架构的系统中。 作为微服务架构最基础也是最重要的组件之一，服务注册中心本质上是为了解耦服务提供者 和服务消费者。对于任何一个微服务，原则上都应存在或者支持多个提供者，这是由微服务 的分布式属性决定的。更进一步地，为了支持弹性扩缩容特性，一个微服务的提供者的数量 和分布往往是动态变化的，也是无法预先确定的。因此，原本在单体应用阶段常用的静态 lb机制就不再适用了，需要引入额外的组件来管理微服务提供者的注册与发现，而这个组 件就是服务注册中心。作为服务注册中心的代表性实现之一，eureka采用了cs的设计架构， eurekaserver作为服务注册功能的服务器，它是服务注册中心。而系统中的其他微服务，使 用eureka的客户端连接到eurekaserver，并维持心跳连接。这样系统的维护人员就可以通过 eurekaserver来监控系统中各个微服务是否正常运行。各个微服务节点通过配置启动后，会 在eurekaserver中进行注册，这样eurekaserver中的服务注册表中将会存储所有可用服务节 点的信息，服务节点的信息可以在界面中直观看到。作为注册中心如果是单节点的话，遇到 故障，后果是非常严重的，eureka就需要通过互相注册的方式来实现高可用的部署，eureka 作为服务治理中心对整个微服务架构起着最核心的整合作用。服务注册中心能够对服务提供 者所提供的服务进行注册存储，并为服务消费者提供查询功能，返回满足需求的服务列表， 还能记录服务提供者和服务消费者的信息，实现服务消费者对服务提供者信息的订阅等，通 过集群的方式还可以实现高可靠、高可用的服务注册中心功能，从而满足某些生产环境中对 服务注册中心的高可用需求。借助服务注册中心，服务消费者可以在进行远程服务调用时， 从查询到
的服务列表中选择服务提供方的地址进行服务调用，无需与特定的服务提供者绑定， 可以实现服务提供者和服务消费者的灵活对接，从而提升分布式系统的服务组件化设计与开 发能力。
[0003]
不管是面向服务架构soa，还是目前流行的微服务架构，服务注册中心都是不可或 缺的重要组成部分，是实现服务使用者和服务提供者对接的纽带。在面向服务的分布式软件 系统架构中，应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契 约联系起来，服务接口采用中立的方式进行定义，并独立于实现服务的硬件平台、操作系统 和编程语言，从而使得构建在各种系统中的服务可以使用统一和通用的方式进行交互。在面 向服务的软件架构中，借助服务描述标准、数据交互协议以及基础平台软件，可以根据需求 对松散耦合的应用组件进行分布式部署、组合和使用。灵活、高效和鲁棒的服务注册中心系 统就是面向服务的软件架构中支撑实现服务提供者和服务消费者动态发现的重要媒介。在分 布式系统中，我们不仅仅是需要在注册中心找到服务和服务地址的映射关系这么简单，我们 还需要考虑更多更复杂的问题：如服务注册后，如何被及时发现；服务宕机后，如何及时下 线服务；如何有效进行水平扩展；服务发现时，如何进行路由；服务异常时，如何进行降级； 注册中心如何实现自身的高可用，这里问题的解决都依赖于注册中心。简单看，注册中心的 功能有点类似于dns服务器或者负载均衡器，而实际上，注册中心作为微服务的基础组件， 可能要更加复杂，也需要更多的灵活性和时效性。
[0004]
现有的注册中心架构一般都采用固定的模式，或者是存在多种模式，但系统运行过 程中只能采用一种模式，而不能在系统运行过程中，实现多种模式的热切换；同时，现有的 注册中心节点数量一般都是系统启动前进行静态配置的固定数量，而不能实现在系统运行过 程中，实现节点数量的动态选择，这就严重限制了目前的注册中心系统在移动动态环境下的 适应性，在移动环境下，网络环境以及环境中的平台、服务都是动态变化的，因此注册中心 的模式需要根据网络环境实现多种模式的灵活切换。注册中心可以说是微服务架构中的“通 讯录”，它记录了服务和服务地址的映射关系。在分布式架构中，服务会注册到这里，当服 务需要调用其它服务时，就到这里找到服务的地址，进行调用。一个服务注册中心，应包含 一个服务器的集群，在这个集群中，各个机器中的数据需要保持一致，机器之间通过 replication协议来实现这个功能。数据一致性是分布式系统永恒的话题，数据一致性从协议 层面上看，基本可以归为两种：一种是基于leader的非对等部署的单点写一致性，一种是 对等部署的多写一致性。当我们选用服务注册中心的时候，并没有一种协议能够覆盖所有场 景，例如当注册的服务节点不会定时发送心跳到注册中心时，强一致协议看起来是唯一的选 择，因为无法通过心跳来进行数据的补偿注册，第一次注册就必须保证数据不会丢失。而当 客户端会定时发送心跳来汇报健康状态时，第一次的注册的成功率并不是非常关键(当然也 很关键，只是相对来说我们容忍数据的少量写失败)，因为后续还可以通过心跳再把数据补 偿上来，此时paxos协议的单点瓶颈就不太划算了，这也是为什么eureka这种代表性的注 册中心不采用paxos协议而采用自定义的renew机制的原因。这两种数据一致性协议有各 自的使用场景，对服务注册的需求不同，就会导致使用不同的协议。虽然大部分用户用到的 性能不高，但是他们仍然希望选用的产品的性能越高越好。影响读写性能的因素很多：一致 性协议、机器的配置、集群的规模、存量数据的规模、数据结构及读写逻辑的设计等等。在 服务发现的场景中，我们认为读写性能都是非常关键的，但
是并非性能越高就越好，因为追 求性能往往需要其他方面做出牺牲。很多业务组件的异地多活正是依靠服务注册中心和配置 中心来实现的，这其中包含流量的调度和集群的访问规则的修改等。机房容灾是异地多活的 一部分，但是要让业务能够在访问服务注册中心时，动态调整访问的集群节点，这需要第三 方的组件来做路由。异地多活往往是一个包含所有产品线的总体方案，很难说单个产品是否 支持异地多活。
[0005]
目前的注册中心选举都是采用的分布式共识算法，这类算法没有考虑移动环境下的 网络特性、移动平台特性、移动平台部署的服务特性以及通信特性等，使得这些算法在不同 的移动环境下得出的结果是相同的，不能很好的依据移动环境情况进行注册中心的优化选取， 从而使得通过这类算法选择出的中心节点不能很好地降低移动环境下注册中心服务交互总体 通信带宽和时延。
[0006]
此外，对于目前存在多模式注册中心实现的注册中心系统，如果需要进行模式切换， 必须要对所有注册中心进行停机，重新进行配置之后再启动执行，不能在无人工介入的情况 下进行多种模式的动态切换。
1.

技术实现要素：

本发明的目的在于针对上述现有技术存在的不足之处，提供一种移动环境下多模式注册中心 架构切换方法，该方法可以实现单中心、多中心以及无中心多种模式架构的灵活切换，并可 支持注册中心的数量动态变化，以克服现有注册中心只考虑单一模式和固定注册中心数量的 问题。
[0008]
本发明的上述目的可以通过以下措施来达到，一种移动环境下多模式注册中心架构 切换方法，具有如下技术特征，移动网络环境下，以多模式注册中心切换引擎作为整个注册 中心架构控制的运行载体，采用多模式注册中心切换算法，周期性的对整个网络域的平台和 搭载的传感器载荷服务状态进行监控；多模式注册中心切换引擎启动本次轮询，进入架构运 行方式手动/自动判断：如果当前模式是自动模式，架构自动设置处理模块则进行架构自动 设置处理，然后先进行架构初始设置判断，如果未进行初始设置，就通过架构转换设置模块 进行架构设置，该过程先采用重心法进行多模式中心平台选取，然后针对选择的模式和中心 平台，进行特定模式下的传感器多模式服务注册，如果已进行架构初始设置，架构状态更新 模块先进行架构状态更新，对平台上线/下线、以及平台/载荷服务信息更新，架构切换决策 模块根据更新结果，利用架构切换策略进行架构模式符合性判断和架构切换阈值判断，如果 计算的自动架构模式与当前架构模式不符或达到架构切换阈值，就启动架构转换设置模块进 行架构切换；如果当前模式是手动模式，显控单元作负责手动模式的注册中心模式和中心列 表输入，则架构手动设置处理模块进行架构手动设置处理；架构切换引擎根据平台加入，平 台退出和平台心跳以及平台列表信息产生的变更事件进行架构状态更新；多模式注册中心根 据感知的网络环境、移动平台部署的服务情况、移动平台之间的距离以及通信质量等情况实 现自动多模式注册中心架构切换。
[0009]
本发明相比于现有技术的有益效果是：本发明采用移动网络环境下，以多模式注册中心切换引擎作为整个注册中心架构控制的运行 载体，周期性的对整个网络域的平台和搭载的传感器载荷服务状态进行监控；多模式注册中 心切换引擎启动本次轮询，进入架构运行方式手动/自动判断：如果当前模式是
自动模式， 采用重心法进行多模式中心平台选取，然后针对选择的模式和中心平台，进行特定模式下的 传感器服务注册。本发明所采用的重心法特别考虑了移动平台部署的传感器服务情况、移动 平台之间的距离以及通信质量等影响因子，使得该方法更贴近移动系统注册中心选取的要求， 可以实现对移动环境下注册中心的优化选取，降低了移动网络环境下，注册中心服务交互总 体通信带宽和时延。
[0010]
本发明采用先进行架构状态更新，对平台上线/下线、以及平台/载荷服务信息更新等 事件的处理，根据更新结果，利用架构切换策略进行架构模式符合性判断和架构切换阈值判 断，如果计算的自动架构模式与当前架构模式不符或达到架构切换阈值，就启动架构转换设 置模块进行架构切换；如果当前模式是手动模式，则进行架构手动设置处理，可以实现单中 心、多中心以及无中心多种模式架构的灵活切换。
[0011]
本发明将通用共识算法策略和移动环境对通信质量的需求相结合，采用架构切换的阈 值判断法，并未对注册中心的其他通用功能进行修改，而只是在原有注册中心的基础上增加 了注册中心架构模式和中心选取的决策算法，完成在移动环境下多种模式架构切换，实现不 需人工介入的架构切换的自主决策，完成多模式注册中心的热切换。
[0012]
本发明参考多种影响因子，采用重心法，对移动分布式环境下的多模式注册中心进 行模式和中心选取决策，以此完成多模式注册中心的架构切换，在移动环境下，提升注册中 心架构的环境适应性和鲁棒性。
[0013]
本发明充分考虑移动环境下注册中心模式选取的环境适应性，为在移动环境下实现 跨无人平台的服务信息共享和使用，多模式注册中心，根据感知的网络环境、移动平台部署 的服务情况、移动平台之间的距离以及通信质量等情况实现自动多模式注册中心架构切换， 可以根据当前网络域感知的网络环境实现多中心、单中心、无中心三种模式注册中心架构的 灵活切换。克服了现有注册中心只考虑单一模式和固定注册中心数量的问题。
[0014]
面向服务架构的多模式注册中心是注册中心从单模式向多模式的扩展实现，是为了 满足面向服务架构在移动、动态环境下，提高注册中心架构的鲁棒性和环境适应性而设计的。 由于原有注册中心的基础功能未进行改变，所以不仅可以与遗留系统进行有效兼容且实现简 单，减少了重复开发成本。
[0015]
本发明支持注册中心的数量动态变化，可以作为现有面向服务架构的服务注册中心 实现的一个扩展，应用对象可推广到其他的移动控制中心选取。
附图说明
[0016]
下面结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地 描述。应当理解，此处所描述的具体实施方式仅仅用以解释本发明，并不用于限定本发明， 本领域普通技术人员在没有创造性劳动前提下所获得的所有其它实施例，都属于本发明保护 的范围。
[0017]
图1显示了本发明移动环境下多模式注册中心架构切换原理示意图。
[0018]
图2是图1的切换流程图。
[0019]
图3是本发明多模式中心平台选取算法流程图。
[0020]
图4是本发明的多模式传感器载荷服务注册及注册信息同步算法流程图。
[0021]
图5是本发明的架构状态更新算法流程图。
[0022]
下面结合附图和实施例对本发明进一步说明。
具体实施方式
[0023]
参阅图1。根据本发明，移动网络环境下，以多模式注册中心切换引擎作为整个注册 中心架构控制的运行载体，采用多模式注册中心切换算法，周期性的对整个网络域的平台和 搭载的传感器载荷服务状态进行监控；多模式注册中心切换引擎启动本次轮询，进入架构运 行方式手动/自动判断：如果当前模式是自动模式，架构自动设置处理模块则进行架构自动 设置处理，然后先进行架构初始设置判断，如果未进行初始设置，就通过架构转换设置模块 进行架构设置，该过程先采用重心法进行多模式中心平台选取，然后针对选择的模式和中心 平台，进行特定模式下的传感器多模式服务注册，如果已进行架构初始设置，架构状态更新 模块先进行架构状态更新，对平台上线/下线、以及平台/载荷服务信息更新，架构切换决策 模块根据更新结果，利用架构切换策略进行架构模式符合性判断和架构切换阈值判断，如果 计算的自动架构模式与当前架构模式不符或达到架构切换阈值，就启动架构转换设置模块进 行架构切换；如果当前模式是手动模式，显控单元作负责手动模式的注册中心模式和中心列 表输入，则架构手动设置处理模块进行架构手动设置处理；架构状态更新模块根据平台加入， 平台退出和平台心跳以及平台列表信息产生的变更事件进行架构状态更新；多模式注册中心 根据感知的网络环境、移动平台部署的服务情况、移动平台之间的距离以及通信质量等情况 实现自动多模式注册中心架构切换。
[0024]
在可选的实施例中，多模式注册中心默认设置是自动模式。
[0025]
多模式注册中心是注册中心从单模式向多模式的扩展实现，面向服务架构的多模式 注册中心，是为了满足面向服务架构在移动、动态环境下，提高注册中心架构的鲁棒性和环 境适应性而设计的。
[0026]
多模式注册中心架构切换引擎是整个多模式注册中心的运行载体，周期性地对整个 网络域的平台和搭载的传感器载荷服务状态进行监控，并根据平台和服务状态完成注册中心 的架构切换，其中平台包括但不限于机载平台。
[0027]
架构运行方式手动/自动判断是多模式注册中心架构切换引擎对当前架构运行是手动 还是自动方式进行的判断。
[0028]
架构初始设置判断是多模式注册中心架构切换引擎对当前架构是否进行已经进行初 始设置的判断。
[0029]
架构自动设置处理模块用于当多模式注册中心架构切换引擎是自动模式时的架构切 换处理算法流程，是该本发明的核心部分。
[0030]
架构手动设置处理模块用于当多模式注册中心架构切换引擎是手动模式时的处理流 程，在该专利中不对该过程作过多说明。
[0031]
架构状态更新模块根据当前网络域的平台加入、平台退出、平台心跳中附带的平台/ 载荷服务更新等产生的变更事件完成多模式注册中心架构切换引擎中对架构状态的更新算法 处理流程。
[0032]
架构切换决策模块是根据架构状态更新模块的处理情况，确定当前计算的架构模式 与保存的历史架构模式是否相符，并判断当前架构状态是否达到架构切换的阈值，继而由上 述情况决定是否进行架构切换的决策。
[0033]
架构转换设置模块包括：多模式中心平台选取模块和多模式服务注册模块，多模式 中心平台选取模块根据当前网络域的平台/服务状态确定当前架构模式，包括单中心、多中 心和无中心三种模式的确定，以及当架构模式是多中心时，确定中心节点数量中心节点数量， 多模式服务注册模块根据确定的架构模式和中心节点数量，分别针对上述三种模式，完成载 荷服务向中心节点的多模式服务注册以及中心节点间信息同步的算法处理流程，从而完成架 构切换。
[0034]
参阅图2。所述多模式注册中心切换算法的具体步骤流程为：s1：多模式注册中心切换引擎启动多模式注册中心切换算法，首先进行架构运行方式判断， 判断当前是否为自动方式，如果是自动方式，则继续执行架构自动设置处理的算法流程；s2：如果是手动方式，则执行架构模式的手动设置处理，多模式注册中心默认是自动模式， 如果当前模式是手动模式，则说明多模式注册中心已经根据用户手动输入的模式和节点数量 进行了架构设置，本实施例对此不做过多说明，重点阐述自动模式切换。
[0035]
s3：所述自动方式的架构自动设置处理流程，首先由架构切换引擎判断当前架构设置 是否已进行初始设置；s4：如果未进行初始设置，架构切换引擎进行架构转换，按照架构转换设置模块的处理算法 流程进行，该模块首先进行架构模式选取和中心平台选取；s5：在确定完架构模式和中心平台后，架构切换引擎将依据选取的中心节点进行架构转换设 置的多模式服务注册；s6：如果是已经进行首次设置，架构切换引擎进行架构状态更新，按照架构状态更新模块的 处理进行，架构切换引擎先进行架构状态更新；s7：架构切换引擎根据架构状态更新结果进行架构模式计算，所述架构模式计算与架构转换 设置的架构模式选取所采用规则一致；s8：架构切换引擎判断当前计算的架构模式与架构状态中记录的历史架构模式是否相符；如 果不符合，则转到s4按照架构转换设置模块的算法处理流程进行；s9：如果相符，则架构切换引擎进行架构切换阈值计算。
[0036]
在可选的实施例中，架构切换阈值计算步骤如下：架构切换决策模块将所有通信状态不佳的节点的数量num
unhealthy
进行初始化，使得 num
unhealthy
＝0；获取每个节点的通信状态com_status，并对该状态进行判断；如果该节点通 信状态不佳，就将num
unhealthy
进行更新，使得num
unhealthy
＝num
unhealthy
+1；在完成所有节点通 信状态判断的情况下，如果num
unhealthy
>num
p
/2+1，即超过半数节点通信状态不佳，则认为 已达到架构切换阈值，其中num
p
为平台数量。
[0037]
s10：架构切换引擎判断计算的阈值是否达到切换阈值，如果已经达到，则转到s4按 照架构转换设置模块的算法处理流程进行；s11：如果未达到，则等待到达下一次轮询时间；s12：到达下次轮询时间，架构切换引擎判断是否退出架构切换任务，如果不退出，则转到 s1继续进行下次轮询；如果退出，则整个切换流程结束。
[0038]
参阅图3。所述架构转换设置模块的多模式中心平台选取的具体步骤流程为：p1：架构切换引擎进行架构模式和中心节点数量计算；
在可选的实施例中，架构模式mode和中心节点数量num
center
的选取规则主要依据平台数量 num
p
进行，具体规则如下：(1)若num
p
≤7，则mode为无中心模式，无中心模式的中心节点数量num
center
＝0；(2)若7≤num
p
≤50，则mode为单中心模式，单中心模式的中心节点数量num
center
＝1；(3)若num
p
≥50，则mode为多中心模式，多中心模式的节点数量num
center
＝num
p
/50+1。
[0039]
p2：确定架构模式和中心节点数量后，架构切换引擎将依据架构模式和中心节点数量进行中心节点选取，首先进行架构模式判断；p3：如果是单中心模式，先采用重心法计算重心节点位置；在可选的实施例中，所述重心法就是根据各个分布平台的位置，采用各个分布平台上部署的传感器服务数量作为系数因子，确定所有平台构成的网络域的重心节点位置的方法，具体计算步骤如下，设表示平台i上部署的传感器服务的数量，lon
i
，lat
i
，alt
i
分别表示平台i的经度、纬度、高度，则重心节点的经度、纬度、高度的计算公式如下：(1)计算重心节点的经度∕(2)计算重心节点的纬度∕；(3)计算重心节点的高度∕；p4：在此基础上，计算所有平台与重心节点的服务影响因子距离dis
i
；服务影响因子距离dis
i
计算公式如下dis
i
=distance
i
/，其中，distance
i
是平台i与重心节点之间的三维空间距离，p5：选择与重心节点的服务影响因子距离dis
i
最小的平台，将其放入中心节点列表中，作为单中心模式的中心节点；在可选的实施例中，服务影响因子距离dis
i
是考虑了平台i上部署的服务数量的距离，该距离设计的初衷是尽可能的让部署的服务数量比较多的节点作为中心平台，以减少服务注册时，与注册中心之间的总体通信开销；p6：如果是多中心模式，先采用重心法计算重心节点位置，所述重心法如前所述；p7：计算所有平台i与重心节点的服务影响因子距离dis
i
；p8：选择与重心节点服务影响因子距离dis
i
最小的前num
center
个平台，将其放入中心节点列表中；p9：将距离最近的中心节点作为master节点，其他num
center-1个平台作为slave节点；p10：如果是无中心模式，则直接将中心节点列表设置为空；p11：返回中心节点列表。
[0040]
参阅图4，所述架构转换设置的多模式服务注册及信息同步的具体步骤流程为：m1：架构切换引擎获取当前架构模式和确定的注册中心列表；m2：架构切换引擎进行架构模式判断；m3：如果是单中心模式，先判断是否完成所有平台上部署的传感器服务的注册，如果完成， 流程结束；
m4：如果未完成，则先获取下一个平台i；m5：为该平台i选择应直连的注册中心平台，因为单中心模式只有一个中心平台c，故将平 台i的直连中心平台设置为c，计算平台i与直连注册中心平台之间的距离；m6：进行平台i与注册中心平台之间的保活信息传输和通信状态设置；m7：将平台i上部署的所有服务注册到中心平台的直连服务列表中，然后转到m3继续执行 是否完成所有平台上部署的传感器服务的注册的判断；m8：如果是多中心模式，先判断是否完成所有平台上部署的传感器服务的注册，如果完成， 流程结束；m9：如果未完成，则先获取下一个平台i；m10：为该平台i选择应直连的注册中心平台c；在可选的实施例中，所述的选择算法是计算平台i与注册中心列表中所有注册中心平台的距 离，并选择距离最小的注册中心平台作为该平台i的直连注册中心c；m11：进行平台i与注册中心平台之间的保活信息传输和通信状态设置；m12：将该平台i上部署的所有服务注册到与该平台直连的注册中心平台c上；m13：注册中心平台c先获取master信息，然后将服务注册的写请求转发到master节点， master节点进行服务注册；m14：master节点完成注册后将注册信息与所有注册中心节点进行信息同步，然后转到m8 继续执行是否完成所有平台上部署的传感器服务的注册的判断；m15：如果是无中心模式，先判断是否完成所有平台上部署的服务的注册，如果完成，流程 结束；m16：如果未完成，则先获取下一个平台i；m17：将该平台自身设置为本地注册中心；m18：将该平台上部署的所有服务添加到本地注册中心的直连服务列表中；m19：本地注册中心与其他所有平台进行服务注册信息同步，然后转到m15继续执行是否 完成所有平台上部署的传感器服务的注册的判断。
[0041]
参阅图5，所述架构状态更新的具体步骤流程为：r1：架构切换引擎接收到变更事件event；r2：架构切换引擎进行变更事件event的类型判断；r3：如果该事件是平台上线事件，架构切换引擎获取当前各个注册中心节点的信息；r4：计算上线平台i与所有注册中心节点的距离，并为该平台选择距离最小的注册中心，作 为平台i的直连注册中心c，并将注册中心c告知该平台i；r5：平台i与直连注册中心c之间进行保活信息传输和通信状态设置；r6：平台i将其上部署的所有服务注册到与该平台直连的注册中心平台c上；r7：注册中心平台c先获取master信息，然后将服务注册的写请求转发到master节点，master节点进行服务注册；r8：master节点完成注册后将注册信息与所有注册中心节点进行信息同步；r9：架构切换引擎将该平台i的当前状态信息保存到架构状态缓存中；r10：如果该事件是平台下线事件，架构切换引擎将平台下线事件发送给所有注册中心平台；
r11：注册中心平台c收到平台下线事件；r12：如果该平台i与注册中心c直连，注册中心平台c先获取master信息，然后将该平台i 上部署的所有服务的注销写请求转发到master节点，master节点进行服务注销；r13：master节点完成注销后将注销信息与所有注册中心节点进行信息同步；r14：注册中心c清除与平台i的保活和通信状态设置；r15：架构切换引擎删除架构状态缓存中存储的下线平台i的信息；r16：如果是平台/服务更新事件，根据推送事件进行架构切换引擎中架构状态缓存中存储的 平台/服务的信息更新；在可选的实施例中，所述的更新信息包括平台位置、平台速度、服务数量等；r17：根据状态信息更新，重新计算各个平台与其直连注册中心之间的距离，该步骤用于架 构切换的阈值判断。
[0042]
尽管已经示出和描述了本发明的实施例，对于本领域的普通技术人员而言，可以理 解在不脱离本发明的原理和精神的情况下对这些实施例进行多种变化、修改、替换和变型， 本发明的范围由所附权力要求及其等同物限定。