CN112968954B

CN112968954B - Flow control method, server and system for service migration

Info

Publication number: CN112968954B
Application number: CN202110182970.8A
Authority: CN
Inventors: 廖过房; 陈静国; 杨帅; 张�浩
Original assignee: Industrial and Commercial Bank of China Ltd ICBC
Current assignee: Industrial and Commercial Bank of China Ltd ICBC
Priority date: 2021-02-10
Filing date: 2021-02-10
Publication date: 2023-04-07
Anticipated expiration: 2041-02-10
Also published as: CN112968954A

Abstract

The application provides a flow control method, a server and a system for service migration, which can be used in the financial field or other fields, and the method comprises the following steps: the method comprises the steps that a first server migrates source codes corresponding to at least one service to a second server, a flow controller identifies all current scenes according to a call chain and segments all the current scenes to obtain a first current scene call group and a second current scene call group, the first server executes the first current scene call group, the second server executes the second current scene call group, one or more services are used for achieving a set scene, call fields are stored in data packets of each service, the call fields of all the services for achieving the scene are connected in series to form a call chain, different call chains correspond to different scenes, a caller system does not need to be modified, the scenes are identified through the call chains, the specific scenes can be directly located, accurate control of service call is achieved, and intelligent flow control is achieved.

Description

Flow control method, server and system for service migration

Technical Field

The application relates to the field of finance, in particular to a flow control method, a server and a system for service migration.

Background

The IT system construction of a new generation of financial institution is to extract 'service' on the basis of the carding of business processes, the service of an obstructed level is the basic element of the IT system, and the construction and the closed loop of business functions are realized among various applications and inside the applications through service calling.

For service providers, especially basic services, there are very many callers, and it is not easy to precisely manage the invoker without intruding into the invoker system. Such as a customer information management application, provides a common service for basic information queries of customers, which is invoked by thousands of scenarios of hundreds of applications throughout the application system.

The difficulty in accurately managing the service invoker is: the bank itself lacks a clear definition of the "scenario" and also lacks an effective mechanism to manage the scenario. The current call side management depends on that a project relates to a process that calls a service call registration ledger, for example, an application A calls a service B of an application B, which actually has 10 scenes, but the application A only registers 1 call relation (namely only records one scene), so that the call relation is inaccurate, and the user cannot know how many scenes actually exist.

When a bank system carries out large-scale host downloading (migration from a host to a development platform system) engineering, original host service needs to be switched to platform service, and the condition of a calling party needs to be accurately mastered when the process needs to ensure stable production.

Disclosure of Invention

Aiming at the problems in the prior art, the application provides a flow control method, a server and a system for service migration, so that a provider of a service can accurately identify scenes, and the accurate and intelligent control of service calling is realized.

In order to solve the technical problem, the application provides the following technical scheme:

in a first aspect, the present application provides a traffic control method for service migration, which is executed by a first server, where the first server hosts a first application system, and the first application system includes at least one service thereon; one or more services are used to implement a set scenario; the flow control method comprises the following steps:

migrating a source code corresponding to the at least one service to a second server;

executing a first current scene call group; wherein the second server executes a second current scene call group;

the first current scene calling group and the second current scene calling group are obtained by segmenting all current scenes through a flow controller; the scene name is represented by a call chain, the call chain comprises call fields for realizing all services of the scene, and the flow controller identifies all current scenes according to the call chain.

In a second aspect, the present application provides a flow control method for service migration, which is executed by a second server, where the second server hosts a second application system, and the second application system includes at least two services; one or more services are used to implement a set scenario; the flow control method comprises the following steps:

receiving a source code corresponding to at least one service migrated by a first server;

executing the second current scene call group; wherein the first server executes a first current scene call group;

In a third aspect, the present application provides a traffic control method for service migration, which is executed by a traffic controller, where a first server hosts a first application system, and the first application system includes at least one service; the second server carries a second application system, and the second application system comprises at least two services; one or more services are used to implement a set scenario; the flow control method comprises the following steps:

identifying all current scenes according to a call chain, wherein the scene name is represented by the call chain, and the call chain comprises call fields for realizing all services of the scene;

segmenting all current scenes to obtain a first current scene calling group and a second current scene calling group;

and sending the first current scene call group to a first server, and sending the second current scene call group to a second server.

Further, the segmenting all current scenes to obtain a first current scene call group and a second current scene call group includes:

and adjusting the flow ratio of the first current scene call group and the second current scene call group in all scenes, so that the flow of the first current scene call group is gradually reduced, and the flow of the second current scene call group is gradually increased.

Further, the segmenting all the current scenes to obtain a first current scene call group and a second current scene call group includes:

and equivalently reducing the flow of the first current scene call group, equivalently increasing the flow of the second current scene call group, further gradually reducing the flow of the first current scene call group, and gradually increasing the flow of the second current scene call group.

In a fourth aspect, the present application provides a traffic control system for service migration, where a first server hosts a first application system, and the first application system includes at least one service; the second server carries a second application system, and the second application system comprises at least two services; one or more services are used to implement a set scenario; the flow control system includes:

a first server migrating a source code corresponding to the at least one service to a second server; executing a first current scene call group; wherein the second server executes a second current scene call group;

the second server receives a source code corresponding to at least one service migrated by the first server; executing the second current scene call group; wherein the first server executes a first current scene call group;

the flow controller identifies all current scenes according to the call chain; segmenting all current scenes to obtain a first current scene calling group and a second current scene calling group; sending the first current scene calling group to a first server, and sending the second current scene calling group to a second server;

wherein the scene name is represented by a call chain comprising call fields for all services implementing the scene.

Further, the flow control system further includes:

a distributed service platform (DSF) to register the service and a call record for the scene.

In a fifth aspect, the present application provides a first server hosting a first application system, the first application system including at least one service thereon; one or more services are used to implement a set scenario; the first server includes:

a service migration module: migrating a source code corresponding to the at least one service to a second server;

the first scene calling module: executing a first current scene call group; wherein the second server executes a second current scene call group;

In a sixth aspect, the present application provides a second server, where the second server hosts a second application system, and the second application system includes at least two services; one or more services are used to implement a set scenario; the second server includes:

a service receiving module: receiving a source code corresponding to at least one service migrated by a first server;

a second scene calling module: executing the second current scene call group; wherein the first server executes a first current scene call group;

In a seventh aspect, the present application provides a traffic controller, where the first server hosts a first application system, and the first application system includes at least one service; the second server carries a second application system, and the second application system comprises at least two services; one or more services are used to implement a set scenario; the flow controller includes:

a scene recognition module: identifying all current scenes according to a call chain, wherein the scene name is represented by the call chain, and the call chain comprises call fields for realizing all services of the scene;

a scene segmentation module: segmenting all current scenes to obtain a first current scene calling group and a second current scene calling group;

a scene sending module: and sending the first current scene call group to a first server, and sending the second current scene call group to a second server.

In an eighth aspect, the present application provides a flow control system for service migration, where the first server hosts a first application system, and the first application system includes at least one service; the second server carries a second application system, and the second application system comprises at least two services; one or more services are used to implement a set scenario; the flow control system includes:

the first server migrates the source code corresponding to the at least one service to the second server; executing a first current scene call group; wherein the second server executes a second current scene call group;

Further, the flow control system further includes:

calling a recording module: the call record module includes a distributed service platform (DSF) for registering call records of the service and the scenario.

In a ninth aspect, the present application provides an electronic device, comprising a memory, a processor and a computer program stored on the memory and executable on the processor, wherein the processor implements the method for controlling flow rate when executing the program.

In a tenth aspect, the present application provides a computer-readable storage medium having stored thereon a computer program which, when executed by a processor, implements the flow control method.

According to the technical scheme, the flow control method, the server and the system for service migration provided by the application comprise the following steps: the method comprises the steps that a first server migrates source codes corresponding to at least one service to a second server, one or more services are used for achieving a set scene, a calling field is stored in a data packet of each service, calling fields of all services achieving the scene are concatenated to form a calling chain, a flow controller identifies all current scenes according to the calling chain and divides all the current scenes to obtain a first current scene calling group and a second current scene calling group, the first server executes the first current scene calling group, and the second server executes the second current scene calling group; the calling fields are stored in the data packet of each service, the calling fields form calling chains of set scenes, different calling chains correspond to different scenes, a calling party system does not need to be modified in the migration process, specific scenes can be directly located, the scenes are identified through the calling chains, flow control is carried out on the scenes through cooperation with the flow controllers, and accurate control and intelligent flow control of service calling can be achieved.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings needed to be used in the description of the embodiments or the prior art will be briefly introduced below, and it is obvious that the drawings in the following description are some embodiments of the present application, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without creative efforts.

Fig. 1 is a schematic view of a service migration flow in a flow control method for service migration in an embodiment of the present application.

Fig. 2 is a schematic diagram of a service receiving flow in a flow control method for service migration in an embodiment of the present application.

Fig. 3 is a schematic flow chart of flow segmentation in the flow control method for service migration in the embodiment of the present application.

Fig. 4 is a schematic flow chart of a traffic control system for service migration in an embodiment of the present application.

Fig. 5 is a schematic view of a scene call chain in a traffic control method for service migration in the embodiment of the present application.

Fig. 6 is a schematic structural diagram of a first server in an embodiment of the present application.

Fig. 7 is a schematic structural diagram of a second server in an embodiment of the present application.

Fig. 8 is a schematic structural diagram of a flow controller in an embodiment of the present application.

Fig. 9 is a schematic structural diagram of a flow control system for service migration in an embodiment of the present application.

Fig. 10 is a schematic structural diagram of an electronic device in an embodiment of the present application.

Detailed Description

In order to make the objects, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are some embodiments of the present application, but not all embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.

It should be noted that the flow control method, the server, and the system for service migration disclosed in the present application may be used in the financial field, and may also be used in any field other than the financial field.

In the prior art, the difficulty of accurately managing a service caller is as follows: the bank itself lacks a clear definition of the "scenario" and also lacks an effective mechanism to manage the scenario. The current call side management depends on the requirement of calling a service call registration ledger in the project related process, for example, an application A calls a service B of an application B, and there are actually 10 scenes, but the application A only registers 1 call relation (namely only records one scene), so the call relation is inaccurate, and how many scenes actually exist cannot be known. When a current bank system carries out large-scale 'host computer downloading' (migration from a host computer to a development platform system) engineering, original host computer service is switched to platform service, the condition of a calling party must be accurately mastered in the process of ensuring stable production.

Based on the foregoing, the present application further provides a flow control system for implementing the flow control method provided in one or more embodiments of the present application, where the flow control system may be in communication connection with a plurality of client terminal devices, and the flow control system may specifically access the client terminal devices through an application server.

The flow control system can transmit flow data of the first server and the second server to the client terminal device, the client terminal device is a device carrying a flow control and analysis program, and the client terminal analyzes scene flow according to the flow data provided by the flow control system and judges whether the flow sum of all calling services in the service migration process is stable.

It is to be appreciated that the client devices may include smart phones, tablet electronic devices, portable computers, desktop computers, personal Digital Assistants (PDAs).

The client device may have a communication module (i.e., a communication unit) that may be communicatively connected to a remote flow control system to implement data transmission with the server. For example, the communication unit may transmit a traffic analysis result of all the invoked services from the client terminal device to the traffic control system, so that the traffic control system performs scene traffic adjustment according to the traffic analysis result.

The traffic control system and the client devices may communicate using any suitable network protocol, including network protocols not yet developed at the filing date of this application. The network protocol may include, for example, a TCP/IP protocol, a UDP/IP protocol, an HTTP protocol, an HTTPS protocol, or the like. Of course, the network Protocol may also include, for example, an RPC Protocol (Remote Procedure Call Protocol), a REST Protocol (Representational State Transfer Protocol), and the like used above the above Protocol.

According to the flow control method, the flow control system, the flow control device, the electronic equipment and the computer readable storage medium for service migration, the calling fields are stored in the data packet of each service, the calling fields form calling chains for setting scenes, different calling chains correspond to different scenes, a calling party system does not need to be modified, specific scenes can be directly located, in the migration process, the scenes are identified through the calling chains, meanwhile, flow control is conducted on the scenes by matching with a flow controller, and accurate control and intelligent flow control of service calling can be achieved.

The following embodiments and application examples are specifically and individually described.

When a bank system carries out large-scale host-off (migration from a host to a development platform system) engineering, original host service needs to be switched to platform service, and the condition of a calling party needs to be accurately mastered when the process ensures stable production. In order to solve the problem, in a first aspect, the present application provides a traffic control method for service migration, referring to fig. 1, executed by a first server hosting a first application system including at least one service thereon; one or more services are used for realizing a set scene, and the flow control method specifically comprises the following contents:

step 100: and migrating the source code corresponding to the at least one service to a second server.

It can be understood that migrating the source code corresponding to the at least one service to the second server may be directly migrating at least one service in the first application system hosted by the first server to the second server, or integrating a plurality of services into a new service in the second server; for example, "original service 1", "original service 2", and "original service 3" on the original host system are all services with similar functions (customer basic information query), and are integrated into "new service 1" after being migrated to the development platform.

Step 101: executing the first current scene call group; wherein the second server executes a second current scene call group.

It is understood that, during the migration process, the three services exist simultaneously for a period of time, and the grayscale cut is a stepwise switching process, that is, the flow rate of at least one service in the first server decreases stepwise, and the flow rate of at least one service in the second server increases stepwise, so that two different scene call groups are executed on the first server and the second server, respectively.

It will be appreciated that call chains are used to distinguish and define scenarios. The call chain is in the format of "(application name 1+ program class name 1) > (application name 2+ program class name 2) > (application name 3+ program class name 3) > (application name n + program class name n)". The service calling data packet is divided into a data packet header and a data packet body. The data packet header contains technical fields supporting service invocation, and the data packet body is fields related to the service logic of the service. The data packet header has a reserved space to support the custom field, and a calling link field is added to store the calling link, as shown in table 1 below.

TABLE 1

Referring to fig. 5, as an example, the customer information application provides a customer basic information inquiry service called a "cash withdrawal service" and a "personal transfer service" of the personal financial transaction application, which are called a "cash withdrawal transaction" and a "personal transfer transaction" of a new terminal, a "registered account transfer" and a "transfer remittance" of a mobile phone bank, respectively. In this example, four scenarios can be defined, respectively:

(F-SOCT+CashDraw)>(F-PRAS+CashDrawSv)>(F-ECIS+QryPersonComInfo)、(F-SOCT+PersonTransf)>(F-PRAS+PersonTransfSv)>

(F-ECIS+QryPersonComInfo)、

(F-WABP+LclTransf)>(F-PRAS+PersonTransfSv)>

(F-ECIS+QryPersonComInfo)、

(F-WABP+ComTransf)>(F-PRAS+PersonTransfSv)>

(F-ECIS+QryPersonComInfo)。

it can be known from the foregoing description that, according to the flow control method for service migration provided in the embodiment of the present application, a call field is stored in a data packet of each service, where the call field forms a call chain for setting a scene, and different call chains correspond to different scenes, and a caller system does not need to be modified, and can be directly located in a specific scene.

In a second aspect, the present application provides a traffic control method for service migration, which is executed by a second server, referring to fig. 2, where the second server hosts a second application system, and the second application system includes at least two services; one or more services are used to implement a set scenario; the flow control method specifically comprises the following steps:

step 200: receiving a source code corresponding to at least one service migrated by a first server;

it can be understood that the receiving of the source code corresponding to the at least one service migrated from the first server may be directly receiving, by the second server, the at least one service in the first server, or integrating the at least one service received from the first server into a new service; for example, "original service 1", "original service 2", and "original service 3" on the original host system are all services (customer basic information query) with similar functions, and are integrated into "new service 1" after being migrated to the development platform.

Step 201: executing the second current scene call group; wherein the first server executes a first current scene call group;

it is understood that, during the migration process, the three services exist simultaneously for a period of time, and the grayscale switching is a gradual switching process, that is, the flow of at least one service in the first server decreases gradually, and the flow of at least one service in the second server increases gradually, so that two different scene call groups are respectively executed on the first server and the second server.

It will be appreciated that call chains are used to distinguish and define scenarios. The call chain is in the format of "(application name 1+ program class name 1) > (application name 2+ program class name 2) > (application name 3+ program class name 3) > (application name n + program class name n)". The service calling data packet is divided into a data packet header and a data packet body. The data packet head contains the technical field supporting the service call, and the data packet body is the field related to the service logic of the service. The data packet header has a reserved space to support the custom field, and a calling link field is added to store the calling link, as shown in table 1.

Referring to fig. 5, as an example, the customer information application provides a customer basic information inquiry service called a "cash withdrawal service" and a "personal transfer service" of the personal financial transaction application, which are called a "cash withdrawal transaction" and a "personal transfer transaction" of a new terminal, a "registered account transfer" and a "transfer remittance" of a mobile phone bank, respectively. Taking the ' registered account transfer ' of a mobile banking as an example, when the function calls the ' personal transfer service ', the calling link field is (F-WABP + LcTransf) > (F-PRAS + PersonTransfSv), ' and when the ' personal transfer service ' further calls the ' customer basic information query service ', the calling link field is (F-WABP + LcTransf) > (F-PRAS + PersonTransfSv) > (F-ECIS + QryPersonComInfo) ".

As can be seen from the above description, according to the flow control method for service migration provided in the embodiment of the present application, the call field is stored in the data packet of each service, the call field forms a call chain for setting a scene, different call chains correspond to different scenes, a caller system does not need to be modified, a specific scene can be directly located, during the migration process, the scene is identified through the call chain, and meanwhile, the flow control is performed on the scene in cooperation with the flow controller, so that accurate control of service call and intelligent flow control can be achieved.

In a third aspect, the present application provides a traffic control method for service migration, which is executed by a traffic controller, and the first server hosts a first application system, where the first application system includes at least one service; the second server carries a second application system, and the second application system comprises at least two services; one or more services are used to implement a set scenario; the flow control method comprises the following steps:

step 300: identifying all current scenes according to a call chain, wherein the scene name is represented by the call chain, and the call chain comprises call fields for realizing all services of the scene;

it will be appreciated that call chains are used to distinguish and define scenarios. The call chain is in the format of "(application name 1+ program class name 1) > (application name 2+ program class name 2) > (application name 3+ program class name 3) > (application name n + program class name n)". The data packet for service call is divided into a data packet header and a data packet body. The data packet head contains the technical field supporting the service call, and the data packet body is the field related to the service logic of the service. The data packet head has a reserved space and supports a custom field, a calling link field is added for storing calling links, different calling links correspond to different scenes, and the flow controller identifies all current scenes through the calling links.

Step 301: segmenting all current scenes to obtain a first current scene calling group and a second current scene calling group;

it is to be understood that during the migration process, at least one service on the first server and at least one service migrated to the second server are concurrent for a period of time, and the grayscale switching is a stepwise switching process. I.e. the traffic of at least one service on a first server decreases step by step and the traffic of at least one service migrated to a second server increases step by step, but the total amount of traffic on both servers should remain stable. Then, when monitoring the flow, the following requirements are met:

1) Traffic of the at least one service on the first server and the at least one service migrated to the second server, respectively, is monitored, and changes in traffic must be consistent with the cut flow plan.

2) The sum of the traffic of the at least one service on the first server and the at least one service migrated to the second server is monitored, which should be kept stable.

3) When any one of the at least one service on the first server and the at least one service migrated to the second server is monitored to be greatly changed in trip, whether the sum of the traffic of the two servers is stable or not is immediately judged.

Therefore, the flow controller segments all scenes to obtain a first current scene call group and a second current scene call group, and the flow of the first current scene call group and the flow of the second current scene call group are gradually changed.

Step 302: and sending the first current scene call group to a first server, and sending the second current scene call group to a second server.

It can be understood that, the flow controller sends the first current scene call group and the second current scene call group after being cut to the first server and the second server for execution until the flow on the first server gradually becomes zero and the flow on the first server gradually reaches the sum of the flows.

As can be seen from the above description, in the migration process, the flow controller identifies a scene through the call chain, and different call chains correspond to different scenes, so that the system of the calling party is not required to be modified, the specific scene can be directly located, the scene is accurately managed and finely switched, and the stable operation of the system is ensured while the user experience is kept unchanged.

The application provides a flow control method for service migration, which is used for segmenting all current scenes to obtain a first current scene calling group and a second current scene calling group and comprises the following steps:

It can be understood that the flow rates of the first current scene call group and the second current scene call group are segmented according to the proportion until the flow rate of the first current scene call group gradually becomes zero and the flow rate of the second current scene call group gradually reaches the total flow rate; for example, assuming that the sum of the traffic of all scenes before the call is 100, the traffic controller adjusts the traffic ratio of the first current scene call group and the second current scene call group to 9:1, gradually adjusting the flow ratio of the first current scene call group to the second current scene call group to 1: and 9, finally gradually adjusting the flow of the first current scene call group to 0, gradually adjusting the flow of the second current scene call group to 100, and controlling the scene flow as shown in the following table 2.

TABLE 2

As can be seen from the above description, in the flow control method for service migration provided in the embodiment of the present application, the flow controller changes the flow proportion of the call scenario to perform accurate management and fine stream switching on the scenario, and ensures stable system operation while maintaining the customer experience unchanged.

It can be understood that, the flow rates of the first current scene call group and the second current scene call group are increased or decreased according to a certain flow rate until the flow rate of the first current scene call group gradually becomes zero and the flow rate of the second current scene call group gradually reaches the sum of the flow rates; for example, assuming that the sum of the flow rates of all scenes before call is 100, the flow controller adjusts the flow rate of the first current scene call group to 10, adjusts the flow rate of the second current scene call group to 90, and gradually adjusts the flow rate of the first current scene call group to 0 and the flow rate of the second current scene call group to 100 in units of 10 flow rates, where the scene flow control parameters are shown in table 2.

As can be seen from the above description, in the migration process, the flow controller accurately manages and finely switches the flow of the call scenario by changing the flow proportion of the call scenario, and ensures stable system operation while maintaining the customer experience unchanged.

In a fourth aspect, an embodiment of the present application provides a flow control system for service migration, and referring to fig. 4, the first server hosts a first application system, where the first application system includes at least one service thereon; the second server carries a second application system, and the second application system comprises at least two services; one or more services are used to implement a set scenario; the flow control system includes:

It can be understood that the source code corresponding to the at least one service is migrated to the second server, one or more services are used to implement a set scenario, different call chains correspond to different scenarios, the flow controller identifies the scenarios according to the call chains, further divides all identified scenarios to obtain a first current scenario call group and a second current scenario call group, and sends the first current scenario call group and the second current scenario call group to the first server and the second server for execution, and simultaneously adjusts the flows of the first current scenario call group and the second current scenario call group according to a scenario flow control table and an associated scenario definition table until the flow on the first server gradually becomes zero, the flow on the first server gradually reaches the total flow, and the associated scenario definition table is shown in table 3 below.

TABLE 3

It can be known from the foregoing description that, according to the flow control system for service migration provided in the embodiment of the present application, a call field is stored in a data packet of each service, where the call field forms a call chain for setting a scene, and different call chains correspond to different scenes, and a calling party system does not need to be modified, and can be directly located in a specific scene.

The embodiment of the present application provides a flow control system for service migration, further including:

It can be understood that the principle of the distributed service platform (DSF) is that a server issues a service to register zookeeper, a client calls the service issued by the server to a zookeeper registration center, and the distributed service platform (DSF) is a basic platform for managing the call between services and is responsible for registering the service, registering the service call relationship, and the like.

The following describes a flow control system for service migration according to the present application with reference to specific examples.

Step 501: the channel end needs to call the product function and call the registration center of the DSF platform to obtain the address information of the product.

Step 502: and the channel terminal function calls the product service.

Step 503: and the product service calls a registration center of the DSF platform to acquire address information of the basic service.

Step 504: product service, call basic service.

Step 505: all services of the basic application are externally connected through an access layer, the access layer acquires scene information from a calling link field of a data packet header and calls a flow controller of the access layer to control a scene flow.

Step 506: the flow controller accesses the scene flow control table, and judges whether the switch is opened or not under the scene (in a certain area) and whether the flow controller is in the supported flow range.

Step 507: and after the flow controller judges that the service is passed, the access layer calls the related service.

In a fifth aspect, in order to enable the foregoing embodiments to be performed, the present application provides a first server, referring to fig. 6, where the first server hosts a first application system, and the first application system includes at least one service thereon; one or more services are used to implement a set scenario; the first server includes:

the service migration module 10: migrating a source code corresponding to the at least one service to a second server;

it can be understood that, in the service migration module, migrating the source code corresponding to at least one service in the first server to the second server may be directly migrating at least one service in the first application system loaded on the first server to the second server, or integrating multiple services to form a new service in the second server; for example, "original service 1", "original service 2", and "original service 3" on the original host system are all services with similar functions (customer basic information query), and are integrated into "new service 1" after being migrated to the development platform.

The first scene call module 11: executing a first current scene call group; wherein the second server executes a second current scene call group;

It will be appreciated that call chains are used to distinguish and define scenarios. The call chain is in the format of "(application name 1+ program class name 1) > (application name 2+ program class name 2) > (application name 3+ program class name 3) > (application name n + program class name n)". The data packet for service call is divided into a data packet header and a data packet body. The data packet head contains the technical field supporting the service call, and the data packet body is the field related to the service logic of the service. The data packet header has a reserved space to support the custom field, and a calling link field is added to store the calling link, as shown in table 1.

Referring to fig. 5, as an example, the customer information application provides a customer basic information inquiry service called by a "cash withdrawal service" and a "personal transfer service" of the personal financial transaction application, which are called by a "cash withdrawal transaction" and a "personal transfer transaction" of a new terminal, a "registered account transfer" and a "transfer remittance" of a mobile phone bank, respectively. In this example, four scenarios can be defined, respectively:

(F-ECIS+QryPersonComInfo)、

(F-WABP+LclTransf)>(F-PRAS+PersonTransfSv)>

(F-ECIS+QryPersonComInfo)、

(F-WABP+ComTransf)>(F-PRAS+PersonTransfSv)>

(F-ECIS+QryPersonComInfo)。

as can be seen from the above description, according to the first server provided in the embodiment of the present application, the call fields are stored in the data packet of each service, the call fields form call chains for setting a scene, different call chains correspond to different scenes, and scene information is transmitted through the data packet header, so that a caller system does not need to be modified, a specific scene can be directly located, and accurate control over service and scene call can be achieved.

In order to enable the foregoing embodiments to be implemented, the present application provides a second server, see fig. 7, where the second server hosts a second application system, and the second application system includes at least two services thereon; one or more services are used to implement a set scenario; the second server includes:

the service reception module 20: receiving a source code corresponding to at least one service migrated by a first server;

it can be understood that, the service receiving module receives the source code corresponding to the at least one service migrated by the first server, and may receive the at least one service in the first server directly from the second server, or integrate the at least one service received in the first server into a new service; for example, "original service 1", "original service 2", and "original service 3" on the original host system are all services with similar functions (customer basic information query), and are integrated into "new service 1" after being migrated to the development platform.

The second scene call module 21: executing the second current scene call group; wherein the first server executes a first current scene call group;

It will be appreciated that call chains are used to distinguish and define scenarios. The call chain is in the format of "(application name 1+ program class name 1) > (application name 2+ program class name 2) > (application name 3+ program class name 3) > (application name n + program class name n)". The data packet for service call is divided into a data packet header and a data packet body. The data packet header contains technical fields supporting service invocation, and the data packet body is fields related to the service logic of the service. The data packet header has a reserved space to support the custom field, and a calling link field is added to store the calling link, as shown in table 1.

Referring to fig. 5, as an example, the customer information application provides a customer basic information inquiry service called a "cash withdrawal service" and a "personal transfer service" of the personal financial transaction application, which are called a "cash withdrawal transaction" and a "personal transfer transaction" of a new terminal, a "registered account transfer" and a "transfer remittance" of a mobile phone bank, respectively. Taking the 'registered account transfer' of the mobile banking as an example, when the function calls the 'personal transfer service', the calling link field is (F-WABP + LcTransf) > (F-PRAS + PersonTransfSv) ', and when the' personal transfer service 'further calls the' customer basic information query service ', the calling link field is (F-WABP + LcTransf) > (F-PRAS + PersonTransfSv) > (F-ECIS + QryPersonComInfo)'.

As can be seen from the above description, according to the second server provided in the embodiment of the present application, the call fields are stored in the data packet of each service, the call fields form call chains for setting a scene, different call chains correspond to different scenes, and scene information is transmitted through the data packet header, so that a caller system does not need to be modified, a specific scene can be directly located, and accurate control over service and scene call can be achieved.

In a seventh aspect, in order to enable the foregoing embodiments to be performed, the present application provides a traffic controller, and referring to fig. 8, the first server hosts a first application system, where the first application system includes at least one service thereon; the second server carries a second application system, and the second application system comprises at least two services; one or more services are used to implement a set scenario; the flow controller includes:

the scene recognition module 30: identifying all current scenes according to a call chain, wherein the scene name is represented by the call chain, and the call chain comprises call fields for realizing all services of the scene;

it is understood that call chains are used to distinguish and define scenarios. The call chain is in the format of "(application name 1+ program class name 1) > (application name 2+ program class name 2) > (application name 3+ program class name 3) > (application name n + program class name n)". The service calling data packet is divided into a data packet header and a data packet body. The data packet head contains the technical field supporting the service call, and the data packet body is the field related to the service logic of the service. The data packet header is provided with a reserved space and supports a custom field, a calling link field is added and used for storing calling links, different calling links correspond to different scenes, and the flow controller identifies all current scenes through the calling links.

Scene segmentation module 31: segmenting all current scenes to obtain a first current scene calling group and a second current scene calling group;

4) Traffic of the at least one service on the first server and the at least one service migrated to the second server, respectively, is monitored, and changes in traffic must be consistent with the cut flow plan.

5) The sum of the traffic of the at least one service on the first server and the at least one service migrated to the second server is monitored, which should be kept stable.

6) When any trip of at least one service on a first server and at least one service migrated to a second server is monitored to be greatly changed, whether the sum of the traffic of the two servers is stable or not is immediately judged.

The scene transmission module 32: and sending the first current scene call group to a first server, and sending the second current scene call group to a second server.

As can be seen from the above description, in the migration process, the flow controller identifies a scene through the call chains, and different call chains correspond to different scenes, so that the system of the calling party does not need to be modified, the specific scene can be directly located, the scene is accurately managed and finely cut, and the stable operation of the system is ensured while the customer experience is kept unchanged.

In an eighth aspect, the present application provides a flow control system for service migration, as shown in fig. 9, the first server hosts a first application system, and the first application system includes at least one service thereon; the second server carries a second application system, and the second application system comprises at least two services; one or more services are used to implement a set scenario; the flow control system includes:

a first server 40, wherein the first server migrates the source code corresponding to the at least one service to a second server; executing the first current scene call group; wherein the second server executes a second current scene call group;

a second server 41, which receives a source code corresponding to at least one service migrated from the first server; executing the second current scene call group; wherein the first server executes a first current scene call group;

the flow controller 42 identifies all current scenes according to the call chain; segmenting all current scenes to obtain a first current scene calling group and a second current scene calling group; sending the first current scene calling group to a first server, and sending the second current scene calling group to a second server;

It can be understood that the source code corresponding to the at least one service is migrated to the second server, one or more services are used to implement a set scenario, different call chains correspond to different scenarios, the flow controller identifies the scenarios according to the call chains, further divides all identified scenarios to obtain a first current scenario call group and a second current scenario call group, and sends the first current scenario call group and the second current scenario call group to the first server and the second server for execution, and simultaneously adjusts the flows of the first current scenario call group and the second current scenario call group according to a scenario flow control table and an associated scenario definition table until the flow on the first server gradually becomes zero, the flow on the first server gradually reaches the total flow, and the associated scenario definition table is shown in table 3.

As can be seen from the above description, according to the flow control system for service migration provided in the embodiment of the present application, the call field is stored in the data packet of each service, the call field forms a call chain for setting a scene, different call chains correspond to different scenes, and a caller system does not need to be modified, and can be directly located in a specific scene.

An embodiment of the present application provides a flow control system for service migration, referring to fig. 8, further including:

the call recording module 43: the call record module includes a distributed service platform (DSF) for registering call records of the service and the scene.

It can be understood that the principle of the distributed service platform (DSF) is that a server issues a service to perform zookeeper registration, a client issues a service issued by the server to a zookeeper registration center to call the service, and the distributed service platform (DSF) is a basic platform for managing call between services and is responsible for registration of the service, registration of a service call relationship, and the like.

A flow control system for service migration according to the present application is specifically described below with reference to fig. 5 in conjunction with a specific example.

Step 502: and the channel terminal function calls the product service.

Step 504: product service, call basic service.

Step 507: and after the flow controller passes the judgment, the access layer calls the related service.

In terms of hardware, in order to solve the problem that the current caller management depends on the requirement of calling a registry ledger for service call in the project-related process, for example, an application a calls a service B of an application B, which actually has 10 scenes, but the application a only registers 1 call relationship (that is, only one scene is recorded), so that the call relationship is inaccurate and how many scenes actually exist cannot be known, the application provides an embodiment of an electronic device for realizing all or part of contents in the flow control method for service migration, and the electronic device specifically includes the following contents:

fig. 10 is a schematic block diagram of a system configuration of an electronic device 9600 according to an embodiment of the present application. As shown in fig. 10, the electronic device 9600 can include a central processor 9100 and a memory 9140; the memory 9140 is coupled to the central processor 9100. Notably, this fig. 10 is exemplary; other types of structures may also be used in addition to or in place of the structure to implement telecommunications or other functions.

In one embodiment, the flow control function may be integrated into the central processor. Wherein the central processor may be configured to control:

it is understood that call chains are used to distinguish and define scenarios. The call chain is in the format of "(application name 1+ program class name 1) > (application name 2+ program class name 2) > (application name 3+ program class name 3) > (application name n + program class name n)". The data packet for service call is divided into a data packet header and a data packet body. The data packet header contains technical fields supporting service invocation, and the data packet body is fields related to the service logic of the service. The data packet head has a reserved space and supports a custom field, a calling link field is added for storing calling links, different calling links correspond to different scenes, and the flow controller identifies all current scenes through the calling links.

7) Traffic of at least one service on a first server and at least one service migrated to a second server is monitored, respectively, the traffic changes having to be in accordance with a cut flow plan.

8) The sum of the traffic of the at least one service on the first server and the at least one service migrated to the second server is monitored, which should be kept stable.

9) When any one of the at least one service on the first server and the at least one service migrated to the second server is monitored to be greatly changed in trip, whether the sum of the traffic of the two servers is stable or not is immediately judged.

As can be seen from the above description, in the migration process, the flow controller identifies a scene through the call chain, and different call chains correspond to different scenes, so that the calling system does not need to be modified, the specific scene can be directly located, the scene is accurately managed and finely cut, and the stable operation of the system is ensured while the user experience is kept unchanged.

In another embodiment, the flow control system for service migration may be configured separately from the central processor 9100, for example, the flow control system may be configured as a chip connected to the central processor 9100, and the flow control of service migration is realized through the control of the central processor.

As shown in fig. 10, the electronic device 9600 may further include: a communication module 9110, an input unit 9120, an audio processor 9130, a display 9160, and a power supply 9170. It is noted that the electronic device 9600 also does not necessarily include all of the components shown in fig. 10; in addition, the electronic device 9600 may further include components not shown in fig. 10, which may be referred to in the prior art.

As shown in fig. 10, a central processor 9100, sometimes referred to as a controller or operational control, can include a microprocessor or other processor device and/or logic device, which central processor 9100 receives input and controls the operation of the various components of the electronic device 9600.

The memory 9140 can be, for example, one or more of a buffer, a flash memory, a hard drive, a removable media, a volatile memory, a non-volatile memory, or other suitable device. The information relating to the failure may be stored, and a program for executing the information may be stored. And the central processing unit 9100 can execute the program stored in the memory 9140 to realize information storage or processing, or the like.

The input unit 9120 provides input to the central processor 9100. The input unit 9120 is, for example, a key or a touch input device. The power supply 9170 is used to provide power to the electronic device 9600. The display 9160 is used for displaying display objects such as images and characters. The display may be, for example, an LCD display, but is not limited thereto.

The memory 9140 can be a solid state memory, e.g., read Only Memory (ROM), random Access Memory (RAM), a SIM card, or the like. There may also be a memory that holds information even when power is off, can be selectively erased, and is provided with more data, an example of which is sometimes referred to as an EPROM or the like. The memory 9140 could also be some other type of device. The memory 9140 includes a buffer memory 9141 (sometimes referred to as a buffer). The memory 9140 may include an application/function storage portion 9142, the application/function storage portion 9142 being used for storing application programs and function programs or for executing a flow of operations of the electronic device 9600 by the central processor 9100.

The memory 9140 can also include a data store 9143, the data store 9143 being used to store data, such as contacts, digital data, pictures, sounds, and/or any other data used by an electronic device. The driver storage portion 9144 of the memory 9140 may include various drivers of the electronic device for communication functions and/or for performing other functions of the electronic device (e.g., messaging applications, contact book applications, etc.).

The communication module 9110 is a transmitter/receiver 9110 that transmits and receives signals via an antenna 9111. The communication module (transmitter/receiver) 9110 is coupled to the central processor 9100 to provide input signals and receive output signals, which may be the same as in the case of a conventional mobile communication terminal.

A plurality of communication modules 9110, such as a cellular network module, a bluetooth module, and/or a wireless local area network module, can be provided in the same electronic device based on different communication technologies. The communication module (transmitter/receiver) 9110 is also coupled to a speaker 9131 and a microphone 9132 via an audio processor 9130 to provide audio output via the speaker 9131 and receive audio input from the microphone 9132, thereby implementing ordinary telecommunications functions. The audio processor 9130 may include any suitable buffers, decoders, amplifiers and so forth. In addition, the audio processor 9130 is also coupled to the central processor 9100, thereby enabling recording locally through the microphone 9132 and enabling locally stored sounds to be played through the speaker 9131.

An embodiment of the present application further provides a computer-readable storage medium capable of implementing all the steps in the flow control method for service migration in the foregoing embodiment, where the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the computer program implements all the steps in the flow control method for which an execution subject is a server in the foregoing embodiment, for example, when the processor executes the computer program, the processor implements the following steps:

it is understood that call chains are used to distinguish and define scenarios. The call chain is in the format of "(application name 1+ program class name 1) > (application name 2+ program class name 2) > (application name 3+ program class name 3) > (application name n + program class name n)". The data packet for service call is divided into a data packet header and a data packet body. The data packet head contains the technical field supporting the service call, and the data packet body is the field related to the service logic of the service. The data packet header is provided with a reserved space and supports a custom field, a calling link field is added and used for storing calling links, different calling links correspond to different scenes, and the flow controller identifies all current scenes through the calling links.

it is to be understood that during the migration process, at least one service on the first server and at least one service migrated to the second server are concurrent for a period of time, and the greyscale switching is a stepwise switching process. I.e. the traffic of at least one service on a first server decreases step by step and the traffic of at least one service migrated to a second server increases step by step, but the total amount of traffic on both servers should remain stable. Then, when monitoring the flow, the following requirements are met:

10 At least one service on a first server and at least one service migrated to a second server, respectively, whose traffic changes must be in accordance with the cut flow plan.

11 Monitoring the sum of the traffic of the at least one service on the first server and the at least one service migrated to the second server, which should be kept stable.

12 When any of the at least one service on the first server and the at least one service migrated to the second server is monitored to be greatly changed in trip, whether the sum of the traffic of the two servers is stable or not is immediately judged.

As will be appreciated by one skilled in the art, embodiments of the present invention may be provided as a method, apparatus, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (devices), and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

The principle and the implementation mode of the invention are explained by applying specific embodiments in the invention, and the description of the embodiments is only used for helping to understand the method and the core idea of the invention; meanwhile, for a person skilled in the art, according to the idea of the present invention, there may be variations in the specific embodiments and the application scope, and in summary, the content of the present specification should not be construed as a limitation to the present invention.

Claims

1. A flow control method for service migration is characterized by being executed by a first server, wherein the first server loads a first application system, and the first application system comprises at least one service; one or more services are used to implement a set scenario; the flow control method comprises the following steps:

migrating the source code corresponding to the at least one service to a second server;

2. A flow control method for service migration is characterized by being executed by a second server, wherein the second server loads a second application system, and the second application system comprises at least two services; one or more services are used to implement a set scenario; the flow control method comprises the following steps:

3. A flow control method for service migration is characterized by being executed by a flow controller, wherein the flow controller, a first server and a second server together form a flow control system for service migration, the first server loads a first application system, and the first application system comprises at least one service; the second server carries a second application system, and the second application system comprises at least two services; one or more services are used to implement a set scenario; the flow control method comprises the following steps:

4. The flow control method according to claim 3, wherein the segmenting all current scenes to obtain a first current scene call group and a second current scene call group comprises:

5. The flow control method according to claim 3, wherein the segmenting all current scenes to obtain a first current scene call group and a second current scene call group comprises:

6. A flow control system for service migration, the flow control system comprising: the system comprises a first server, a second server and a flow controller, wherein the first server carries a first application system, and the first application system comprises at least one service; the second server carries a second application system, and the second application system comprises at least two services; one or more services are used to implement a set scenario;

migrating the source code corresponding to the at least one service to a second server by the first server; executing a first current scene call group; wherein the second server executes a second current scene call group;

7. The flow control system of claim 6, further comprising:

a distributed service platform for registering the service and the call record of the scenario.

8. A first server, wherein the first server hosts a first application system, the first application system comprising at least one service thereon; one or more services are used to implement a set scenario; the first server includes:

a service migration module: migrating the source code corresponding to the at least one service to a second server;

the first scene calling module: executing the first current scene call group; wherein the second server executes a second current scene call group;

9. A second server, wherein the second server hosts a second application system, and the second application system includes at least two services; one or more services are used to implement a set scenario; the second server includes:

the second scene calling module: executing the second current scene call group; wherein the first server executes a first current scene call group;

10. A flow controller is characterized in that the flow controller, a first server and a second server together form a flow control system for service migration, the first server loads a first application system, and the first application system comprises at least one service; the second server carries a second application system, and the second application system comprises at least two services; one or more services are used to implement a set scenario; the flow controller includes:

11. An electronic device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, characterized in that the steps of the method of any of claims 1 to 5 are implemented by the processor when executing the computer program.

12. A computer-readable storage medium, on which a computer program is stored, which, when being executed by a processor, carries out the steps of the method of any one of claims 1 to 5.