CN103905225B - 一种服务控制方法、服务控制装置以及服务系统 - Google Patents

Abstract

本发明提供了一种服务控制方法、服务控制装置以及服务系统，该方法包括：接收步骤，接收用户发送的外部业务请求；检测步骤，检测是否存在新老不同版本的数据处理子系统；分流控制步骤，在检测步骤检测出存在不同版本的数据处理子系统时，根据预设的分流条件，将外部业务请求分流到不同版本的数据处理子系统中；切换步骤，当新版本数据处理子系统不稳定时，将分流到新版本数据处理子系统的外部业务请求从新版本的数据处理子系统切换到老版本的数据处理子系统。实现了对用户的智能分流控制，保证了升级过程中对新版本服务的全面测试，并能及时切换回退至老版本服务，达到降低系统升级风险的目的。

Description

一种服务控制方法、服务控制装置以及服务系统

技术领域

本发明涉及一种服务控制方法、服务控制装置以及服务系统，特别是涉及移动业务支撑领域以及业务支撑系统设计领域。

背景技术

随着互联网业务模式对传统移动通信业的影响，通讯业务越来越互联网化，传统通讯公司的IT系统建设要逐步适应互联网业务的要求，向移动互联的方向转型，更加强调业务的快速升级和开放互联。但因为电信行业的客户需求的多样性，多年以来沉淀下来的业务功能越来越复杂，系统之间的交叉越来越多，经常会出现系统功能升级后某些功能点异常不能正常使用(如，前台功能异常导致业务无法受理)，或者用户服务感知异常引发大批量的用户投诉(如，后台进程导致批量用户数据错误)。这些问题，不但给用户感知上造成极其不好的印象，也对支撑系统的稳定性和服务连续性产生了很大的冲击。

当前运营商的支撑系统上线都是采用一次性将服务全部升级的方式来操作，为了避免上线后出现问题，通常采用上线前加大测试力度和上线后增加验证测试两种方式。上线前通过大量的测试工作、规范的上线流程来保证版本发布的质量，但因为业务特别复杂，很难保证测试案例涵盖真实用户的所有行为，测试难度大测试周期长；上线后通过自动化回归和人工测试的方式进行验证，但上线后验证测试的时间短，只能保证对重点业务、重点场景的回归验证，无法保证全部业务的回归验证。此外，生产系统上的数据远比测试环境复杂，存在因遗留的bug、或者维护人员人为修改遗留的“脏数据”，这些都是测试环境无法模拟出来的异常情况，因此，即使是在测试环境通过的功能仍然可能在生产环境上出问题。综上所述，每次上线后出现问题的概率很大。

针对上述问题，需要对现有的服务控制方法和服务控制装置以及服务系统进行改进，使之既能保证系统功能正常上线，又尽可能降低系统升级带来的负面影响，把上线的风险限定在一个可控制的范围以内。

通常控制系统升级所带来风险的思路是：控制上线可能影响到的用户。通过事先框定部分目标用户，当这批目标用户在访问系统时，才会使用到新升级的版本功能，而绝大多数的老用户仍然使用老的稳定版本的功能。这样，即使系统升级后出了问题，受到影响的也仅仅是这一小批的目标用户。

然而，对于电信运营商使用的庞大的运营支撑系统而言，基于以上的思路实现上线风险控制的挑战很大。因为电信支撑运营系统的每一次升级除了前台相关操作的新增修改，后台对应的查询、计费、出账、报表、财务等一系列的功能都要做相应的新增或调整，数据表结构也要做调整，涉及的历史数据也很可能要做批量修改或者迁移，上述工作全部顺利完成，才能实现一次完整的从前台到后台版本升级工作。在这种复杂的场景下，如何控制系统升级的影响范围，实现只有极少部分前台营业人员、极少部分的客户才能使用到升级后的服务和功能，绝大部分用户使用的仍然是老版本稳定的服务，同时，当新版本出现不稳定状态时，能及时保证使用新版本的试点用户回退至老版本并能正常使用服务，目前而言尚无有效的解决方案。

发明内容

本发明的实施例提供一种服务控制方法、服务控制装置以及服务系统，当新版本服务内容通过一系列的测试之后，同时部署新老两个版本的生产环境，或者在一个生产环境上同时部署新老两个版本的数据处理子系统，通过分流控制将少部分真实用户的服务请求引导到新版本的生产环境或数据处理子系统上，在观察期内利用真实用户来体验新版本的功能，期间当新版本的生产环境或数据处理子系统出现不稳定的情况时，例如出现问题等，能及时通过分流控制再把这部分用户切换回到老版本的生产环境或数据处理子系统中，避免问题影响的扩大。

具体而言，本发明的实施例涉及一种服务控制方法，包括：接收步骤，接收用户发送的外部业务请求；检测步骤，检测是否存在新老不同版本的数据处理子系统；分流控制步骤，在检测步骤检测出存在不同版本的数据处理子系统时，根据预设的分流条件，将外部业务请求分流到不同版本的数据处理子系统中；切换步骤，当新版本数据处理子系统不稳定时，将分流到新版本数据处理子系统的外部业务请求从新版本的数据处理子系统切换到老版本的数据处理子系统。

本发明的实施例还涉及一种服务控制装置，包括：接收模块，接收用户发送的外部业务请求；检测模块，与接收模块相连，检测是否存在新老不同版本的数据处理子系统；分流控制模块，与检测模块相连，在检测模块检测出存在不同版本的数据处理子系统时，根据预设的分流条件，将外部业务请求分流到不同版本的数据处理子系统中；切换模块，当新版本数据处理子系统不稳定时，将分流到新版本数据处理子系统的外部业务请求从新版本的数据处理子系统切换到老版本的数据处理子系统。

同时，本发明的实施例还涉及一种服务系统，包括：老版本生产子系统，运行老版本的服务；新版本生产子系统，运行新版本的服务；接收装置，接收用户发送的外部业务请求；检测装置，检测是否存在新老不同版本的生产子系统；分流控制装置，在检测模块检测出存在不同版本的生产子系统时，根据预设的分流条件，将外部业务请求分流到不同版本的生产子系统中；切换装置，当新版本生产子系统不稳定时，将分流到新版本生产子系统的外部业务请求从新版本生产子系统切换到老版本生产子系统。

本发明实施例具有如下有益效果中的至少一个：

本发明实施例中，将原本一次系统升级的工作拆分成多步实施，逐步扩大系统升级的范围直至全部升级完成。分流控制根据业务特征将业务请求分流到新老不同版本的生产环境上，确保一部分试点数据运行在新版本的生产环境(服务集群)中；

同时，分流控制还支持快速回切，保证试点期间发现问题后所有业务请求能及时切换回老版本。本发明的实施例能按照预设的分流条件，对用户进行分流，并根据新版本的稳定程度，控制整个版本升级工作的风险。

待验证新的版本符合条件并稳定运行一段时间后，扩大体验用户的范围，逐渐把老的版本替换升级，直到所有的服务全部升级到新版本。解决了传统的升级方法升级复杂，新版本测试不充分，无法及时解决升级故障等问题。因此，本发明实施例中的系统升级方法实现了对用户的智能分流控制，保证了升级过程中对新版本的全面测试，并能及时回退至老版本，达到降低系统升级风险的目的。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，并不构成对本发明的限定。在附图中：

图1是本发明实施例的服务控制装置的示意图；

图2是本发明实施例的服务控制装置的硬件部署框图；

图3是本发明实施例的服务控制方法的示意图；

图4是本发明实施例的服务控制方法的分流控制流程图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚明白，下面结合实施方式和附图，对本发明做进一步详细说明。在此，本发明的示意性实施方式及其说明用于解释本发明，但并不作为对本发明的限定。

本发明将原有系统升级的一次性的工作划分成多次升级的工作，在生产环境保持两套版本的服务集群，控制不同的用户使用不同的系统版本。同时，通过跟踪实际用户的使用情况，验证新版本的功能，监控和收集新版本存在的问题，在新版本稳定后再逐步扩大升级范围，从而达到降低系统升级风险的目的。

图1是本发明服务控制装置的示意图，该服务控制装置包括：

接收模块，接收用户发送的外部业务请求；

检测模块，与接收模块相连，检测是否存在新老不同版本的数据处理子系统；

分流控制模块，与检测模块相连，在检测模块检测出存在不同版本的数据处理子系统时，根据预设的分流条件，将外部业务请求分流到不同版本的数据处理子系统中；

切换模块，当新版本数据处理子系统不稳定时，将分流到新版本数据处理子系统的外部业务请求从新版本的数据处理子系统切换到老版本的数据处理子系统。

具体而言，通过例如计算机终端设备，手机通讯设备或互联网接入端等发出所要办理的业务请求，接收模块接收上述外部业务请求，将其发送至检测模块。这里业务请求来自用户自助办理或营业厅的工作人员人工办理，所发送的业务请求数据中可包含有发起请求的IP地址，用户的手机号码等识别信息。

检测模块接收到从接受模块所发送的业务请求之后，检测办理该项业务请求的数据处理子系统，判断是否同时部署了新老两套版本的数据处理子系统，新版本的数据处理子系统处于测试阶段。检测模块执行如下功能，在只有一套老版本数据处理子系统的服务时，直接执行老版本的服务，不必进行分流控制。如果存在新老两个版本数据处理子系统的服务需要将请求进行分流时，执行分流操作。优选地，当遇到新版本的服务异常时，可以通过切换模块，快速将所有的外部服务请求都切换到老版本数据处理子系统的服务集群上去。

而分流控制模块，与检测模块相连，在检测模块检测出存在新老不同版本的数据处理子系统需要进行分流时，根据预设的分流条件，将外部业务请求分流到不同版本的数据处理子系统中。

当新版本的数据处理子系统不稳定时，切换模块能够将分流到新版本的外部业务请求从新版本的数据处理子系统切换到老版本的数据处理子系统。

分流控制模块能执行自适应的智能分流，根据业务特征将业务请求分流到不同版本的生产环境上，确保试点数据运行在新版本的服务集群中；切换模块支持快速回切策略，保证试点期间发现问题后所有业务请求能及时切换回老版本。

分流控制模块支持预设的分流条件，该分流条件包括静态分流条件和动态分流条件，即可基于静态试点数据，如控制前台试点范围(静态分流条件)，又可在静态试点数据的基础上基于动态试点数据，如随机挑选真实用户作为试点(动态分流条件)，有效保证试点样本的随机性。

本发明实施例中，该服务控制装置还可以包括：

验证模块，与分流控制模块相连，跟踪分流到新版本的用户使用情况的数据，监控和分析新版本的数据处理子系统的数据，进而验证新版本的数据处理子系统是否稳定。

通过验证模块的设置，如网管监控分析系统等及时获取的新版本服务性能信息、试点用户的动态业务分析数据，进而可以设定更加合适的分流条件，影响试点用户的业务分流流向。

本发明实施例中，该服务控制装置还可以包括：

数据迁移模块，与分流控制模块相连，在分流到新版本数据处理子系统的试点用户的外部业务请求被接受后，将该试点用户的历史数据从老版本数据处理子系统迁移到新版本数据处理子系统。

所述数据迁移模块还支持将试点用户的历史数据从新版本回退到老版本的生产环境。版本升级中如涉及到相关用户数据表结构调整，需要先把历史数据转换成新的格式才能保证新版本的运行。本方案不用提前批量迁移数据(大数据量)的方式，而是通过数据迁移模块实现数据的即时迁移；例如：数据结构(格式)的转换，在试点用户的业务请求到达后，触发该试点用户的历史数据迁移(小数据量)，这样，既保证数据迁移的效率，又能保证服务的正常运行。

其中数据迁移模块包括：第一数据迁移模块，在分流到新版本数据处理子系统的试点用户的外部业务请求被接受后，将该试点用户的历史数据从老版本数据处理子系统迁移到新版本数据处理子系统。

第一数据迁移模块将试点用户的历史数据的数据结构，从老版本数据处理子系统的结构形式变化为新版本数据处理子系统的结构形式。

其中数据迁移模块还可以包括：

第二数据迁移模块，当新版本数据处理子系统不稳定时，在切换模块执行切换前，将迁移到新版本数据处理子系统的历史数据迁移到老版本数据处理子系统。

第二数据迁移模块将试点用户的历史数据的数据结构，从新版本数据处理子系统的结构形式变化为老版本数据处理子系统的结构形式，使得回退后还能够基于老版本数据处理子系统提供服务。

新版本数据处理子系统下的服务经验证稳定后，老版本的服务集群将逐步升级加入到新版本的服务集群中，直到全部升级完成。

如图2所示，本实施例采用硬件负载均衡设备来保障各项服务的连续性，除此之外也可以通过软负载均衡前端服务器来保证。新版本的服务集群和老版本的服务集群各自独立，避免相互之间的影响。同时，重构业务调用的实现，调用之前必须先通过“分流控制模块”来决定是调用老版本的业务服务还是新版本的业务服务，从而实现不同版本服务分流调用的目的。这里作为分流模块的一个具体应用，可以采用智能分流引擎。

业务请求首先通分流控制服务集群，由智能分流引擎判断是调用老版本的业务服务接口还是调用新版本的业务服务接口，再由切换模块分别转发到新、老两套不同版本的业务服务集群入口中。智能分流引擎采用不同的分流条件，根据不同的需要设定分流条件，如根据服务请求的报文头格式、根据业务请求的成功率等；同时也能导入相应的数据清单来设定分流条件，如发起请求的IP地址、请求中对应用户手机号码等；这些分流条件的相关数据除了会保存在配置数据库中，同时也会通过缓存的方式保存在内存中以提高访问的效率。同时，实时更新的缓存信息也可以通过接口定期回写到配置数据库中，以保证服务重启后数据不会缺失。智能分流引擎和验证模块的业务监控之间也打通了接口，业务监控的部分分析数据，如调用次数、调用成功率，会实时传递到智能分流引擎，通过分析数据得出的统计信息也能构成基础数据配合形成相应的分流条件来使用，比如，某新版服务调用连续一段时间内失败次数超过一定的阀值，相关的新版本服务都不再被调用；或者某个试点用户调用服务重复失败一定次数后，自动将该用户从试点用户中剔除。

如果新版本上线后发现新版本的服务有缺陷，不需要回退代码，直接通过分流控制模块关闭分流控制，立即把前台请求引导到老版本的服务上，实现升级业务的快速回退，确保服务稳定性。在新版本通过一定时间的验证后，通过调整服务集群策略，将一部分老版本服务集群上的服务升级后加入到新版本服务的集群中来，从而达到逐步将老版本服务升级的目标。因为整个升级过程中，新服务已经经过了真实用户的验证，且在升级过程中都有新老两个版本同时保障，遇到问题可以快速回退，从而有效控制了系统升级的风险。

在不同版本服务并存的环境中，需要不同数据结构版本。因为不同版本的服务可以通过生产环境部署来解决，此时如果后台数据也要随之改变，在数据批量更新、同步上的压力会非常大，而且这种复杂的环境反而增加了上线升级的风险。本实施例实现的数据迁移模块，支持正反双向的即时数据迁移。其中的第一数据迁移模块将试点用户的历史数据的数据结构，从老版本数据处理子系统的结构形式变化为新版本数据处理子系统的结构形式；第二数据迁移模块将试点用户的历史数据的数据结构，从新版本数据处理子系统的结构形式变化为老版本数据处理子系统的结构形式。通过触点式的数据迁移方式，在试点用户的业务请求到达后才触发该用户的历史数据迁移，以单用户的数据迁移保证迁移的工作效率，迁移成功后才能使用新版本服务，保证服务正常运行。即时数据迁移装置除支持正向的升级迁移，也支持反向的降级迁移脚本，用于试点用户回退时数据的迁移。

如图3所示，本发明的一种服务控制方法，包括：

接收步骤，接收用户发送的外部业务请求；

检测步骤，检测是否存在新老不同版本的数据处理子系统；

分流控制步骤，在检测步骤检测出存在不同版本的数据处理子系统时，根据预设的分流条件，将外部业务请求分流到不同版本的数据处理子系统中；

切换步骤，当新版本数据处理子系统不稳定时，将分流到新版本数据处理子系统的外部业务请求从新版本的数据处理子系统切换到老版本的数据处理子系统。

当然，还可以包括：

验证步骤，跟踪分流到新版本的用户使用情况的数据，监控和分析新版本的数据处理子系统的数据，及时获取新版本的服务性能信息，进而验证新版本的数据处理子系统是否稳定。

其中预设的分流条件一方面能根据静态试点数据和/或动态试点数据来设定，另一方面还能根据验证步骤的验证数据来设定分流条件。

而由于新旧版本数据处理子系统的数据结构方面的差异，还应该设置：数据迁移步骤，在分流到新版本的试点用户的外部业务请求被接受后，触发该试点用户的历史数据从老版本迁移到新版本的数据处理子系统。

其中的数据迁移步骤包括双反向的迁移，即包括：

第一数据迁移步骤，在分流到新版本数据处理子系统的试点用户的外部业务请求被接受后，将该试点用户的历史数据从老版本数据处理子系统迁移到新版本数据处理子系统；

第二数据迁移步骤，当新版本数据处理子系统不稳定时，在切换步骤执行前，将迁移到新版本数据处理子系统的历史数据迁移到老版本数据处理子系统。

第一数据迁移步骤将试点用户的历史数据的数据结构，从老版本数据处理子系统的结构形式变化为新版本数据处理子系统的结构形式。而第二数据迁移步骤将试点用户的历史数据的数据结构，从新版本数据处理子系统的结构形式变化为老版本数据处理子系统的结构形式。

如图4所示，给出了一种服务控制方法的具体实施方式的流程图，按照步骤详细阐述如下。

步骤301：接收外部业务请求。

步骤302：判断是否部署了新老两套版本的服务，是否需要根据业务特征将业务请求引导到新版本的服务集群中。若是，执行步骤303，若否，执行步骤311。

步骤302能执行控制操作，在只有一套老版本的服务时，该分流控制关闭，直接调用老版本服务；如果存在新老两个版本的服务集群，遇到新版本的服务异常时，可以及时改变，快速将所有的外部服务请求都切换到老版本的服务集群上去。

步骤303：根据业务请求报文中的属性标志，和缓存在内存中的分流条件和数据进行比较，判断应该调用哪个版本的服务。

根据运营商业务的特点，新业务升级要会先受到控制，只有个别营业厅、个别前台席才能使用，这样，一般先配置以营业台席的IP地址作为分流条件，从这些IP地址发送上来的业务请求才会可能被分流到新版本，这样，其他绝大部分的台席都仍然使用老版本。如果验证新版本服务不稳定，不会出现无法响应请求或请求失败等情形，影响服务效果和用户体验。

这里的分流条件并不是只有IP地址一种，还可以包括用户的手机号码、账户编号等关键信息，这些数据可以提前导入，这就意味着这批提前导入的用户将作为试点的用户，在业务受理、查询等功能上使用新版本的功能。如果没有提前导入，分流条件也可以与关联设置和/或关联数据配合，当试点IP的台席受理了某个用户的业务，那这个用户自然就作为试点用户，去验证后续的其他功能是否正常。这种关联设置加大了试点用户的随机性，避免了提前选择试点客户做验证测试的片面性。实现分流条件的实时关联刷新，透明引入试点用户。如前台功能试点的使用人员通过新功能操作过的用户将作为试点用户，参与验证后续一系列查询、计费等后台功能，避免因目标用户的选取出现偏差而导致功能验证的不全面。

因为试点的分流条件和目标用户数据都是缓存在内存中，为了避免内存数据太大效率低下并且可能溢出，可以设置试点目标用户的数量，比如1000，当达到这个量值以后，后续受理的用户就不再作为试点用户去验证新版本服务，而是去调用老版本的服务。

此外，针对新版本服务调用的情况，如调用次数、调用成功率等等数据，有专属的验证模块和验证步骤来监控系统或服务，获取相关的统计信息，这些统计信息也将能构成分流条件所需的参考数据，比如，某新版服务调用连续一段时间内失败次数超过一定的阀值，相关的新版本服务都不再被调用；或者某个试点用户调用服务重复失败一定次数后，自动将该用户从试点用户中剔除。

步骤304：判断是否要调用新版本的服务？如是，执行步骤305；如否，执行步骤311。

步骤305：判断是否包含数据迁移？如是，执行步骤306；如否，执行步骤307。

有时，新版本的服务还依赖于新的数据结构，在传统的版本升级工作中需要同步完成用户数据的割接迁移。但在本方案中，因为试点用户选择的随机性，所以没有办法做到提前迁移数据，所以要配置新服务调用前的数据迁移依赖关系。必须在数据迁移完成后，才能调用新版本的服务。

步骤306：调用数据迁移服务，升级单个用户的数据。升级完成后，执行步骤307。

步骤307：调用新版本的服务。服务调用成功，执行步骤308。

步骤308：判断新版本服务是否调用成功？如是，执行步骤309；如否，执行步骤313；

步骤309：调用关联设置和/或关联数据更新分流条件，刷新缓存。

开始只有试点IP地址的静态数据，在受理完成某个业务后，该用户的数据，如手机号码、账户编号等动态数据也要被刷新到分流数据中。这里，一般采用内存数据库，如memcache技术，以保证缓存更新的效率。这里是异步调用缓存刷新的服务，不用等待缓存刷新结果返回，即可执行步骤310。

当下一次该用户访问系统时(不单单是通过试点IP地址来办理业务，也可能是查询余额、缴费等其他业务)，因为该试点用户的分流数据已经保存在缓存中，后台调用的都将是新版本的服务集群对应的服务。

步骤310：应答服务请求，告知服务调用成功。

步骤311：如果在步骤302、或者在步骤304中判断不需要调用新服务，则调用老版本服务。

步骤312：判断老版本服务是否调用成功？如是，执行步骤310；如否，执行步骤313；

本发明实施例还提供一种服务系统的示意图，包括：老版本生产子系统，运行老版本的服务；新版本生产子系统，运行新版本的服务；接收装置，接收用户发送的外部业务请求；检测装置，检测是否存在新老不同版本的生产子系统；分流控制装置，在检测模块检测出存在不同版本的生产子系统时，根据预设的分流条件，将外部业务请求分流到不同版本的生产子系统中；切换装置，当新版本生产子系统不稳定时，将分流到新版本生产子系统的外部业务请求从新版本生产子系统切换到老版本生产子系统。

在新老版本的生产子系统可以提供不同的服务，老版本的生产子系统按照原有的服务模式来响应用户的业务请求，新版本的生产子系统按照升级后的新的服务模式来响应用户的业务请求，以适应日益发展的业务需要。新老版本的生产子系统不限于包括数据处理子系统，还可以包括多个服务提供者组成的联合服务系统等。

当通过分流控制装置将业务请求分流到某个服务提供者，其所属的服务系统不稳定时，导致该生产环境下无法提供服务时，还可以由切换装置将用户的业务请求切换回其他的服务提供者，从而保证了服务的连续性，提高了用户的使用体验感受。

该服务系统，还可包括上述服务控制装置实施例中的其他模块，还可执行上述服务控制方法实施例中的各个流程，这里不再赘述。

本发明的实施例从根本上改变了现有系统升级发布的策略(要升级全升级，要回退全回退)，通过智能分流引擎随机动态选取新版本的试点范围，缩小了错误的可能的波及范围，充分验证新版本服务的稳定性和可靠性后再将老版本服务逐步升级直至全部升级完成，有效降低了系统升级的风险。

此外，对于数据处理子系统或生产环境的数量不应仅仅局限于实施例中所述的两个，本发明中的升级系统同样可以用于同时存在多个数据处理子系统或生产环境的情形，根据系统测试需求，将外部业务请求分流至多个不同版本的数据处理子系统或生产环境中，进而同时可以对多个数据处理子系统或生产环境进行测试，选取合适稳定版本的生产环境，完成服务升级。

以上所述的具体实施方式，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施方式而已，并不用于限定本发明的保护范围，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (13)

1.一种服务控制方法，其特征在于，包括：

接收步骤，接收用户发送的外部业务请求；

检测步骤，检测办理该项外部业务请求的数据处理子系统是否存在新老不同版本的数据处理子系统；

分流控制步骤，在检测步骤检测出存在不同版本的数据处理子系统时，根据预设的分流条件，将外部业务请求分流到不同版本的数据处理子系统中；

切换步骤，当新版本数据处理子系统不稳定时，将分流到新版本数据处理子系统的外部业务请求从新版本的数据处理子系统切换到老版本的数据处理子系统。

2.根据权利要求1所述的服务控制方法，其特征在于，还包括：

验证步骤，跟踪和统计分流到新版本数据处理子系统的用户使用情况的数据，监控和分析新版本数据处理子系统的数据，以及时获取新版本数据处理子系统的服务性能信息，进而验证新版本数据处理子系统是否稳定。

3.根据权利要求1所述的服务控制方法，其特征在于，所述分流控制步骤，根据静态试点数据和/或动态试点数据来设定分流条件。

4.根据权利要求2所述的服务控制方法，其特征在于，所述分流控制步骤，根据验证步骤的验证数据来设定分流条件。

5.根据权利要求1或2所述的服务控制方法，其特征在于，还包括：

第一数据迁移步骤，在分流到新版本数据处理子系统的用户的外部业务请求被接受后，将用户的历史数据从老版本数据处理子系统迁移到新版本数据处理子系统。

6.根据权利要求5所述的服务控制方法，其特征在于，还包括：

第二数据迁移步骤，当新版本数据处理子系统不稳定时，在切换步骤执行前，将迁移到新版本数据处理子系统的历史数据迁移到老版本数据处理子系统。

7.一种服务控制装置，其特征在于，包括：

接收模块，接收用户发送的外部业务请求；

检测模块，与接收模块相连，检测办理该项外部业务请求的数据处理子系统是否存在新老不同版本的数据处理子系统；

分流控制模块，与检测模块相连，在检测模块检测出存在不同版本的数据处理子系统时，根据预设的分流条件，将外部业务请求分流到不同版本的数据处理子系统中；

切换模块，当新版本数据处理子系统不稳定时，将分流到新版本数据处理子系统的外部业务请求从新版本的数据处理子系统切换到老版本的数据处理子系统。

8.根据权利要求7所述的服务控制装置，其特征在于，还包括：

验证模块，与分流控制模块相连，跟踪和统计分流到新版本数据处理子系统的用户使用情况的数据，监控和分析新版本数据处理子系统的数据，以及时获取新版本数据处理子系统的服务性能信息，进而验证新版本数据处理子系统是否稳定。

9.根据权利要求8所述的服务控制装置，其特征在于：所述分流控制模块，根据静态试点数据和/或动态试点数据来设定分流条件。

10.根据权利要求8所述的服务控制装置，其特征在于：所述分流控制模块，根据验证模块的验证数据来设定分流条件。

11.根据权利要求7或8所述的服务控制装置，其特征在于，还包括：

第一数据迁移模块，在分流到新版本数据处理子系统的试点用户的外部业务请求被接受后，将该试点用户的历史数据从老版本数据处理子系统迁移到新版本数据处理子系统。

12.根据权利要求11所述的服务控制装置，其特征在于，还包括：

第二数据迁移模块，当新版本数据处理子系统不稳定时，在切换模块执行切换前，将迁移到新版本数据处理子系统的历史数据迁移到老版本数据处理子系统。

13.一种服务系统，其特征在于，包括：

老版本生产子系统，运行老版本的服务；

新版本生产子系统，运行新版本的服务；

接收装置，接收用户发送的外部业务请求；

检测装置，检测办理该项外部业务请求的数据处理子系统是否存在新老不同版本的生产子系统；

分流控制装置，在检测模块检测出存在不同版本的生产子系统时，根据预设的分流条件，将外部业务请求分流到不同版本的生产子系统中；

切换装置，当新版本生产子系统不稳定时，将分流到新版本生产子系统的外部业务请求从新版本生产子系统切换到老版本生产子系统。