企业级微服务平台跨区域容灾架构及方法与流程

1.本发明涉及容灾技术领域，具体涉及企业级微服务平台跨区域容灾架构及方法。


背景技术：

2.在信息技术的快速发展下，各互联网公司和厂商越来越注重系统容灾方面的建设。容灾备份如果根据应用来划分的话，分为数据级容灾和应用级容灾。数据级容灾，在本地数据出现灾难时，系统至少在异地保存有一份可用的关键业务的数据。应用级容灾备份，是指在生产环境和同城环境建立完全相同的应用，两者组合为双活系统，在生产环境应用出现灾难时，同城环境的应用可以接管生产环境的业务，并在生产环境系统正常使用后，业务重新迁移直生产环境。应用级容灾和数据级容灾最大的区别就是，在生产系统发生灾难时，同城系统是否接管了生产系统的业务，保障了业务的连续性，这也是应用级容灾重点解决的问题。
3.在企业的实际生产环境中，当某个微服务部分节点或全部节点宕机时，如果使用现有技术方案来处理服务不可用的问题，会出现两个问题：一是从运维人员发现问题，到手动切换流量分配，会造成长时间服务不可用，严重时导致生产事故；二是使用注册中心的机房配置项时，无法灵活控制生产同城节点是否全部参与服务。


技术实现要素：

4.为了克服现有技术的不足，本发明提供了企业级微服务平台跨区域容灾架构及方法，可实现生产环境和同城环境功能互通，有利于解决当某个业务微服务部分节点或全部节点宕机时，无法灵活切换系统的问题。
5.为解决上述技术问题，本发明采用的技术方案如下：
6.第一方面，本发明提供企业级微服务平台跨区域容灾架构，其特征在于，所述架构包括：
7.网络流量配置装置，被配置为由生产环境和同城环境共用，用于向所述生产环境和/或同城环境配置相应的网络流量；注册中心，被配置为由生产环境和同城环境共用，用于向所述生产环境和/或同城环境的业务微服务提供节点注册；
8.配置中心，被配置为由生产环境和同城环境共用，用于在所述生产环境和/或同城环境的业务微服务的监听下提供相应的配置信息；
9.认证中心，被配置为由生产环境和同城环境共用，用于向所述生产环境和/或同城环境的业务微服务做统一认证；
10.监控中心，被配置为由生产环境和同城环境共用，用于向所述生产环境和/或同城环境的业务微服务运行时的指标做采集和记录；
11.管理平台，被配置为由生产环境和同城环境共用，用于向所述生产环境和/或同城环境的业务微服务进行统一管理。
12.可选的，所述网络流量配置装置包括负载均衡器和网关；其中：
13.所述负载均衡器根据网关的工作状态，向处于预设工作状态的网关进行流量转发。
14.可选的，所述网关具备同环境优先访问的特性，对应于生产环境或同城环境的网关优先访问生产环境或同城环境的业务微服务。
15.可选的，所述注册中心的节点数据相互同步，所述生产环境和/或同城环境的所有业务微服务向所述注册中心节点注册。
16.可选的，所述配置中心可以对所述生产环境和/或同城环境的业务微服务进行统一配置，并且统一对配置进行管控。
17.可选的，所述认证中心主要对所述生产环境和/或同城环境的业务微服务在每次请求时，均与所述认证中心交互，验证交易有效性，确保微服务间交易的安全性。
18.可选的，所述监控中心对所述生产环境和/或同城环境的业务微服务运行时的指标做采集并进行展示，以实时查看业务微服务的运行状态。
19.可选的，所述管理平台包括：
20.对所述生产环境和/或同城环境的业务微服务的服务治理；
21.对所述生产环境和/或同城环境的业务微服务的各组件信息进行统一管理。
22.第二方面，本发明提供企业级微服务平台跨区域容灾方法，其特征在于，所述方法包括：
23.通过由生产环境和同城环境共用的网络流量配置装置向所述生产环境和/或同城环境配置相应的网络流量；
24.通过由生产环境和同城环境共用的注册中心向所述生产环境和/或同城环境的业务微服务提供节点注册；
25.通过由生产环境和同城环境共用的配置中心在所述生产环境和/或同城环境的业务微服务的监听下提供相应的配置信息；通过由生产环境和同城环境共用的认证中心向所述生产环境和/或同城环境的业务微服务做统一认证；
26.通过由生产环境和同城环境共用的监控中心向所述生产环境和/或同城环境的业务微服务运行时的指标做采集和记录；
27.通过由生产环境和同城环境共用的管理平台向所述生产环境和/或同城环境的业务微服务进行统一管理。
28.可选的，其中：
29.在所述生产环境或同城环境的第一类业务微服务的部分节点宕机的状态下，所述生产环境或同城环境中其他类业务微服务能够访问第一类业务微服务未宕机的节点或者访问所述同城环境或生产环境中第一类业务微服务节点；或者
30.在所述生产环境或同城环境的第一类业务微服务的全部节点宕机的状态下，所述生产环境或同城环境中其他类业务微服务能够访问所述同城环境或生产环境中第一类业务微服务节点；或者
31.在所述生产环境和同城环境的全部节点连通的状态下，所述业务微服务交互时支持不同环境之间基于流量配比的混合调用。
32.本发明提供的上述方案通过重构业务系统所依赖的软件开发包，重写了业务微服务互相访问时所用到的基于ribbon组件的负载均衡方法，并加入区域亲和开关、通过为生
产环境和同城环境添加专属标识等关键性字段，并且在字段修改时可以实时更新到注册中心的元数据中，使配置及时生效，可在生产环境节点部分宕机时减少剩余节点压力，全部节点宕机时流量快速自动切换到同城环境节点，解决了无法灵活切换系统，且服务不可用时间过长时，需要人工干预的问题。
附图说明
33.图1为现有技术的架构运行的示意图；
34.图2为本发明实施例的架构运行的示意图；
35.图3为应用本发明实施例的处理业务微服务的部分节点宕机的示意图；
36.图4为应用本发明实施例的处理业务微服务的全部节点宕机的示意图；
37.图5为应用本发明实施例的处理混合调用的示意图；
38.图6为应用本发明实施例的处理网关宕机的示意图；
39.图7为应用本发明实施例的处理注册中心宕机的示意图；
40.图8为应用本发明实施例的处理配置中心宕机的示意图；
41.图9为应用本发明实施例的处理网关、注册中心、配置中心宕机的示意图。
具体实施方式
42.为了使得本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例的附图，对本发明实施例的技术方案进行清楚、完整地描述。显然，所描述的实施例是本发明的一部分实施例，而不是全部的实施例。基于所描述的本发明的实施例，本领域普通技术人员在无需创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。
43.除非另外定义，本发明使用的技术术语或者科学术语应当为本发明所属领域内具有一般技能的人士所理解的通常意义。本发明中使用的“第一”、“第二”以及类似的词语并不表示任何顺序、数量或者重要性，而只是用来区分不同的组成部分。“包括”或者“包含”等类似的词语意指出现该词前面的元件或者物件涵盖出现在该词后面列举的元件或者物件及其等同，而不排除其他元件或者物件。“连接”或者“相连”等类似的词语并非限定于物理的或者机械的连接，而是可以包括电性的连接，不管是直接的还是间接的。“上”、“下”、“左”、“右”等仅用于表示相对位置关系，当被描述对象的绝对位置改变后，则该相对位置关系也可能相应地改变。
44.在现有技术中当某个微服务部分节点或全部节点宕机时，会出现两个问题：一是从运维人员发现问题，到手动切换流量分配，会造成长时间服务不可用，严重时导致生产事故；二是使用注册中心的机房在配置项时，无法灵活控制生产同城节点是否全部参与服务。
45.本发明提供的上述方案通过重构业务系统所依赖的软件开发包，重写了业务微服务互相访问时所用到的基于ribbon组件的负载均衡方法，并加入区域亲和开关、通过为生产环境和同城环境添加专属标识等关键性字段，并且在字段修改时可以实时更新到注册中心的元数据中，使配置及时生效，可在生产环境节点部分宕机时减少剩余节点压力，全部节点宕机时流量快速自动切换到同城环境节点，解决了无法灵活切换系统，且服务不可用时间过长时，需要人工干预的问题。
46.以下对本发明的各个实施例做详细描述。
47.如图1所示，现有技术中在未进行架构改造时，相同的业务区域(业务渠道区)中，生产环境与同城环境的组件各自属于不同的集群，分别服务于各自环境中的业务微服务。生产环境中的业务微服务只能在生产环境中的注册中心中拉取生产环境的业务微服务节点列表，配置中心、认证中心、监控中心、管理平台同理，仅服务于生产环境的业务微服务。进一步的，在生产环境中，流量从消费方至负载均衡器、网关、到达其他类业务微服务时，其他类业务微服务如果有调用第一类业务微服务的需求，其他类业务微服务只能服务发现同环境的第一类业务微服务，在第一类业务微服务正常的情况下，调用链路正常，业务正常进行。如图所示，本文对于现有技术或者本技术各实施例中的负载均衡器可以通过f5标识。在生产环境、同城环境中，其他类业务微服务可被界定为业务微服务a，第一类业务微服务可被界定为业务微服务b。本文中通过业务微服务a、业务微服务b可以表征不同业务类别，也可以表征业务微服务所对应的不同节点，本文不做限定。
48.进一步的，如果业务微服务b部分节点宕机，剩余可用节点继续提供服务，但剩余节点会出现压力大的情况，导致业务微服务b全部节点宕机，业务微服务a因此无法找到可用的业务微服务b，造成业务中断，从而导致服务不可用时间过长。
49.进一步的，业务微服务a作为被调用方时同理，此处不再赘述。
50.作为一种方案，本技术的实施例能够提供企业级微服务平台跨区域容灾架构，包括：
51.网络流量配置装置，被配置为由生产环境和同城环境共用，用于向所述生产环境和/或同城环境配置相应的网络流量；
52.注册中心，被配置为由生产环境和同城环境共用，用于向所述生产环境和/或同城环境的业务微服务提供节点注册；
53.配置中心，被配置为由生产环境和同城环境共用，用于在所述生产环境和/或同城环境的业务微服务的监听下提供相应的配置信息；
54.认证中心，被配置为由生产环境和同城环境共用，用于向所述生产环境和/或同城环境的业务微服务做统一认证；
55.监控中心，被配置为由生产环境和同城环境共用，用于向所述生产环境和/或同城环境的业务微服务运行时的指标做采集和记录；
56.管理平台，被配置为由生产环境和同城环境共用，用于向所述生产环境和/或同城环境的业务微服务进行统一管理。
57.在一些实施例中，所述网络流量配置装置包括负载均衡器和网关；其中：
58.所述负载均衡器根据网关的工作状态，向处于预设工作状态的网关进行流量转发。
59.其中，负载均衡器可被配置为使用f5方案，其建立在现有网络结构之上，提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。需要说明的是：负载均衡设备不是基础网络设备，而是一种性能优化设备。对于网络应用而言，并不是一开始就需要负载均衡，当网络应用的访问量不断增长，单个处理单元无法满足负载需求时，网络应用流量将要出现瓶颈时，负载均衡才会起到作用。
60.在一些实施例中，所述网关具备同环境优先访问的特性，对应于生产环境或同城环境的网关优先访问生产环境或同城环境的业务微服务。
61.其中，负载均衡有两方面的含义：一方面，单个重负载的运算分担到多台节点设备上做并行处理，每个节点设备处理结束后，将结果汇总，返回给用户，系统处理能力得到大幅度提高(集群技术：clustering)。另一方面，大量的并发访问或数据流量分担到多台节点设备上分别处理，减少用户等待响应的时间，这主要针对web服务器、ftp服务器、企业关键应用服务器等网络应用。
62.本发明的一些实施例中，如图2所示，改造后的架构将生产环境和同城环境各自的注册中心集群合并为一个集群，生产环境和同城环境的业务微服务可以服务发现整个业务区域内所有的业务微服务实例信息；
63.进一步的，将配置中心、认证中心、监控中心集群也合并为一个集群，管理和监控所有微服务及实例节点；
64.进一步的，将管理平台合并，在一个后台上管理所有的业务微服务实例。
65.进一步的，在业务微服务依赖的sdk jar包中添加生产同城环境标识、区域亲和开关等字段，这些配置信息在管理平台上进行统一管控，当修改后会即时被推送至注册中心业务微服务的元数据中。
66.进一步的，业务微服务a调用业务微服务b时，业务微服务a根据sdk jar包中重写的负载均衡算法拉取所有可用的业务微服务b实例信息，再根据业务微服务b的注册中心的元数据中携带的区域亲和开关、流量配比在生产环境和同城环境所有业务微服务b的实例节点中选择一个合适可用的业务微服务b实例进行访问，通过上述改造，从而解决服务不可用时间过长的问题。
67.进一步的，所述注册中心的节点数据相互同步，所述生产环境和/或同城环境的所有业务微服务向所述注册中心节点注册。具体的，注册中心使用的是spring cloud技术框架中的eureka组件，通过重写业务微服务互相访问时所用到的基于ribbon组件的负载均衡方法，并加入区域亲和开关、为生产环境和同城环境添加专属标识等关键性字段，并且在字段修改时可以实时更新到注册中心的元数据中，使配置及时生效，从而当生产环境节点部分宕机时，减少剩余节点压力，全部节点宕机时流量快速自动切换到同城环境节点。
68.其中，spring cloud是一系列框架的有序集合，利用spring boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用spring boot的开发风格做到一键启动和部署。本技术各实施例的注册机制通过采用spring cloud将本领域中较为完善、认可度较高的服务框架组合起来，避免重复配置，通过spring boot风格进行再封装屏蔽掉了复杂的配置和实现原理，从而输出一套简单易懂、易部署和易维护的分布式系统开发工具包。
69.进一步的，所述配置中心可以对所述生产环境和/或同城环境的业务微服务进行统一配置，并且统一对配置进行管控。具体的，配置中心主要使用开源apollo技术框架，可以对业务微服务进行统一配置，并且统一的对配置进行管控，当业务微服务使用配置中心以后，可以在配置中心创建一份配置，业务微服务a可监听这一份配置的变化，进而对自身的一些配置做热更新操作，达到统一管控的能力，相当于将相同信息放在一起进行维护，避免重复劳动。
70.其中，apollo(阿波罗)是开源的一款生产级的配置中心产品，它能够集中管理应用在不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性，适用于微服务配置管理场景。
71.进一步的，所述认证中心主要对所述生产环境和/或同城环境的业务微服务在每次请求时，均与所述认证中心交互，验证交易有效性，确保微服务间交易的安全性。具体的，认证中心使用oauth2.0认证技术，主要对业务微服务做统一认证，微服务每次请求都会与认证中心交互，验证交易的有效性，确保微服务间交易的安全性。
72.其中，oauth2.0是oauth协议的延续版本。本技术各实施例的认证机制可以采用oauth 2.0关注客户端开发者的简易性，既可以通过组织在资源拥有者和http服务商之间的被批准的交互动作代表用户，也可以允许第三方应用代表用户获得访问的权限。同时，在一些实施例中，可以为web应用，桌面应用和手机等用户各种可能面对的终端设备提供专门的认证流程。
73.进一步的，所述监控中心对所述生产环境和/或同城环境的业务微服务运行时的指标做采集并进行展示，以实时查看业务微服务的运行状态。具体的，监控中心采用开源prometheus技术框架，对业务微服务运行时的指标做采集并通过grafana前端技术框架进行展示，prometheus的采集信息包括业务微服务的交易耗时，交易次数、交易失败率，熔断，微服务服务器cpu、内存、数据库线程池、微服务jvm等信息的监控及采集，帮助技术人员能实时查看业务微服务的运行状态。
74.其中，prometheus技术框架提供多维度数据模型和灵活的查询语言：通过将监控指标关联多个标签(tag)，来将监控数据进行任意维度的组合；提供http查询接口；可以很方便的结合grafana等组件展示数据，优选地，grafana可以做数据监控和数据统计，具有可视化、报警、通知、动态仪表盘、混合数据源、注释、过滤器的七大特点。
75.进一步的，所述管理平台包括：对所述生产环境和/或同城环境的业务微服务的服务治理；对所述生产环境和/或同城环境的业务微服务的各组件信息进行统一管理。具体的，管理平台又称为业务微服务统一管理平台，主要对业务微服务做统一管理，包括业务微服务的服务治理及业务微服务管理平台各组件信息的统一管理(api网关、注册中心、配置中心、认证中心、监控中心)；服务治理方面提供微服务api接口鉴权、ip白名单、微服务熔断、微服务间交互权限、流量权重及灰度等功能。
76.作为一种方案，结合前文所述，本技术的实施例能够提供企业级微服务平台跨区域容灾方法，包括：
77.通过由生产环境和同城环境共用的网络流量配置装置向所述生产环境和/或同城环境配置相应的网络流量；
78.通过由生产环境和同城环境共用的注册中心向所述生产环境和/或同城环境的业务微服务提供节点注册；
79.通过由生产环境和同城环境共用的配置中心在所述生产环境和/或同城环境的业务微服务的监听下提供相应的配置信息；通过由生产环境和同城环境共用的认证中心向所述生产环境和/或同城环境的业务微服务做统一认证；
80.通过由生产环境和同城环境共用的监控中心向所述生产环境和/或同城环境的业务微服务运行时的指标做采集和记录；
81.通过由生产环境和同城环境共用的管理平台向所述生产环境和/或同城环境的业务微服务进行统一管理。
82.本发明的一些实施例中，在所述生产环境或同城环境的第一类业务微服务的部分节点宕机的状态下，所述生产环境或同城环境中其他类业务微服务能够访问第一类业务微服务未宕机的节点或者访问所述同城环境或生产环境中第一类业务微服务节点。
83.本发明的一些实施例中，在所述生产环境或同城环境的第一类业务微服务的全部节点宕机的状态下，所述生产环境或同城环境中其他类业务微服务能够访问访问所述同城环境或生产环境中第一类业务微服务节点。
84.本发明的一些实施例中，在所述生产环境和同城环境的全部节点连通的状态下，所述业务微服务交互时支持不同环境之间基于流量配比的混合调用。
85.示例性地参见图3所示，业务微服务在进行交互时支持同环境优先访问，当生产环境的业务微服务b部分节点宕机时，业务微服务a访问业务微服务b剩余的存活节点；
86.进一步的，当业务微服务由于访问量较大时，可以手动在管理平台对该微服务进行配置，以支持不同环境混合调用，即生产环境的业务微服务a可以同时访问生产环境剩余的业务微服务b和同城环境的所有业务微服务b。
87.本发明的一些实施例中，参见图4所示，当生产环境的业务微服务b全部宕机时，生产环境的业务微服务a自动访问同城环境的业务微服务b的存活节点。
88.本发明的一些实施例中，参见图5所示，通过在管理平台对服务的区域亲和开关和被访问时的流量比例进行配置，达到生产环境与同城环境的业务微服务b在被调用时根据流量比例被混合或非混合调用。
89.本发明的一些实施例中，参见图6所示，f5负载均衡器在向网关转发流量前会探测网关是否存活，f5负载均衡器只向存活的网关进行流量转发，生产环境的f5负载均衡器默认向生产环境的网关转发流量；
90.进一步的，当同城环境网关宕机时，同城环境的f5负载均衡器会向生产环境的网关转发流量，生产环境的业务微服务继续提供服务。
91.本发明的一些实施例中，参见图7所示，生产环境和同城环境的注册中心在架构改造后已合并为一个集群，每个注册中心节点互为peer节点(数据互相同步)，可以看作生产环境和同城环境的所有业务微服务向每个注册中心节点注册，当同城环境的注册中心宕机时，生产环境的注册中心仍有全量业务微服务信息，业务微服务续约时向生产环境注册中心节点注册，生产环境注册中心可以继续提供服务。
92.本发明的一些实施例中，参见图8所示，生产环境和同城环境的配置中心中都存有全量业务微服务的配置信息，当同城环境的配置中心宕机时，生产环境的配置中心可以继续提供服务；
93.进一步的，所述配置中心的功能已在之前的实施例中描述，此处不再赘述。
94.本发明的一些实施例中，参见图9所示，当同城环境中的网关、注册中心、配置中心都宕机时，f5负载均衡器向生产环境中的网关转发流量，生产环境与同城环境中的业务微服务均可以继续使用生产环境中的注册中心、配置中心，业务系统之间的调用不受影响，同城环境的微服务节点可以继续提供服务，在当一方环境所有的微服务组件全部宕机的情况下依然可以保证业务连续性，可增强容灾能力。
95.综上所述，本发明提供的一种跨区域容灾系统及方法，可实现生产环境和同城环境功能互通，有利于解决当某个业务微服务部分节点或全部节点宕机时，无法灵活切换系统，且服务不可用时间过长时，需要人工干预的问题。
96.在一些实施例中，执行算机可执行指令处理器可以是包括一个以上通用处理设备的处理设备，诸如微处理器、中央处理单元(cpu)、图形处理单元(gpu)等。更具体地，该处理器可以是复杂指令集计算(cisc)微处理器、精简指令集计算(risc)微处理器、超长指令字(vliw)微处理器、运行其他指令集的处理器或运行指令集的组合的处理器。该处理器还可以是一个以上专用处理设备，诸如专用集成电路(asic)、现场可编程门阵列(fpga)、数字信号处理器(dsp)、片上系统(soc)等。
97.在一些实施例中，计算机可读存储介质可以为存储器，诸如只读存储器(rom)、随机存取存储器(ram)、相变随机存取存储器(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、电可擦除可编程只读存储器(eeprom)、其他类型的随机存取存储器(ram)、闪存盘或其他形式的闪存、缓存、寄存器、静态存储器、光盘只读存储器(cd-rom)、数字通用光盘(dvd)或其他光学存储器、盒式磁带或其他磁存储设备，或被用于储存能够被计算机设备访问的信息或指令的任何其他可能的非暂时性的介质等。
98.在一些实施例中，计算机可执行指令可以实现为多个程序模块，多个程序模块共同实现根据本公开中任何一项所述的医学影像的显示方法。
99.本公开描述了各种操作或功能，其可以实现为软件代码或指令或者定义为软件代码或指令。显示单元可以实现为在存储器上存储的软件代码或指令模块，其由处理器执行时可以实现相应的步骤和方法。
100.这样的内容可以是可以直接执行(“对象”或“可执行”形式)的源代码或差分代码(“delta”或“patch”代码)。这里描述的实施例的软件实现可以通过其上存储有代码或指令的制品提供，或者通过操作通信接口以通过通信接口发送数据的方法提供。机器或计算机可读存储介质可以使机器执行所描述的功能或操作，并且包括以可由机器(例如，计算显示设备、电子系统等)访问的形式存储信息的任何机制，例如可记录/不可记录介质(例如，只读存储器(rom)、随机存取存储器(ram)、磁盘存储介质、光存储介质、闪存显示设备等)。通信接口包括与硬连线、无线、光学等介质中的任何一种接口以与其他显示设备通信的任何机制，例如存储器总线接口、处理器总线接口、因特网连接、磁盘控制器等。通信接口可以通过提供配置参数和/或发送信号来配置以准备通信接口，以提供描述软件内容的数据信号。可以通过向通信接口发送一个或多个命令或信号来访问通信接口。
101.本公开的实施例的计算机可执行指令可以组织成一个或多个计算机可执行组件或模块。可以用这类组件或模块的任何数量和组合来实现本公开的各方面。例如，本公开的各方面不限于附图中示出的和本文描述的特定的计算机可执行指令或特定组件或模块。其他实施例可以包括具有比本文所示出和描述的更多或更少功能的不同的计算机可执行指令或组件。
102.以上描述旨在是说明性的而不是限制性的。例如，上述示例(或其一个或更多方案)可以彼此组合使用。例如本领域普通技术人员在阅读上述描述时可以使用其它实施例。另外，在上述具体实施方式中，各种特征可以被分组在一起以简单化本公开。这不应解释为一种不要求保护的公开的特征对于任一权利要求是必要的意图。相反，本公开的主题可以
少于特定的公开的实施例的全部特征。从而，以下权利要求书作为示例或实施例在此并入具体实施方式中，其中每个权利要求独立地作为单独的实施例，并且考虑这些实施例可以以各种组合或排列彼此组合。本公开的范围应参照所附权利要求以及这些权利要求赋权的等同形式的全部范围来确定。
103.以上实施例仅为本公开的示例性实施例，不用于限制本公开，本公开的保护范围由权利要求书限定。本领域技术人员可以在本公开的实质和保护范围内，对本公开做出各种修改或等同替换，这种修改或等同替换也应视为落在本公开的保护范围内。