WO2012142854A1

WO2012142854A1 - Application service platform system and implementation method thereof

Info

Publication number: WO2012142854A1
Application number: PCT/CN2011/085194
Authority: WO
Inventors: 高磊; 赵博然; 黄湘龙; 杨虎; 李春雷; 陈春松; 吴炳锡; 刘丹; 刘玎; 唐峤木
Original assignee: 北京新媒传信科技有限公司
Priority date: 2011-04-18
Filing date: 2011-12-31
Publication date: 2012-10-26
Also published as: CN103283209B; CN103283209A

Abstract

Disclosed are an application service platform system and an implementation method thereof. Proxy servers and a cloud computing application service system are disposed in the application service platform system. Applications are loaded and run on an application server cluster in the cloud computing application service system, and description information of the applications and correspondence between the applications and the application servers are stored in the cloud computing application service system. The proxy server receives a client request message, creates application context according to the description information of the application, adds the application context into the client request message, and then distributes, according to the correspondence between the application and the application server, the client request message to the application server where the corresponding application is located. The application server delivers the client request message to the corresponding application for processing, and the corresponding application locates data resources according to the application context. The technical solution of the present invention decreases the difficulty of application development, improves flexibility of the deployment and reduces difficulty of the deployment.

Description

Application service platform system and implementation method thereof

Technical field

The present invention relates to the field of Internet, and in particular to an application service platform system and an implementation method thereof.

Background of the invention

In the field of background service development, most Internet applications and enterprise applications will become increasingly complex when the system scale becomes more and more, and the system scale will increase, the development cost and operation and maintenance cost will increase sharply.

The present invention is directed to reducing application development difficulty, increasing deployment flexibility and reducing deployment difficulty.

Summary of the invention

The invention provides an application service platform system and an implementation method thereof. The technical solution of the invention can reduce application development difficulty, improve deployment flexibility and reduce deployment difficulty.

In order to solve the above technical problem, the technical solution of the present invention is implemented as follows:

The invention discloses a method for implementing an application service platform system, which sets a proxy server and a cloud computing application service system in an application service platform system, and saves description information of the application and between the application and the application server in the cloud computing application service system. Correspondence; the method includes:

The proxy server receives the client request message, parses the client request message, determines the corresponding application, creates an application context according to the description information of the application, and adds an application context to the client request message, according to the application and the application. The correspondence between the servers distributes the client request message to the application server where the corresponding application is located;

When receiving the client request message sent by the proxy server, the application server in the cloud computing application service system hands the client request message to the corresponding application for processing;

The corresponding application processes the task requested by the client request message, performs data resource positioning according to the application context, and obtains a processing result;

The application server returns the processing result to the client via the proxy server.

The invention also discloses an application service platform system, the system comprising: a proxy server and a cloud computing application service system, wherein the application server cluster in the cloud computing application service system bears and runs the application, and the cloud computing application service system The description information of the application and the correspondence between the application and the application server are saved;

a proxy server, configured to receive a client request message, parse the client request message, determine a corresponding application, create an application context according to the description information of the application, and add an application context to the client request message, according to the application Distributing the client request message to the application server where the corresponding application is located; receiving the processing result returned by the application server, and returning the result to the client;

The application server in the application server cluster is configured to: when receiving the client request message sent by the proxy server, handing the client request message to the corresponding application for processing, and returning the processing result to the proxy server; The application processes the task requested by the client request message, performs data resource positioning according to the application context, and obtains a processing result.

It can be seen from the above that for most Internet applications and enterprise applications, the problem that the system scale becomes increasingly complicated and the scale is increased, and the development cost and the operation and maintenance cost increase sharply, the present invention builds a platform-as-a-service software platform. The general existing back-end software solution is split according to the service role, and the application splitting is performed at a fine-grained signaling level, and the application development and deployment is simple, which reduces development and deployment. Complexity; In addition, the present invention isolates complex resource location and application-to-application routing from a developer perspective by introducing the concept of application context, which supports a simple development method and enables the platform to be applied to a very large-scale server. Cluster.

BRIEF DESCRIPTION OF THE DRAWINGS

1 is a schematic diagram showing the logical structure of an application service platform system in an embodiment of the present invention;

2 is a schematic diagram of an actual networking of an application service platform system in an embodiment of the present invention;

3 is a hierarchical structure diagram of related application development in an embodiment of the present invention;

4 is a schematic diagram showing the internal structure of a single application server and the connection with the outside in the embodiment of the present invention;

FIG. 5 is a flowchart of an application process startup process in an embodiment of the present invention; FIG.

6 is a flowchart of an application process stopping process in an embodiment of the present invention;

7 is a flowchart of an application process update process in an embodiment of the present invention;

8 is a flowchart of a hot update of an application process in an embodiment of the present invention;

9 is a schematic diagram of a global configuration system in an embodiment of the present invention;

Figure 10 is a schematic diagram of a monitoring system in an embodiment of the present invention;

11 is a schematic diagram showing an implementation manner of a program embedded counter in the embodiment of the present invention;

Figure 12 is a schematic view of an injection type debugging system in an embodiment of the present invention;

FIG. 13 is a schematic structural diagram of multiple application service platform systems in an embodiment of the present invention. Mode for carrying out the invention

The present invention is an application service development platform based on a cluster PC server environment. In a specific implementation, the application can be based on a Java runtime environment but is not limited to the Java language. The present invention logically integrates distributed server resources into a unified application. The platform, the application based on the platform for development.

The invention splits the application development to a single signaling level, and designs the concept of the application context, and binds the resource access in the application and the application routing to the application context, which further simplifies the development of the application platform.

The invention conducts routing through the proxy server Proxys, and performs application loading through the application server AppServer, and constructs a server cluster platform which can be operated and maintained as a whole and can be monitored.

The present invention will be described in detail below with reference to the accompanying drawings and specific embodiments.

I. Overall overview

FIG. 1 is a schematic diagram showing the logical structure of an application service platform system in an embodiment of the present invention. The proxy server and the cloud computing application service system are set in the application service platform system, wherein the proxy logic part is set in the proxy server, and the logic server part, the basic service, the resource, the center and the like are set in the cloud computing application service system. In Figure 1, the description of each logical part is as follows:

※Proxy (Proxy)

- used to distribute client messages and maintain client state (such as long connections);

- Agency services:

• SIP Proxy: maintains a long SIP connection with the client;

• HTTP Proxy: Responsible for distributing Http applications;

• SMS Proxy: Responsible for distributing SMS upstream applications;

※Application Server Clusters (AppEngine Hosts)

- The actual application service runs, and the server can be grouped;

※Basic Service (B asic Service)

- some core applications or stand-alone applications for internal requirements of the platform;

>3⁄4 Resources ( Resource )

- System resources provided to the platform, such as:

. Database ( File ) . Memory Object Buffer Server ( Memcache )

※ Center ( Center )

- The entire system's control center is used to monitor system management operations such as deployment, distribution, and update of application services used.

FIG. 2 is a schematic diagram of an actual networking of an application service platform system in an embodiment of the present invention. As shown in FIG. 2, the application service platform system includes: a proxy server and a cloud computing application service system, where an application server cluster in the cloud computing application service system loads and runs an application, and the cloud computing application service system stores Description information of the application and the correspondence between the application and the application server;

a proxy server, configured to receive a client request message, parse the client request message, determine a corresponding application, create an application context according to the description information of the application, and add an application context to the client request message, according to the The application and the application server distribute the client request message to the application server where the corresponding application is located; receive the processing result returned by the application server, and return the result to the client;

The application server in the cloud computing application service system is configured to: when receiving the client request message sent by the proxy server, handing the client request message to the corresponding application for processing, and returning the processing result to the proxy a server; the corresponding application processes the task requested by the client request message, performs data resource positioning according to the application context, and obtains a processing result.

The correspondence between the application and the application server saved in the cloud computing application service system is saved in a table, where the application process name and the application service path are recorded, that is, the correspondence between the application and the application server.

For the logical architecture shown in FIG. 1 above, in the embodiment of the present invention, the cloud computing application service system includes: a central server, a resource server, and a server cluster composed of multiple application servers, where:

The central server is configured to receive the externally uploaded application, save the description information of the application to the application configuration information list, create a correspondence between the application and the application server, and deploy the application on the corresponding application server, and save the application. a list of application running information for saving a correspondence between the application and the application server;

Each application server is configured to upload running information of the loaded application to a list of application running information for saving a correspondence between the application and the application server on the central server;

The application configuration information list includes the following information: an application ID, an application name, an application service type, an application process name, and an application service metadata annotation; the application operation information list includes the following information: an application process name, an application service address; The resource server is configured to save a data resource that needs to be accessed when each application on the application server processes the task requested by the client request message. In this embodiment, the resource server includes: a database server, a file server, and a memory object buffer server.

The proxy server is configured to receive the client request message, identify the application corresponding to the client request message by querying the application configuration information list on the central server, and then obtain the corresponding information by querying the application configuration information list and the application running information list on the central server. The service address of the application, the client request message is distributed to the application server where the corresponding application is located according to the obtained service address; the processing result returned by the application server is received, and returned to the client;

In one embodiment of the invention, the proxy server comprises: a hypertext transfer protocol, an HTTP proxy server, an initial session SIP proxy server, and a short message system SMS proxy server. Among them, the HTTP proxy server is responsible for distributing the HTTP application, the SIP proxy server is responsible for the long-term connection with the client's SIP, and the SMS proxy server is responsible for distributing the SMS uplink application.

In addition, the cloud computing application service system further includes a basic service server (not shown in Figure 2) connected to the application server cluster, and some core applications or independent applications for providing internal requirements of the platform.

In the application service platform system shown in FIG. 2, the proxy server is configured to: when receiving a client request message, extract a request parameter from a client request message, query a list of application configuration information in the central server, and find out The application configuration information list item corresponding to the metadata tag field is requested, and the corresponding application is identified.

For example, when receiving the HTTP request message, querying the application configuration information list on the central server according to the uniform resource locator URL in the request message, and finding that the application metadata label field includes the application with the URL information. The configuration information list item identifies the application corresponding to the client request message according to the application name in the found application configuration information list item;

Alternatively, when receiving the remote call procedure protocol Rpc request corresponding to the remote calling application component RemoteAppBean, the proxy server finds the application name (AppName) field on the central server according to the remote calling service name (Remote AppName) in the request message. The application configuration information list item with the same service name is remotely invoked, and the application corresponding to the request message is identified according to the application name field in the searched application configuration information list item;

The proxy server is configured to: according to the application process name in the searched application configuration information list item, find an application operation information list item that is in the application process name field on the central server and that has the same information as the application process name, The service address information of the application service is obtained from the found application running information list item. And distributing the client request message to the application server where the corresponding application is located according to the service address information of the application.

The proxy server creates an application service context according to the context information about the patch application service in the metadata label field in the found application configuration information list item.

In the application service platform system shown in FIG. 2, the central server is further configured to save a resource list; the resource list includes the following information: a resource name, a resource type, an application service context type, a positioning algorithm name, and a positioning algorithm parameter;

After receiving the client request message, the application performs resource location according to the application context and the corresponding information in the resource list in the process of completing the task requested by the client request message.

It can be seen that the application service platform system composed of the above proxy server, application server cluster, central server and resource server integrates the distributed server resources logically, which greatly reduces the development difficulty of the application and improves the development. The flexibility of deployment and the difficulty of deployment.

3 is a hierarchical structure diagram of related application development in an embodiment of the present invention. As shown in Figure 3, the application service platform system is developed based on the following hierarchical structure. Specifically, the proxy server, the iftli service, and the applications running on the application server cluster on the proxy server are developed based on the following hierarchy:

Develop a basic framework class library ( Framework): The base framework class library provides basic core functions and extension interfaces for customization in specific business areas; defines and implements multiple application component AppBean base types in the base ftH framework class library, and the basis The framework class library predefines the implementation of the application context interface and the basic application context type to provide the basic core functions; wherein different AppBean iftli types correspond to different types of applications for different types of signaling processing; the basic framework class library provides The extension interface is specifically used to extend the new AppBean base ftH type and the new application context in the business framework class library BizLibrary.

Based on the business characteristics, a business framework class library (Biz Library) customized for the business is developed based on the basic framework class library. The business framework library also provides service-related extension interfaces for extending new applications;

Based on the ^ ftH framework class library and business framework class library, develop applications, basic services, and proxy servers that implement business requirements.

Applications rely on the Framework and Biz Library to achieve business needs.

The underlying services rely on the Framework and Biz Library to provide the underlying services.

The proxy server relies on the Framework and Biz Library to implement business-based routing and load-bearing functions.

In the embodiment of the present invention, an application development mode based on an application component (AppBean) is provided. The minimum development and load granularity defined here is AppBean, which is defined as an application that implements a tiny granularity.

Generally, the application is defined to the signaling level. The specific expression of the application defined to the signaling level may be different depending on the service, such as a specific Http request (such as GET /default.do ), or a specific upstream message (FROM: 13800138000; TO: 10658000032; TEXT: HELLO), or a specific SIP instruction, or an RPC instruction (a method, Not an interface) and so on.

In the embodiment of the present invention, an application for processing one or more instructions is defined as an AppBean, and the minimum unit that can be developed and deployed by the application is AppBean, which can develop an AppBean for one signaling or multiple signaling, and deploy it to the platform system. In accepting the user's request, the request may come from the user's client software, browser, internal reference, or external signaling call.

In the embodiment of the present invention, an application is implemented as an interface based on Java, and all specific AppBeans are derived from the interface to implement specific methods, such as self-installation mechanism, configuration initialization, and service processing. And service unloading, etc.

An AppBean is an abstract interface, but application development must be derived from the AppBean base type (BaseAppBeanTypes ) designed for a particular signaling process.

In the embodiment of the present invention, the implemented AppBean basic types include: HttpAppB ean for processing HTTP requests, RemoteAppBean for processing RPC requests, and JobAppBean for processing scheduled tasks.

Each specific AppBean base type handles specific forms of signaling, and application developers need to choose the appropriate AppBean base type to implement their own application. The AppBean base types are not limited to the above. At the Biz Library level, you can extend a specific type of BaseAppBeanType and implement a Proxy for a specific type of processing.

About the application context is called App Context

In the present invention, not only is the development mode split into individual signaling, but the signaling is bound to the application context, and the application context is called AppContext. In the application service platform system of the present invention, the application service context (AppContext) is the key to application calling and resource location. Here, the application call includes the proxy server calling the application service, and the application service calling other application services. Both applications require the AppContext to achieve the target application service positioning.

The AppContext can be understood as follows: The AppContext is bound to the identity of the environment in which the current application is running, such as the current user. In this way, the developer is developing based on the AppContext (current user) at the development time, and accessing resources (database, file, cache) must be Through the current AppContext, developers can eliminate the problem of splitting the database, files, caches, etc., and even the cross-machine room problem of user data. It can only be developed based on the current user, greatly simplifying the development mode, and the system. The deployment structure is isolated from the development process to achieve an efficient and convenient PaaS platform.

The AppContext is divided into two parts from the data composition. The AppContext is serializable and deserializable: (1) The URI ( Context Uri ) is a string format, including the user's index information, which is responsible for subsequent positioning. Such as id: 230302023; session: 13910000001.

(2) Additional data ( ContextData ): is a predefined strong type data structure, which may include multiple fields; it includes attribute information of the application; the attribute information of the application includes: session parameters, authorization information, and the like;

In some cases, additional data will be generated by the Proxy for subsequent applications, in a long-connected Proxy server scenario (see the Proxys section).

Support for the getNamedValue(String fieldName) method, which can get the data of a specific field name. This method is used for grayscale publishing (see below).

AppContext is an abstract base class, and the following AppContext subclasses are predefined in the Framework:

NullContext : A predefined empty context, used when no context is needed;

S es sionContext : A predefined context that only holds the session Id.

In complex applications, a specific AppContext is generally extended in the Biz Library, such as an IM system. On the SIP Proxy, the user's Session is saved. Then we can extend the UserContext, so each application will receive the Proxy. Saved session information.

In addition to the standard AppContext, when using the application service system platform of the present invention for extension development, it is necessary to customize some basic foundations of the service, and the AppContext is one of them. The following is a specific example of an AppContext.

For example: using the application service platform system of the present invention to open an instant messaging (IM) system, where users in the IM system use an integer id for positioning, then the AppContex of the IM system can be customized according to the following manner, derived from the AppContext, Named UserContext:

Uri part: "id : 230302023" , which represents the user's id , then the user's id can be used to locate the user's application service location and database storage location;

. Data section:

- the user's login network address; - client type, etc.;

When the user's UserContext is customized, all AppBeans based on the user's operation in the system will use the UserContext as the <C> parameter of the AppBean, such as:

- Get user profile; - Set user profile; - Get friend list, etc.;

In addition, in the application service platform system of the present invention, in addition to providing an AppContext based on a single user, It also provides group-based business types, develops group-based application services, and also needs to customize group-based AppContext. IM system uses an integer to identify groups, derives from AppContext, and is named GroupContext. The structure of GroupContext is as follows: :

Uri part: "group : 123 123" , identifies the group id , which represents the user's id, then through the id of this group, we can locate the application service location of the group and the database storage location;

. Data section:

- the session parameters of the group; - the authorization of the group, etc.;

When a group-based GroupContext is customized, all AppB eans that operate on the group based on the group will use GroupContext as the < C > parameter of the AppBean, such as:

- Set the group name; - Update group permissions; - Get group offline messages, etc.

Application metadata annotation ( Ann otation s ) information

In the invention, when an application AppBean is developed and the AppB ean is extended, the application metadata and the operation mode and the like are marked by the Java metadata annotation (Annotation). After the data is compiled, the data can be loaded at the runtime, or compiled. The data is extracted from the reflection in the subsequent binary package.

In an embodiment of the invention, some predefined Annotations are described below, and the extended AppB ean defines its own specific Annotation.

1 . © AppName (app name and category name)

• Declare the name of the AppBean and the name of the category;

- @AppName(category="Core" , name="GetUserInfo");

Here @xxx is the annotation of the program metadata in the Java language.

• Category: name is globally unique;

• category can be used for classification of AppBeans;

- Convenient for operation and maintenance personnel to configure and classify;

- In a Category, if an AppBean is allowed to be accessed by an AppBean in another Category, the AppBean declaration must be made public, or friendly;

• @Public() : Allows access to all AppBeans;

• @ Friendlly ("Core") : Only allowed to specify Category access;

• ©Friendlly ("Core:AddBuddy"): Allows only specified application access.

2. ©Stateful (application status information)

When an AppBean is declared stateful, this AppBean can save the state in native memory;

Applications that are not labeled @81&16&1 are considered stateless applications, and the use of local memory is prohibited for state saving;

If multiple AppBeans in a Category have the same Stateful parameter ("Presence"), then these AppBeans are launched into a process and do not allow separate hot updates;

@Stateful's application will lose state when it is hot-updated, so try to use memcache instead, it is recommended to start only in some areas with high performance requirements;

When an AppBean is declared as Stateful, access to the AppBean will be taken from the AppBean.

AppContext binding consistency Hash way to route.

3. @ Http Pr efix

HttpPrefix (HTTP prefix, only for Http AppB ean )

Used to mark the scope of an Http request processed by an Http AppB ean;

Such as: @ HttpPrefix( '71ogin.do',);

- Indicates that the HttpAppBean handles http requests starting with login . do .

Message Name (Event name, only for MessageAppB ean)

Used to label the name of a MessageAppBean;

• For example: @ Mess age Name

4. © C ontextL oader (adding application service context information)

Used to label an AppBean: 3⁄4. He Li mouth planting AppContext

- such as: @ ContextLoader(name = " CookieParser" )

- indicates that the Context is processed by a program called CookieParser;

The -CookieParser program is built into the Proxy and handles user-related information by processing the cookie field in the Http Request.

In the embodiment of the present invention, some predefined Annotations are not limited to the above, and other annotations may be added according to actual business requirements, such as @ Peer s Site mentioned later. The cornerstone is Ap p B e an type ( AppB e anB aseType )

In the Framework, the steps to implement an AppBeanBaseType are as follows:

An AppBeanBaseType includes the following components and features:

• AppBeanBaseType is an abstract base class

• AppBeanBaseType must add the @AppBeanBaseType to be recognized by AppLoader

• There is no way to define the business in the AppBean, but ^ AppBeanBaseType must provide an abstraction method for processing the business, which is provided to the application subclass to implement

• At the moment of application, AppBeanBaseType is a single piece. The business process abstraction method will pass all the request parameters of this business run, and the transaction abstract class of the response method, we call it AppTx

• AppTx is generally bound to an AppContext

• The AppHost class must be implemented. The AppHost class will actually trigger the AppBean business processing method. AppHost will be derived with AppBeanBaseType.

• In general, you need to implement the AppBeanRouteManager responsible for distributing this request and the Proxy (independent proxy service) that handles the application.

Several basic AppBeanBaseTypes are implemented in the Framework, but the AppB ean that the application can use is not limited to the following types, and can be extended at the Biz Library level.

1. Http AppBean (Hypertext Transfer Protocol Application Component)

The HttpAppBean is used to process a specific Http request. The Http request may come from a direct request from the user's client browser or program, and the request will be forwarded to the application process through the intelligent layer 7 of the Http Proxy. Http requests may also originate from requests from other servers.

HttpAppBean<C extends AppContext> is a generic class, where the generic parameters are interpreted as follows:

.Context <C>: a specific type of context

Context source: Where to get the context < C > ;

URL prefix: The URL prefix processed by this application (the URL prefix is processed by @11« ?^^ metadata annotation) HttpAppBean indicates the UrlPrefix (prefix) that the request is being processed by the annotation, for example, develop one for the simplest HttpAppBean The steps are as follows:

1. Derived from the base class of HttpAppBean

@HttpPrefix("/Hello ")

@AppName( category: "example " name= "hello ")

Class HelloWorldAppBean extends HttpAppBean<NullContext>()

2. Specify the context type <0, which is NullContext, ie no context is required;

3. By @HttpPrefix annotation, represents the request to process the address sent to the @HttpPrefix annotation;

4. By @AppName, the directory of the application is example, and the name is hello;

5. Implement the process() method. The process() method is an abstract method defined in the HttpAppBean. After reading the HttpRequest, after processing, it returns HttpResponse to the client.

For example: The process for developing an application for user unified login authentication is:

1. Derived from the base class of HttpAppB ean;

2. Specify the application service context type < C > as S e ssionContext ;

3. Specify the Context source as the s sic field in the cookie;

4. Implement the proce s s method, read HttpReque st, and return HttpRe spons e to the client after processing.

2. RemoteAppBean (remote call application component)

RemoteAppBean is derived from AppBean and is used to process a specific Rpc request. Rpc requests may originate from the following scenarios.

- Calls from other AppBeans, possibly any source type;

From its roxy;

- From other external service calls.

RemoteAppBean is a generic class, where the generic parameters are explained as follows:

- <A>: request parameters, strong type definitions, serializable;

- <R>: response parameter, strong type definition, serializable;

- <C >: A specific type of application context.

Implementing a RemoteAppBean must provide certain types of determinants, such as developing a RemoteAppBean that handles getting user data as follows:

1. Derived from the base class of RemoteAppBean @AppName( category: "example ", name= "GetUserlnfo ")

Class GetUserlnfo extends RemoteAppBean<GetOption, UserInfo, NullContext>

2. Define the request parameter type <A> is GetOption, GetOption is the serializable class, save the user id and option parameters;

3. Define the response parameter type <R> is UserInfo, UserInfo is a serializable class, and save user information;

4. Define the context <C> is NullContext, no context is needed in this case;

5. After inheritance, the process() method is used to process the business logic, inheriting the load() method and initializing, inheriting the unload() method, unloading, and inheriting the setup() method to implement self-installation.

When calling a RemoteAppBean, you must provide a specific type of application context (AppContext) that this RemoteAppBean declares at implementation time.

An application that gets user information will declare it as follows:

1. Derived from RemoteAppB ean < GetOption , UserInfo , UserContext >;

a. Request parameter < A > is GetOption , to get some option parameters of the user

b. The response parameter < R > is UserInfo , a collection of user information

c. The application context < C > is UserContext , which is the user information of the current context, and the UserContext is used to identify the user ID

2. Implement proce s s method to handle business logic

3JobAppBean (Task Application Component)

JobAppBean λ AppBean derivation, used to process a timed task, and can ensure that the scheduled task runs exclusively on a resource in the global.

The steps to implement a JobAppBean are as follows

1. Derived from the base class of JobAppBean

@JobSchedule( cron= " */5 * * * *")

@JobResource( resource= "USERDB ", parallel=true)

@AppName( category: "example ", name= "GetUserlnfo ")

Class GetUserJobApp extends JobAppBean

2. Define the running time of the Job, where the running time of the Job runs according to the time expressed in the Com expression.

3. Define the resources that the Job will monopolize. For the definition of resources, see the next section. After the resources are bound, the JobAppBean in the platform system will not be run repeatedly for this resource.

Resource access location based on Ap p C ont ext

In the present invention, after defining and implementing an application having a certain business function, the application necessarily accesses various resources such as a database, a file server, a memory object buffer server, or other provided services. The application service platform system in the present invention is a large distributed system, so these resources are not single-point services, that is, there may be multiple instances of vertical sharding in the same type of database. In the present invention, a resource accessible by an application is bound to its application context AppContext.

For example, an application that retrieves user information, named GetUserlnfoApp, reads the user database (UserDB) in the implementation of the application and returns the result. The UserDB has multiple instances of vertical splitting after moduloing by user id.

Then the specific process is as follows:

1. Proxy server Http Proxy receives an Http request from the client;

2. Http Proxy judges the application corresponding to the request through the URL of the Http request; specifically, the Http Proxy finds the application of the @HttpPrefix and the URL of the Http request in the metadata annotation Annotations field by accessing the application configuration information list on the central server. The configuration information item, the application corresponding to the entry is the application corresponding to the Http request;

3. Http Proxy identifies in step 2 that the request is a request for GetUserlnfoAp and requires UserContext as the context parameter;

4. The Http Prorxy creates a UserContext according to the @ContextLoader in the Annotations field in the application configuration information table and the information extracted from the Http request message.

5. Http Proxy forwards the Htt request to the application server where GetUserInfoApp is located after adding the UserContext data from the Http request from the client; here, the service address of GetUserlnfoAPP is obtained by querying the application running information list.

6. The application process running on the application service GetUserlnfoApp receives the Http request, extracts the UserContext, and hands it to GetUserlnfoAp for processing;

7. GetUserInfoAp reads the UserDB. When reading the UserDB, the UserDB is located through the id information in the UserContext.

8. The GetUserlnfoAp organization returns the text and returns it to the Http Proxy;

9. Http Proxy will return the message back to the client.

In step 7 of the above process, positioning is performed through a resource table. A resource table in an embodiment of the present invention, such as Table 1 shows:

Table 1

Different positioning methods for different resources can be implemented by implementing different positioning functions (Locator). For example, in the above example, the specific configuration of the resource table is shown in Table 2:

Table 2

Then, when you use the id: 1001 to locate the UserDB in step 7, the ModDatabaseLocator will take out 1001 and divide 1001 by 5, taking the remainder as 1 and returning the database instance named UserDB.l.

Another example:

Develop an instant messaging (IM) system. Users in this IM system use an integer id to locate the application. The AppContext of the IM system can be customized from the AppContext and named UserContext.

- Uri part: " Id:230302023", which represents the user's id, then through this user's id, we can locate the user's application location, and the database storage location

- Data section:

• The user's login network address,

• Client type

• Wait…

When customizing the user-based UserContext, all AppBeans based on user actions in the system will use UserContext as the <C> parameter of the AppBean.

Such as: Get user data, set user profiles, get friends list, ...

However, in an IM platform, in addition to providing a user-based AppContext, there are group-based service types. To develop a group-based application, a group-based AppContext is also required. The IM system uses an integer to identify the group. , then the GroupContext structure is as follows

- Uri part: "group: 123123", which identifies the group id, which represents the user's id. Then, by the id of this group, we can locate the application location of the group, and the database storage location.

- The Data section includes: Group session parameters, group authorization, etc.

When a group-based GroupContext is customized, all Group-based AppBeans in that system will use GroupContext as the <C> parameter of the AppBean.

Such as: set group name, update group permissions, get group offline messages, ...

AppB ean based on the business framework class library BizL ibr ar y extension method

In the present invention, when a new type of application needs to be developed: an extension interface provided by the framework of the base framework class library extends the AppBean base type corresponding to the new type application in the business framework class library BizLibrary, and the business framework class library BizLibrary Extend the application context for this new type of application. Then you can develop a corresponding proxy server based on Framework and BizLibrary, and finally you can develop new applications on this basis.

For example: When developing a short message service system, we can extend the SMSBean based basic type of SMS type based on SMS: SmsAppBean, and develop the Sms Proxy for distributing SMS, and develop the UserContext based on SMS users. After these three items, the platform application can be developed based on the user and SMS instructions. The extension points are as follows:

• Extending AppBeans and Proxy allows the platform to gain the ability to support arbitrary signaling;

• Extending the AppContext allows the platform to support business systems of virtually any data type.

An extended example of AppBean: Sip AppBean

If in a SIP-based IM platform, consider applying the system, using PROTOCOL, METHOD, and EVENT of SIP signaling as a distinguishing SIP signaling identifier, then based on this, we can design a SipAppBean for processing from Client's SIP request. Then the steps to implement a SipAppBean are as follows:

1. Derived from AppBean;

2. Design logo @81 1\^&0(1("«0(;01=''¥1'', method="SERVICE", event="GetUserInfo") indicates this

The type of signaling handled by the SipAppBean;

3. Design identifier @81 1\^&0(18(81 ^\^^10(1[] methods)) allows a SipAppBean to handle multiple requests;

4. Design the SipAppHost class, open the SIP port, listen to all SIP requests, and distribute them to the SipAppBean of the specific application. The distribution is based on @AppName, which is added for the PROXY layer.

5. The actual SipTx transaction class, which encapsulates the request, response, and context;

6. Design a generic abstraction of processing signaling on SipAppBean;

7. SipcAppHost generates SipTx and forwards it to the abstract method of SipAppBean.

In this way, we can develop applications for each SIP signaling, and we will implement a SIP PROXY client that will maintain a long connection with SIP PROXY, and login with SIP PROXY will maintain some basic state of the user, and in subsequent The application is passed to subsequent applications, and the context required by each application can be implemented by extending the AppContext.

Extension example of AppC ontext: User C ontext

In the above description, we extend an AppContext for each IM user, called UserContext. According to the previous article, we need to implement two parts of the UserContext:

1. ContextUri:

We define ContextUri as id: 332132132, which represents the user's id

2. ContextData:

Definition ContextData includes the following data: NickName nickname, Age age, ClientType client type, Client Version client version number, ClientCaps client capability, Region user region.

Based on the above design, SIP PROXY will extract the information from the session saved by the user and send it to the corresponding application process of the application, so that the application process will get the UserContext from the request information and distribute it to the actual application. In this way, the application can actually get the UserContext and perform resource access and other processing.

Second, application deployment, operation and maintenance and routing

In the application service platform system shown in FIG. 2, a plurality of application servers in a server cluster are divided into a plurality of different groups, each group including one to more servers. When receiving the externally uploaded application, the central server deploys the application to a single application server according to external instructions, or deploys to multiple servers belonging to the same group. In this way, an application can be selectively hosted in a group, that is, the core application can be used separately to ensure the resource usage and stability of the core application; and the unstable application of the online application is used. Group separate servers to strip the effects and reduce the risk of the entire system. This approach facilitates the allocation of overall resources and the adjustment of network strategies.

In the present invention, an application server capable of running an application needs to be configured in a global unified manner, specifically, a global application server list and an application server grouping list are configured and saved on the central service.

The list of application servers is shown in Table 3:

table 3

As can be seen from Table 3, the application server list includes the following information: application server name, group name to which the application server belongs, and application server address.

The application server grouping list is shown in Table 4: Field Name Field Type Primary Key Description

GroupName varchar Y application group name

GroupDesc Varchar Application Server Description

Table 4

As can be seen from Table 4, the application server grouping list includes: an application server group name, and application server description information in the group. In practical applications, multiple application servers can be divided into different groups for running different application services. The benefits of application server grouping are as follows: 1. Specify the application server group for the core application to ensure the resource usage of the core application. And stability; 2. Specifying a separate application server group for some new unstable applications can reduce the risk of the entire system; 3. Conducive to the overall resource allocation and network policy adjustment.

4 is a schematic diagram showing the internal structure of a single application server and the connection with the outside in the embodiment of the present invention. The central server deploys the application to the application server in the application server cluster, including:

A daemon is deployed on each application server; a list of application processes is saved on the central server; the application process list includes: an application process identifier, a dynamic port tag, an application server name, an application server group name, a deployment package interface, and a service port; The central server determines, according to the information in the application server list, the application server grouping list, and the application process list, a list of application process deployment information that should be started on each application server; the application process deployment information list includes: an application process identifier, a dynamic port identifier, Deploy the package interface and service port;

After the daemon of each application server is started, a connection is established with the central server and the heartbeat is maintained. The application process deployment information list of the application server is obtained from the central server, and the application server of the application server is downloaded and started according to the application process deployment information list. Process

Each launched application process establishes a connection with the central server and maintains a heartbeat;

The central server records its connection information in the daemon status information list for each daemon that establishes the connection, and saves the connection information in the application operation information list for each application process that establishes the connection.

As shown in Figure 4, the daemon (Master) is a background monitoring process deployed on each application server, responsible for the running and deployment of application services. A daemon is deployed on each application server. The daemon establishes a long connection with the central server, and through this long connection, it accepts system instructions such as deployment, update, and monitoring. In an application server, several application services can run in an application process (Worker), which can also be called a service shell. There can be multiple application processes on an application server.

Application deployment

In the present invention, the developed application is deployed to an application server in the server cluster, and the proxy server's routing for the application is customized to the application server hosting the application.

The developer compiles the code of the developed application to generate a JAVA application release (jar package) for deployment, also known as a deployment package. In one embodiment of the invention, a possible jar package is distributed as follows: Framework.jar, BizLibrary.jar, Appl.jar, App2.jar. The Appl and App2 jar packages include the actual AppBeans that can be run, and the BaseAppBeanType is stored in the Framework and BizLibrary, and the META-INF/appbean.properties configuration exists in the resource files of the jar package. The above jar package will be labeled as a tar.gz package, as a deployment release package.

The operation and maintenance personnel use the processing tool, which is generally AppLoader. AppApper will extract all the AppBeans implemented by the developer through the java reflection mechanism. The extraction steps are as follows:

1. Traverse all the jar packages in the compressed package;

2. Skip the non-application jar package by looking for the configuration in the resource file;

3. Traverse all the classes in the application jar package;

4. Skip the class that does not implement the AppBean interface;

5. Skip abstract class recursive traversal class of the base class, the base class can be found when the annotation: When © AppBeanBaseType; kg by the step ^P £ ^P obtained according to the list of components and applications stored application package list. ''' In the embodiment of the present invention, the application component list and the application package list are respectively shown in Table 5 and Table 6,

ArgsTyp e Text input parameter class 3⁄4

ResultTyp e Text output parameter class 3⁄4

Dep endencies B oolean Whether there is a dependency on other applications

Packageld Int package identifier (package ID)

table 5

Table 6

A list of application configuration information is generated based on the information in the application component list and the application package list. The application configuration information list (also known as the Application table) is shown in Table 7:

Table 7

In Table 3, about the Annotations field: AppLoader analyzes the metadata annotations contained in the Java application classes and application classes, and extracts the type information and metadata annotation information of each AppBean, and uses JSON (JavaScript Object Notation) format. The string is saved in the Annotations field of the Application table. The specific format is as follows:

The Annotations field contains a classlnfo subfield and a classAnnotations subfield;

The classlnfo field contains the current type, the base type, and the generic parameters of the base ftH type;

The classAnnotations field contains each metadata tag contained in the AppBean. Each parameter of the metadata tag is stored by "key", "value".

In Table 3, in addition to the WorkerPackage (Application Service Deployment Package Name), ServerGroup (Application Server Group), and Enabled (Enable) fields, the data of the remaining fields are automatically written into the application configuration information list in the central server by the tooling tool. . This avoids the hassle of manual writing and the risk of errors.

The operation and maintenance personnel select the application service deployment package name, the application server group, and whether the option is enabled, and update the Application table. In the present invention, the application process running the application is also uniformly configured globally, specifically, the application process list is also configured and saved on the central service, also referred to as the worker table, as shown in Table 8:

Service port; required service agreement name, semicolon separated

ServicePor s Varchar

Http,rpc:,

Table 8

The central server determines the application process deployment information list to be started on each application server according to the information in the application server list (Table 3), the application server grouping list (Table 4), and the application process list (Table 8), and the specific rules are as follows: :

1. Get the name of the current application server and its application server group name;

2. In the application process list (Table 8), if its application server group name field is not empty, look in the application process list for the application server group name field containing the record of the application server group name of the current application server;

3. In the application process list (Table 8), if its application server name field is not empty, look in the application process list for the application server name field containing the current application server name record;

4. Combine the records in steps 2 and 3 to get a list of deployment information for the application process that should be started on the current server.

Each item of the application process deployment information list contains the following information: Application Process ID (WorkerID), Dynamic Port Tag (IsDynamicPor), Deployment Package Interface (PackageUrl), Service Port (ServicePorts).

After the daemon of each application server is started, a connection is established with the central server and the heartbeat is maintained. The application server deployment information list of the application server is obtained from the central server, and the application server is downloaded and started according to the application process deployment information list. Process; each launched application process establishes a connection with the central server and maintains a heartbeat; the central server records its connection information in the daemon status information list for each daemon that establishes the connection, and for each application process that establishes the connection The connection information is saved in the application running information list.

Launch and registration of the daemon (M aster )

A daemon Master is responsible for managing all application processes on this application server. The startup registration steps of the Master are as follows:

1. Start the Master;

2. The Master establishes a TCP long connection with the central server and listens for commands from the central server;

3. Keep heartbeat with the central server and upload the running status of the application server;

4. Obtain the application process deployment information list of the application server from the central server through the TCP long connection, and start the corresponding application process.

After the Master obtains the application process deployment information list, the process of starting the application process is as follows:

1. Download the application process running package through the PackageUrl in the application process deployment information list;

2. Create a directory named Workerld+PackageN ame, and extract the downloaded application process package to Workerld;

3. Select the available ports from the local port pool and select the available ports. Start the application process from the workerld in the directory and transfer the ports in the port pool to the application process.

The central server maintains an entry for the master on each connection in the list of daemon status information in the database to record its connection information. The entries for this record are shown in Table 9:

Word ^ g called field class 3⁄4 primary key field description and description

ComputerName Varchar Y host name

C ornp uterAddre ΞΞ Varchar host address

CenterUrl Varchar Center Address

HostVersian Varchar Host version

Re isterTirne D atetime ;

Last eepTime DateTime Last Heart Time

HostStartTime Datetime Host startup time

Last equestTime Datetime Last request time

MachineCpu Float host C J utilization

UsedMem Bigint uses memory

FreeMern Bigint empty 3⁄4 memory

Buffers Bigint uses Buffer

Cached Bigint uses Cached

UsedSwap Bigint uses swap memory

FreeSwap Bigint does not use swap memory Status Varchar

StatusEx Nvarchar status information

Table 9

Porter pool management

The master port pool management process is as follows:

1. After the Master starts, obtain the port pool range of the application server from the application server list on the central server, such as "8001-8099";

2. The Master will test the port number in the port pool range that has not been turned on, and mark it as available;

3. When a worker is started, if the dynamic port in the corresponding application process deployment information list is marked as a dynamic port, the master knows the port number required by the worker according to the service port in the corresponding application process deployment information list item. Quantity, otherwise it will not be processed. For example, "http;rpc" means that the application needs two ports, http and rpc;

4. Take the corresponding number of port numbers from the port pool range of the application server and assign it to the worker, and mark the assigned port number as occupied; if it is transmitted in the following format: http = 8001; rpc = 8002;

5. When the worker needs to start the port, use the port number combination transmitted by the Master, such as: When the application listens to the http port, select the port 8001, when the application listens to the rpc port is the monitor 8002;

6. When the worker exits, the daemon returns the port number occupied by the application process to the port pool.

Application process (Wor ker) startup and registration

The worker startup steps controlled by the Master are as follows:

1. Accept the parameters from the Master, including the configuration of the port pool;

2. Implement the logic of service startup, including configuration read, resource initialization, etc.

3. When configured as a dynamic port, start the listening port according to the port pool configuration, otherwise it will listen according to the configuration of the service;

3. Establish a long connection with the central server and listen for commands from the central server;

4. Register yourself in the central server via this long connection;

5. Maintain a heartbeat with the central server through this long connection.

Each launched Worker will establish a long connection with the central server and maintain the heartbeat. The central server will record the connection information in the application running information list for each connected worker in the application running information list to record the connection information. Table 10 For the application to run the information list, also known as the Running Worker table:

Table 10

In Table 10, the format of the application service address can be: ^^= :〃192.168.1.100:8000;1« =1« :〃192.168.1.100:8080 According to the previous description, after the worker establishes a long connection with the central server And periodically send a heartbeat (such as 15 seconds), where the following situation will cause the central server to use the available Worker from the application running information list: 1. The connection is disconnected; 2. The preset time (such as 45 seconds) No heartbeat was received.

Application process (Worker) management

In addition to the design of the self-starting application process at the moment the daemon starts, it can also manage the running of the application process while the daemon is running. Adding a control terminal connected to the central server; the control terminal sends a request to the central server to start the specified application process, the central server sends the request to the corresponding daemon, and the daemon starts the specified application process, and the application process connects to the daemon, The daemon sends the request to the application process, and the application process invokes a startup method of the service; the control terminal sends a request to the central server to stop the specified application process, and the central server sends the request to the corresponding daemon, and the daemon processes the request. The request is sent to the specified application process, the application process calls the stop method of the service, and the daemon stops the application process.

About how to control the terminal to find the appropriate central server address: Because the central server will be deployed in a balanced manner, but HADB is a single-point structure, when the control terminal wants to operate a central server, the following steps are taken: 1. The control terminal accesses the GetEndpoint interface of the central server through the bearer address; 2. controls the Endpoint returned by the terminal through the central server Connect to the central server that is responsible for the connection.

FIG. 5 is a flowchart of an application process startup process in an embodiment of the present invention. As shown in FIG. 5, the method includes: the control terminal sends a request for starting a specified application process to the central server through the Http, and the central server selects the TCP connection by using the selected TCP connection, and sends a request for starting the specified application process to the corresponding daemon through the selected TCP connection. The daemon starts the application process, and the application process connects to the daemon through the Namepipe; the daemon sends the request to the application process through the Namepipe, and the application process invokes the service's Start method.

6 is a flow chart of an application process stop process in an embodiment of the present invention. As shown in FIG. 6, the method includes: the control terminal sends a request to the central server to stop the specified application process through the Http, and the central server selects a TCP connection according to the request, and sends the request to the corresponding daemon through the TCP connection; The request is sent to the application process through the Namepipe, and the application process invokes the stop (Stop) method of the service by reflection; the daemon stops the application process.

FIG. 7 is a flowchart of an application process update process in an embodiment of the present invention. As shown in FIG. 7, when the specified application process A is updated by the application process A', the control terminal sends a request for updating A to A' to the central server through the Http, and the central server selects a TCP connection according to the request, and connects through the TCP connection. The request is sent to the corresponding daemon; the daemon obtains the address of the new application process and overwrites the current application process for application process update. Specifically, stop application process A first, then download A from the central server, and overwrite A with A, and start a new application process A.

FIG. 8 is a flowchart of a hot update of an application process in an embodiment of the present invention. As shown in FIG. 8, when the specified application process A is updated by the application process A', the control terminal uploads the deployment package of A' to the central server, and sends a request updated by A' to the central server, and the central server requests the request. Sent to the corresponding daemon, the daemon downloads the A' deployment package from the central server, and starts the application processΑ, the application process is started, and then registers with the central server after startup; then, the control terminal sends an update A to the central server. The request, the central server sends the request to the corresponding daemon, and the daemon sends the request to the application process A, and the application process A deletes its own registration information on the central server, and the application process A stops.

The hot update shown in Fig. 8 can be used without stopping the business of the application process with respect to the update shown in Fig. 7.

The above solution implements the monitoring of the running state of the application process, and can conveniently view the running status of the application process, which greatly simplifies the operation and maintenance deployment cost and realizes rapid deployment. The monitoring of the application process is isolated from the actual application process, which effectively improves the security of the application process.

When the application process starts, our core requirement is to find the application server address that is started by the application process through an application process name. In this step, the client is connected to the central server to provide the central server with the application process identification information to be accessed; the central server reads the application process list and the application running information list, which is consistent with the client's provided information. The record of the application process identification information is returned to the client; the client parses the received content, and selects a record for routing. In addition, when the application process list or the application operation information list changes, the central server notifies the client that the client re-acquires records from the central server that match the application process identification information that it is to access. The specific description is as follows:

1. The client accesses the central server, establishes a TCP long connection with the central server, and listens to the commands of the central server;

2. The client accesses the central server through a TCP long connection, providing the name of the application process that he wants to access;

3. The central server reads the application process list, and the application running information list, and returns the record of the application process name to the client, and records the information of the connection in the memory, and registers the callback;

4. The client parses the record, and obtains the address corresponding to the application process name according to the following rules;

a) get the record of the application process name;

b) Get the records that match the list of application processes, and disassemble the records in the ServiceUrls;

Such as: http=http:〃192.168.1. 100: 8800;rpc=tcp:〃192.168.1.100: 8801 Get the address of rpc from it;

c) Return to the caller from a series of matching records according to the access rules, such as:

i. Random access will randomly select one from a fixed address;

Ii. If the consistency hash is selected according to the consistency hash algorithm;

5. All central servers will be notified when the following changes are triggered;

a) when the application process list changes;

b) when the application operation information list changes;

6. Since the client maintains a long connection with the central server and listens for commands from the central server, the central server responsible for the client receives the change notification, and sends the change information to the client;

7. After the client receives the change, it will repeat step 3 again to re-acquire and establish the routing table.

In the present invention, the hot update process of the application (App Bean) is as follows: The central server traverses all affected application servers, sends update instructions to the corresponding application server daemon; the daemon processes a new application package, starts a new The application process listens to the new port; the new application process establishes a connection with the central server, the central server saves a record for the new application process (specifically, updates the application process name in the application configuration information list), and synchronizes the change to all The client that is listening. At this point, the request starts routing to The new application process, the old application process no longer receives the application request after a period of time, exit.

Applied routing

In the system shown in Figure 2, the proxy server (proxy) needs to call an application, or an application needs to call another application, it is through the application configuration information list (Application table, Table 7) and the application operation information list. (Running Worker table, Table 10) is routed.

The basic routing strategy is as follows:

1. Searching for the application metadata of the corresponding application in the list of application configuration information corresponding to the request through the parameters in the request (this step has different execution methods according to different types of AppBeans);

2. Find the corresponding application process name by using the metadata annotation in the application configuration information list;

3. In the application running information list by using the application process name, find one or more application server addresses with the same name as the application;

4. Determine whether the application process name is random or consistent by the metadata annotation in the application configuration information list.

5. Find the exact target application server address through a random bearer algorithm or a consistent hash algorithm;

6. Calling to the target application server, and appending the application name (App Name ) in the application configuration information list item to the request, so that the daemon on the target application server can directly locate the corresponding application according to the application classification name, and It is no longer necessary to repeat the steps 1 and 2 again.

For example, in one embodiment of the invention, the process of finding the address of an Http application is as follows:

1. The proxy server receives an Http request from the client or browser;

2. The proxy server accesses the central server. From the Annotations field of the application (application metadata annotation field), find a record that @HttpPrefix (a type of metadata annotation information) matches the request URL in the Http request;

Specifically, say, enumerate all the records in the Application table, find the @HttpPrefix metadata annotation in Annotations, and determine whether the requested URL starts with the value of HttpPrefix;

3. The proxy server generates an AppContext according to the information of the Annotations field (application service metadata label field) in a record determined in step 2;

Specifically, find the @ContextLoader information of the Annotations field, find the assignment function that matches the value of the ContextLoader, extract the information from the cookie field of the Http request message as the input of the function, and run the function to get the AppContext;

4. The proxy server finds the record corresponding to the WorkerName field (the running application process name) from the Running Worker table according to the WorkerName field (application process name segment) in a record determined in step 2; The record is consistent with it.

5. The proxy server makes the following selection according to the @Stateful configuration in the Annotations field in a record determined in step 2:

If it is 'true', a consistent hash is used to select a record from multiple Running Workers through the AppContext information; here, the consistency hash is calculated by the Uri string of the AppContext, and the hash value is selected. Corresponding one record; the specific hash algorithm can adopt the KETAMA algorithm;

If it is 'false', randomly select a RuningWorker record;

6. Extract the address information in the ServiceURLs field (application service address field) in the selected RuningWorker record, and implement the application call according to the address information.

In the above example, the proxy server receives the request for the HttpAppBean, so find the corresponding HttpPrefix in the Application table according to the URL in the request to find the corresponding application service.

The RemoteAppBean will route based on @AppName. For example, if the proxy server receives the Rpc request corresponding to the RemoteAppBean, then: according to the remote call service name (RemoAppName) in the Rpc request, find the application service name (AppName) field and its consistent Application table, the Application table is To deploy the table generated when the Rpc requests the corresponding RemoteAppBean, then perform the same steps as 3-6 above.

Applied grayscale release

Grayscale publishing is a process in which applications are opened to all users in a user-wide or heuristic manner. Grayscale publishing can reduce the risk of application updates.

The grayscale publishing factor (GrayFactor) is included in the list of application configuration information mentioned earlier. In the present invention. For applications that do not use grayscale publishing, the grayscale publishing factor in the corresponding application configuration information list item is empty; and for applications that use grayscale publishing, the grayscale publishing factor is configured in the application configuration information list item.

In the present invention, the grayscale publishing factor is a conditional expression, which is defined in the following format:

Field. condition

Where: field and condition are separated by ., field.condition can be logically operated, for example:

Fieldl.conditionl and lor f ield2. condition2 Field indicates the value point, condition indicates the value condition, and the application published by this gray level is used when this value condition is met.

In the system shown in FIG. 2, after receiving the client request message, the proxy server identifies the application corresponding to the client request message by querying the application configuration information list on the central server, and if multiple applications are found, press Choose as follows;

The proxy server first matches its grayscale publishing factor in an application whose grayscale publishing factor is not empty. If the matching hits, the selected application is selected. If there is no matching hit, the application whose grayscale publishing factor is empty is selected (ie, the default is application).

In one embodiment of the present invention, the grayscale is published based on the AppContext, that is, the field value is a condition pre-defined in the AppContext, which is obtained by AppContext.getNamedValue("fieldr).

In the previous section, there was an extension to the AppContext with a getNamed Value () method. In grayscale publishing, getNamedValuedO is evaluated as the field parameter for grayscale publishing.

Then, the proxy server first matches the grayscale publishing factor in the application that the grayscale publishing factor is not empty, including: the proxy server parses the client request message, and determines the correspondence in the application configuration information list on the central server. a list item, creating an application context according to the information in the corresponding list item, matching the grayscale publishing factor according to the grayscale publishing factor matching condition information in the created application context, and hitting if the condition expressed by the grayscale publishing factor is met. For example, when the grayscale publishing factor is: client version number = V2.0, the matching is based on the client version number information in the application context to see if it is V2.0, and then it is hit.

For example, in the UserContext extension example in the previous section, NamedValued is defined as follows:

The available fields for grayscale publishing include: user-owned area (user_region), user client type (client_type), client-side ip address-associated area (client-region), and client version number (client-version).

Then the application routing steps with grayscale publishing implemented in the SIP Proxy are as follows:

1. After receiving the request, obtain the session information of the user, and create a UserContext;

2. Through the requested parameters, in the application configuration information list corresponding to all the types of requests, search for the application configuration information list item corresponding to the application and the corresponding metadata annotation (this step has different execution methods according to different types of AppBeans);

3. In the case of grayscale publishing, step 2 may find multiple application configuration information list items (one application corresponds to one application configuration information list row), wherein only one grayscale publishing factor GrayFactors is allowed, other GrayFactors Data that is not empty is published in grayscale.

4. Priority judgment GrayFactors is not empty application configuration information list item data, UserContext is calculated according to the order of configuration acquisition GrayFactors,

a) If the calculation does not match, the next one is automatically calculated, until only one match is found

b) If you find data that GrayFactors is not empty, use this application configuration information list item for subsequent route calculations;

c) If no matching configuration list items are found that are not GrayFactors, the default application configuration information list item (GrayFactors is empty) is used for subsequent route calculation;

5. The routing algorithm after the application configuration list item is found is consistent with the foregoing description, that is, the application operation information list is queried according to the application process name in the found application configuration information list item, and the application operation information list item with the same application process name is found. If there are multiple, it is determined according to the metadata label whether the application process is random or consistent Hash, and the exact target application server address is found by the random load algorithm or the consistent hash algorithm, and the target application server is called. And append the App Name in the application configuration information list item to the request.

Version number gradation grayscale

In this system, there may be the following situations: Application A provides services to users, but application A calls application B; application A upgrades to application Α', but at the same time needs to upgrade applications Β', we will gray out application A' Released, but hope that A' calls B' instead of Β Α and Β version number is 1.0, A' and B' version number is 2.0

The solution given in the present invention is as follows: After the application B of the application B and the call B is released, the corresponding upgrade versions B' and A' are grayscale-released, and the grayscale factor of B' is set. To match the version number of A', the process of routing the client request message to A' is as follows:

1. A' find the application to be called in the application configuration information list, find B and Β'; where B' is configured for grayscale publishing, and the grayscale publishing factor is version matching, and the grayscale publishing factor is configured as follows: app_version. Equals("2.0")

2. Since the grayscale publishing factor of B' is not empty, the matching is performed first; A' obtains its own version number and matches B's grayscale publishing factor, hits; A' selects B' as the called application.

3. The routing process after selecting B' is consistent with the foregoing description, and details are not described herein again.

Third, the configuration system

In the development of large-scale cluster systems, the configuration information of application services has always been confusing and difficult to manage. In the present invention, a central-based configuration method is used, and the global manageability of the configuration is realized on the flexible ftH. , convenience, specialization, update and other features.

FIG. 9 is a schematic diagram of a global configuration system in an embodiment of the present invention. As shown in FIG. 9, the system adds a global configuration database connected to the central server for saving configuration information of the application based on the system shown in FIG. 2. Application server to central server Sending a configuration information request message; after receiving the configuration information request message sent by the application server, the central server retrieves corresponding configuration information from the global configuration database and returns it to the application server.

The application server also registers its own address to the configuration server. After the configuration information of the application server in the configuration database is updated, the configuration server delivers the updated configuration information to the corresponding application server according to the registered address of the application server.

In this system, the configuration information is divided into two types: text configuration text and table configuration table. Among them: Text is text, can be any format, such as .properties format, or xml format; Table is a data table, similar to the table in the database, the interface provides access to the table interface, you can directly access the table.

Local/global configuration mode

In the present invention, the application server can also obtain configuration information locally, so the configuration has two modes of operation: local configuration and global configuration:

In the local configuration mode, Text will use the current running directory as the root directory to read the text file. Table will directly read the table structure in the database by running the configuration information of the global configuration database in the root directory.

In the global configuration mode, Text and Table are read through the central server. The central server reads the Text configuration and Table configuration stored in the global configuration database, and implements specialization features and PUSH update features.

The application server switches between the global configuration mode for obtaining configuration information from the central server and the local configuration mode for obtaining configuration information from the local device by switching the remote loading module and the local loading module. The remote loading module is configured to send a configuration information request message to the central server, and receive configuration information returned by the central server. The local loading module is configured to obtain configuration information locally from the application server.

In general, when unit testing, and running directly from the development environment, the application runs in the local configuration mode; when the actual deployment to the environment, the application will run in the global configuration mode, running in the global configuration mode can support specialization, And PUSH update.

Special configuration

The specialization requirement is described as the requirement when a configuration is configured as A for the global, but needs to be configured as a B for a server or an application.

In the present invention, default configuration information and special configuration information are saved in the global configuration database. After receiving the configuration information request message sent by the application server, the central server matches the matching parameters in the configuration information request message according to the maximum matching principle, and returns the matching default configuration information or special configuration information to the application server.

For example, in an embodiment of the present invention: the configuration information is saved according to the correspondence between the configuration information key value, the application name, and the application server name; the application server sends the configuration information key value, the application name, and the application server name to the central server. The configuration information request message of the three parameters; after receiving the request message, the central server first retrieves the configuration information from the configuration database according to the three parameters of the configuration information key value, the application name, and the application server name; If the matching item is retrieved, the configuration information is retrieved from the configuration database according to the configuration information key value and the application name; if the matching item is still not retrieved, the configuration information key value is used to retrieve the configuration data from the configuration database. Configuration information.

The system shown in Figure 9 supports two configuration text configurations and table configurations in the global configuration mode. The configuration is read from the central server through the rpc mode. The configuration table is consistent for all applications, and the configuration text can be used for different applications. Specialization.

The way to configure specialization is as follows:

1. When applying A to get the configuration, the loadText parameter will be submitted as follows.

a. Path="Tracing" shows the ear and Tracing's S set

b. Args = "Application=A;S erver=SERVER-A;", the fields in the 3⁄4 quotation marks have different key values.

2. After receiving the configuration request, the central server will compare the configuration of Path="Tracing" with the Args field, if the following two records exist.

c Args = "", Value = " Warn"

d. Args = "Application=A", Value="Info"

3. The central server will adopt the principle of maximum matching when selecting the configuration. Judging the equality with the most key values. If there are the same number of key-value pairs, the order of the key-value pairs appearing in the request is judged, and the first satisfaction will be returned;

4. According to the above discriminating rules, the central server will return Value="Info" to the application.

Specialized optional parameters include:

Group=server group name

Server= H server name

Npp=0. by name App Name

Configured PUSH update

The central server updates the configuration information in the global configuration database, and finds the application that uses the configuration information, and sends the updated configuration information to the application server where the application that uses the configuration information is located. Specifically: 1. The terminal initiates a configuration update request to the central server (specifically, the operation and maintenance personnel issue a configuration update request through the operation and maintenance tool, and the operation and maintenance tool submits the update request to the central server);

2. The central server updates the configuration information in the global configuration database, and finds the connection of the corresponding application process, and sends a configuration update request through the connection;

3. The corresponding application process re-acquires the configuration information from the central server, refreshes the configuration information, and returns the result to the central server;

4. The central server returns the result to the terminal.

Fourth, the monitoring system

Figure 10 is a schematic illustration of a monitoring system in accordance with an embodiment of the present invention. As shown in FIG. 10, the system adds a global monitoring database connected to the central server, a monitoring server connected to the global monitoring database, and a local log in each application server based on the system shown in FIG. 2. database. Due to space limitations, only the central server and an application server in Fig. 2 are schematically illustrated in Fig. 10.

In Figure 10, different monitoring policies are stored in the global monitoring database. The daemon process and the application process in the application server obtain the corresponding monitoring policy from the global monitoring database through the central server, monitor according to the acquired monitoring policy, save the monitoring result data to the local log database, and correspondingly according to the monitoring policy. The monitoring result data is uploaded to the global monitoring database through the central server, and an alarm flag is attached when the acquired data exceeds the threshold. The monitoring server displays the monitoring result data in the global monitoring database and prompts the alarm.

In FIG. 10, the monitoring server updates the monitoring policy in the global monitoring database, and then sends a monitoring policy update notification to the daemon and/or the application process in the specified application server; the protection process in the specified application server and/or After receiving the monitoring policy update notification, the application process obtains the corresponding updated monitoring policy from the global configuration server.

Specifically, the monitoring server sends an update monitoring policy command to the global monitoring database, and the global monitoring database updates the monitoring policy to return an response response message; the monitoring machine sends a monitoring policy update to the daemon and/or application process on the specified server. After the notification process is updated, the daemon and/or the application process on the specified server obtains the corresponding updated monitoring policy from the global monitoring database, which is to compare the version number of the existing monitoring policy with the global monitoring. The version number of the corresponding monitoring policy on the database is the same. If the information is inconsistent, the monitoring policy is obtained from the global monitoring database and the existing monitoring policy is updated with the obtained monitoring policy, and the update success message is returned to the monitoring server.

The global report server periodically obtains data from the local log database of each application server, summarizes it, saves it to the global report database, and displays the data in the global report database to the user. The daemon in the application server deletes data in the native log database for more than a certain amount of time (such as 7 days), which ensures that the data in the native log database does not exceed the limit.

In the system shown in Figure 10, the data sources for the monitoring and alarm system are divided into two types:

1. System resource counter (including CPU, memory, disk, 10, network traffic, etc., which can be directly retrieved from the operating system, usually a floating point number);

2. Program embedded counter, which is a system-specific internal report-based, dynamic specification report counter;

In this system, the system resource counter is monitored by the daemon master, and the program inline counter is monitored by the application process worker. The monitoring configuration of all counters (ie, the acquisition policy) is read by the Master and Worker from the global monitoring database through the central server. After reading the monitoring configuration, the Master and Worker will periodically store the data in the local log database according to the monitoring configuration, or upload it to the central server. Whether to upload depends on the configuration of the monitoring policy.

The system resource counters are monitored by the daemon in the application server; the monitored indicators include: CPU metrics, memory metrics, disk metrics, NIC traffic metrics, and MySQL metrics.

Specifically, the daemon obtains the monitoring configuration from the central server, and executes the script according to the content in the monitoring configuration to obtain the data, save the data to the local log database, and perform the following operations according to the monitoring configuration: 1) The threshold alarm is configured, and the obtained value exceeds the threshold, the data packet is uploaded to the central server, and the alarm flag is attached; 2) If the scheduled upload is configured, the data is directly packaged and uploaded to the central server. The central server saves the uploaded data to the global monitoring database.

The program embedded counter unique to the present invention will be mainly described below.

In the field of server-side development, performance counters are key indicators that reflect the health of a service. Under Windows, there are perfmon programs that can be used to monitor critical resources of the system, and applications can also record and extend the type of perfmon, and View real-time data through the perfmon tool, or store it. The latest version of Linux kernel is also supported with performance counters.

However, the counters related to the above operating systems are more difficult to meet the counting requirements at the service level. E.g:

1. The records of data are often several, and it is difficult to monitor and display thousands of data;

2. The type of the counter is limited to several types (number, frequency, average, hit rate), etc., and it is not possible to record information such as text, which is difficult to expand;

3. More attention to functions In real-time monitoring, it is not friendly to the daily recording operation of large-scale data.

Based on the above considerations, the present invention designs in-process program embedded counters to better support the recording and monitoring of business class data. FIG. 11 is a schematic diagram of an implementation manner of a program embedded counter in the embodiment of the present invention. Referring to Figure 11, the business code will output the relevant count to the embedded counter, and the client agent will acquire the counter collection strategy through the central server at the startup time, and periodically collect the data collection work of the program embedded counter, upload to The central server, or logging to the local log database, and alerting based on the threshold.

It can be seen that in the present invention, a program embedded counter is required to embed a built-in counter of the designed program in the application process; the application process in the application server monitors the embedded counter of the program according to the acquired monitoring policy.

In the present invention, the data structure of the program embedded counter is as follows:

- The program inline counter contains multiple categories with unique names ( Category );

- Multiple fixed columns can be included in each category;

- Each category contains multiple instances with unique names (also known as rows).

According to the above definition, the output of a defined program inline counter is shown in Table 11:

Cate or : "r c-client

Table 1 1

Where the column is fixed and the row is the same as the method name of the request, it may increase as the request increases.

Methods for generating a category include: determining the name of the category, setting an output column for the category, a set of atomic counters and atomic counter operations for the category, a data format for the snapshot of the category, and an output based on the snapshot data for the category The method of the instance.

Specifically, in an embodiment of the present invention, a category (Category) is defined by:

1. Define a unique name, that is, specify the name of the category;

2. Define the output column of the category; the type of the column can be an integer, a floating point number, and a string;

3. Define the original data type and method of operation: Define a set of atomic counters and atomic counters for that class;

4. Define the data format of the snapshot of the category; include the direct structure taken from the atomic counter;

5. Define a method for calculating an output instance based on the snapshot data of the category; that is, defining a method for calculating a report output line from two snapshots;

6. Define the summary method for the output instance of this category, which is the summary method for defining the report row.

According to the above description, a method of customizing a hit rate counter (ie, a class that implements hit rate calculation) is as follows:

1. Specify a unique name for the category; here is "cached-hit-ratio";

2. Define the output columns for this category as: Visits per second (/sec), Hit ratio (ratio); There are two columns here;

3. Define the atomic counter and the method of operation: The raw data of the hit rate counter contains two integer atomic counters, the first atomic counter hitted and the second atomic counter missed;

The hit code is incremented by one when the business code record hits;

Missed one by one when the business code record misses;

4. The data format of the snapshot defining the category is: save the count value of the first atomic counter at the time of generating the snapshot, the count value of the second atomic counter, and the system time;

5. Define the method for calculating the output instance based on the snapshot data of the category, that is, calculate the output line of the report according to the two snapshots as follows: Calculate the total number of accesses, the number of hits, and the interval between the two snapshots according to the data of the two snapshots, and then Obtaining the number of visits per second according to the ratio of the total number of visits and the interval between the two snapshots, and obtaining the hit ratio according to the ratio of the number of hits to the total number of visits;

For example, the output line is calculated from two snapshots with interval T. When we define time 0, we get snapshot snapshotl. When time T is passed again, snapshot snapshot2 is obtained here. The output calculation formula is

Report. total = (sna shot2.hitted+ shapshot2. missed) - (snapshot l .hitted + snapshot l . missed)

Report. hitted = (snapshot2. hitted - snapshot l .hitted)

Report. interval = (snapshot2.time - snapshot l .time)

The output line shows the data as

(call ./sec) : total I interval

(hit ratio) : hitted I total

6. The summary method for defining the output instance of this category is as follows: The total number of accesses of each instance is summed to obtain the total number of accesses after the summation, and the number of hits of each instance is summed to obtain the number of hits after the summary, after summarizing The interval between two snapshots is equal to the interval between snapshots of the instance. The interval between snapshots of each instance is equal. Such as:

Summary. total = sum(report. total)

Summary. hitted = sum(report. hitted) Summary, interval = report. interval;

The sum ( ) operation represents the summation, and the summed data of each row is consistent.

The service code in the application process finds the category calculated by the hit rate according to the category name, and finds the corresponding instance of the category calculated by the hit rate according to the instance name, and adds the first atom counter in the corresponding instance when the service hits 1. Add 1 to the second atomic counter in the corresponding instance when the service is missing.

After the program inline counter is designed, each time the code is triggered, the data is stored in the memory of the application process. After the application process is started, the monitoring steps are as follows:

1. The application process establishes a long connection with the central server;

2. The application process obtains the monitoring configuration of the machine;

3. The central server returns a monitoring configuration suitable for the application server according to the name of the application server;

4. The application server starts the monitoring thread and runs at a fixed time;

5. After the fixed time, the application process will take a snapshot of the program embedded counter. If there is a snapshot acquired last time, the last result will be calculated with two snapshots, otherwise the current snapshot will be counted to the last time. In the result;

6. If there is a calculation result, perform the following operations according to the recording mode:

a) N0NE, not recorded;

b) ALL: store all instance records in the local log database;

c) SUMMARY: The records of all instances are summarized and stored in the local log database;

7. If there is a calculation result, perform the following operations according to the upload mode;

a) N0NE, not recorded;

b) ALL: Upload all the records of the instance to the central server.

c) SUMMARY: The records of all instances are summarized and packaged and uploaded to the central server;

8. Determine whether the calculation result exceeds the threshold. If the threshold is exceeded, the calculation result is attached to the alarm record and uploaded to the central server. Fifth, the development of auxiliary systems

Plug-in based development

In the Java-based application development of the present invention, an extension plug-in system (Eclipse) is generated based on the existing plug-in system (Eclipse), and the extension plug-in connection development management server implements the following functions:

Create and manage engineering components and implement a version-based upgrade system;

Create the application's framework code;

Implement the generation of code for the RemoteAppBean call and assist in managing dependency information;

Enable injection debugging of the application.

Version management of components

In this system, the dependencies of different versions of components need to be developed. The way to rely on the version of the iftH library is as follows: For example, when developing Appsl.O, the dependency is Framework- l.O.jar, BizLibrary-1.0-jar;

When developing Apps 2.0, the dependencies are Framework- 1.1.jar, BizLibrary-2.0-jar.

The system solves this problem in this way, and defines the version as follows:

Version 1.0, dependent libraries include: Framework-1.0.jar; BizLibrary- 1.0.jar;

Version 2.0, dependent libraries include: Frame work- 1.1. jar; BizLibrary-2.0.jar.

This version information is created by the development administrator. Each time you upgrade the version, you need to add this configuration information to the configuration management server's configuration repository.

Dependency configuration establishment when creating a new project

When creating an App project, development needs to select a current version. When the developer selects the version, the plugin performs the following steps:

1. Obtain information about the dependent package through the development management server;

2. Get a specific version of the package;

3. Add dependencies to the current App project environment;

4. Write the version number to the META-INF/AppBean.properties version (this version will also affect the program's online, as well as grayscale release)

Dependent configuration upgrade of old projects

When we need to upgrade the old application based on the newly released base library, for example, when upgrading the library to version 2.0, the steps to upgrade the version 1.0 application to version 2.0 are as follows:

1. The developer selects the current version to 2.0;

2. The plugin reads the dependent library information of the 2.0 version to the version management system;

3. The plug-in downloads the dependency plug-in for the development management system configuration;

4. Replace local dependencies; 5. The upgrade was successful.

Generation of calling code for RemoteApp Beans

RemoteAppBean is the core concept of implementing application access and application hierarchy in this system. When RemoteAppBean is implemented and uploaded to the central server via AppLoader, any application that wants to access this RemoteAppBean needs to generate a proxy class for this RemoteAppBean call.

When developing an application that needs to access RemoteAppBean, the extension gets all the exposed RemoteAppBeans from the development management server and displays its information to the developer, and the developer selects the RemoteAppBean to be called; the extension's reflection from the selected RemoteAppBean The information obtains the following information: application name and type information; the extension generates a request and response type entity class based on the obtained information; the extension creates a proxy class according to the request and response entity type, and inserts the proxy class into the Need to access the application of RemoteAppBean.

Specific steps are as follows:

1. The developer starts the RemoteAppBean dependency;

2. The plugin accesses the development management platform and obtains all current public RemoteAppBeans, and returns and displays the information to the developer;

3. The developer selects the RemoteAppBean to be called;

4. The plugin gets the following information from the reflection information of the RemoteAppBean:

a) @AppName: application name;

b) type information, including: request, response, and context type;

5. The plugin generates a request based on the above information, and responds to the type entity class. The process is as follows:

a) AppLoader saves the request and response type as reflected intermediate data and saves it in the management platform library;

b) if this type exists in the reference of the project, directly refer to the class;

c) otherwise the plugin regenerates the code of the class of the request and response type based on the intermediate data;

6. Using the request obtained in the previous step, and the response type, create a proxy class, the proxy class will use the context type obtained in step 4;

7. Insert the initialization of the proxy class into the called AppBean.

Dependency detection

In large-scale complex platforms, the dependency between different services is a very difficult problem to manage.

In the present invention, the dependency information between the created applications is displayed, and the dependency information is detected during the update process of the application to determine whether or not to perform the update of the application.

When AppLoader adds an existing App project, it will save the dependency information as follows:

Caller

Callee

Dependent request parameter type information;

Dependent response parameter type information.

For example, when application B depends on application A, the system creates dependency information:

Caller: B

Called by: A

Dependent request parameter type information: A.RequestArgs

Dependent parameter type information: A.ResponseArgs

Dependency detection during the application's update process

B has a dependency on A, but when A is upgraded to A', the steps for dependency detection are as follows:

1. The deployment program uploads the application Α', and initiates an update instruction;

2. The deployment program finds that the application depends on Α. In this case, there are two possibilities for comparing the request and response parameters of A' and Β to ::

a) A' request and response parameters are compatible (equal, or backward compatible) with A's request and response parameters, the system allows updates, and both A and B are marked as update programs;

b) A's request and response parameters are not compatible with A's request and response parameters, and the system will not allow updates unless B updates are also submitted, or B is taken offline.

Version test scope estimate

According to the description of the previous scenario, when a version of the application is developed, the system records the update records at all points in time, so that when the system administrator determines the online version, it can extract the time from a certain point in time. A list of application scopes that may be affected after the point.

This list can be used for automatic test range judgment. The extraction steps are as follows:

1. Identify all applications that are updated after the point in time; 2. Identify applications that depend on these applications; 3. Recursively find the application in step 2 until there is no reference location; 4. Incorporate all identified applications into the test scope . Injection debugging

In general, debugging an application requires deploying the program to the actual running environment (test environment or production environment), but the application deployed to the test environment is difficult to debug. The system invents an injection solution. Solve developer debugging issues for the runtime environment.

The solution is: the extension plugin launches the application locally; the launched application creates a connection with the proxy server, and sends a configuration parameter to the proxy server to debug the application; the configuration parameter of the application to be debugged defines the user within the specified range; the proxy After receiving the client request message, the server first matches the configuration parameter of the application to be debugged, and if the matching succeeds, sends a client request message to the activated application process, and returns the processing result of the started application. Send to the client, if the match is unsuccessful, distribute the client request to the application server where the corresponding application is located.

Figure 12 is a schematic illustration of an injection type debugging system in accordance with an embodiment of the present invention. Referring to Figure 12, the plug-in is connected to the proxy server in the system shown in Figure 2, and only the proxy server and application server clusters in the system shown in Figure 2 are illustrated.

As shown in Figure 12, in a normal operating environment, the client's request is sent directly to the proxy server, which then sends the specific application server based on the application configuration, as described in the previous section.

The steps to inject debugging are as follows:

1. An application launched through a plugin creates a long connection with a specific type of proxy server (each created) and listens for requests;

2. The application sends an injection request to the proxy server, and sends the configuration parameters of the debugged application to the proxy server, wherein the configuration parameter of the plug-in restriction application must include a grayscale parameter (that is, it can only affect users in a fixed range);

3. The proxy server will add an injection item to the local routing table;

4. When the proxy server listens for a request from the client, it will judge whether the request satisfies the current injection condition; the request that does not satisfy the injection condition will be routed according to the original routing logic.

5. The request that satisfies the injection condition forwards the request to the application launched by the plugin through a long connection established by the plugin with the proxy server;

6. The application will convert the request from the connection into a normal request, pass it to the application for processing, and send the response back to the proxy server, and downlink to the client through the proxy server;

7. After the application exits, the connection to the proxy server will be interrupted, and the proxy server will automatically remove the injection.

This enables the injection and debugging of the environment on the development machine.

Application access across the application service platform system

In the environment across the IDC equipment room, the deployment structure in each equipment room is consistent with the structure shown in Figure 2 above. That is, each IDC room has an application service platform system as shown in Figure 2. Here each IDC is called a Site.

FIG. 13 is a schematic structural diagram of multiple application service platform systems in an embodiment of the present invention. As shown in Figure 13, each IDC has an application service platform system as shown in Figure 2. A gateway is added to each application service platform system, and each application service platform system communicates through the gateway. Private line communication can be used between gateways, or compressed and encrypted public network communication.

It can be seen that the gateway communicates with the gateways in other application service platform systems to implement application cross-application service platform system access. Specifically, in each application service platform system:

a central server, configured to find an application configuration information list item corresponding to an application that needs to be accessed across platforms in the application service platform system, and send the information to the gateway of the application service platform system;

a gateway, configured to send the received corresponding application configuration information list item information to a gateway in another application service platform system; and configured to receive an application configuration information list item sent by a gateway in another application service platform system, and on the local server The list of local application configuration information is processed as follows:

For each application configuration information list item received, if there is a corresponding item in the local application configuration information list, and the application process name is not the gateway, it is ignored, if there is no corresponding corresponding in the local application configuration information list If the item or the existing application process name is a gateway, the local application configuration information list is updated by using the received application configuration information list item, and the remote system field is added in the updated application configuration information list item, and the value of the field is added. Set to the source system of the received application configuration information list item.

When accessing an application across an application service platform system:

The gateway first obtains the corresponding application configuration information list item from the central server of the application service platform system, and checks whether the application metadata label in the corresponding application configuration information list item includes the peer system label; if the peer system label is included, Determining a target application service platform system according to an application context of the application; if the peer system annotation is not included, determining a target application service platform system by using a remote system field in the corresponding application configuration information list item; and applying the service according to the determined target application The platform system knows the address of the gateway of the target application service platform system, and forwards the application access request to the gateway of the target application service platform system;

The gateway is further configured to forward the request to the corresponding application configuration information list and the application running information list on the central server in the application service platform system after receiving the application access request sent by the gateway of the other application service platform system. Applications.

In the present invention, an application service platform system that only supports data and applications related to users in the application service platform system is defined as a peer-to-peer system (PeerSite); users and other users within the application service platform system will be hosted. The application service platform system for the data and application of the application service platform system user is defined as a non-peer system (Non-PeerSite); According to the previous definition, there is an additional GetSiteName() method in the AppContext, which can obtain the cross-site (that is, cross-application service platform system) access of the PeerSite RemoteApp Bean to which the context belongs.

In the embodiment of the present invention, only the RemoteAppBean can be accessed through the gateway at the framework level, and other beans can only be accessed in the Site, and the method of the RemoteAppB ean access is as follows:

1. If a RemoteAppBean is only related to a user in a PeerSite, add a peer system annotation in the application metadata annotation of the RemoteAppBean; if a RemoteAppBean is not associated with a user in a specific PeerSite, the application metadata annotation of the RemoteAppBean No equivalent system annotations are added;

That is, RemoteAppBean has an additional annotation @PeerSite; where @PeerSite is defined as follows: If the application is user-dependent and must be part of the user's PeerSite, then the annotation @PeerSite must be added; if the RemoetAppBean is in multiple sites The deployment is not user-dependent, so you don't need to label @PeerSite

2. Synchronizing the routing information of each RemoteAppBean that is not related to the user in the specific peer system through the gateway between the application service platform systems;

3. Implementing access to the RemoteAppBean cross-application service platform system that is not associated with users in a particular peer system based on the synchronized routing information.

Synchronization of routing tables between multiple sites

The gateway is responsible for the routing of RemoteAppBeans between different sites. Because the routing of AppBeans in this system is dynamic (application configuration information list and application running information list), routing synchronization is dynamically performed among multiple sites.

Synchronizing the routing information of each RemoteAppBean that is not related to the user in a specific PeerSite through the gateway between the application service platform systems includes:

The central server in each application service platform system finds the RemoteAppBean that does not include the peer system annotation @PeerSite in the application metadata annotation deployed in the application service platform system, and the RemoteAppBean that needs to be synchronized (the RemoteAppBean labeled @PeerSite does not. Synchronization), and the corresponding application configuration information list item of the RemoteAppBean that needs to be synchronized is sent to the gateway of the application service platform system, and the gateway of the application service platform system sends the received corresponding application configuration information list item information to other application services. a gateway in the platform system;

The gateway that receives the corresponding application configuration information list item is processed as follows: For each application configuration information list item received, if there is a corresponding item in the local application configuration information list, and the application process name is not the gateway Ignore, if there is no corresponding item in the local application configuration information list or exists but the application process name is the gateway, the local application configuration information list is updated with the received application configuration information list item, and is updated. The remote system RemoteSite field is added to the application configuration information list item, and the value of the field is set to the source system of the received application configuration information list item.

It can be seen that the gateway synchronizes the routing data of the non- PeerSite type RemoteAppBean deployed in each site between the sites. When looking for the routing address of the RemoteAppBean, the corresponding gateway of the RemoteAppBean can be found.

Routing step of RemoteApp Bean

Access to the cross-application service platform system of RemoteAppBeans that are not related to users in a particular peer system PeerSit based on the synchronized routing information includes:

1. When accessing a RemoteAppBean that is not related to a user in a specific peer system, first obtain a corresponding application configuration information list item from the central server of the application service platform system;

2. Check whether the application metadata annotation in the corresponding application configuration information list item includes the peer system annotation @PeerSite;

If the peer system annotation @?66 is included, the target application service platform system is determined by the application context of the RemoteAppBean;

If the peer system annotation @PeerSite is not included, the target application service platform system is determined by the remote system RemoteSite field in the corresponding application configuration information list item;

3. Learning, according to the determined target application service platform system, the address of the gateway of the target application service platform system, and forwarding the access request to the gateway of the target application service platform system through the gateway of the application service platform system;

4. After receiving the access request, the gateway of the target application service platform system forwards the request to the corresponding RemoteAppBean according to the application configuration information list and the application operation information list on the central server in the system.

It can be seen from the above that the application service platform system consisting of the above proxy server, application server cluster, central server and resource server integrates the distributed server resources logically and is developed for a single signaling application. And the development method based on the basic framework class library and the business framework class library greatly reduces the development difficulty of the application, improves the flexibility of deployment and reduces the difficulty of deployment.

The above is only the preferred embodiment of the present invention, and is not intended to limit the present invention. Any modifications, equivalents, improvements, etc., which are made within the spirit and principles of the present invention, should be included in the present invention. Within the scope of protection.

Claims

Claim

A method for implementing an application service platform system, characterized in that a proxy server and a cloud computing application service system are set in an application service platform system, and the description information of the application and the application and the application server are saved in the cloud computing application service system. Correspondence between the two; the method includes:

2. The method according to claim 1, wherein the application service platform system is developed based on the following hierarchical structure: development! a framework class library, wherein the basic framework class library defines implementations of multiple application component AppBean foundation types, application context interfaces, and basic application context types to provide basic core functions; wherein different AppBean base types correspond to different types of applications, For processing different types of signaling;

According to the business characteristics, develop a business framework class library customized for the business based on the basic framework class library;

Based on the ^ftli framework class library and business framework class library, develop applications that implement business requirements; and, based on the base framework class library and the business framework class library, implement the service-based routing and load-bearing functions of the proxy server.

3. The method according to claim 2, wherein the AppBean base type comprises: a hypertext transfer protocol application component HttpAppBean that processes a hypertext transfer protocol HTTP request, and a remote call application component that processes a remote procedure call protocol RPC request. RemoteAppBean, and any application component JobAppBean that handles timed tasks;

When a new type of application needs to be developed, the method further includes: extending an AppBean base type corresponding to the new type of application in the business framework class library, and extending an application context for the new type of application in the business framework class library.

The method according to claim 1, wherein the application context comprises two parts in data composition: a universal resource identifier URI: including index information of the user, and is responsible for subsequent resource positioning;

Additional data: Includes attribute information for the app.

5. A method according to any one of claims 1-4, characterized in that

The cloud computing application service system includes: a central server, a resource server, and an application server cluster composed of a plurality of application servers; wherein, the resource server needs to save the tasks requested by each application on the application server to process the client request message. Access to data resources;

Hosting and running the application on the application server cluster;

The saving the description information of the application and the correspondence between the application and the application server in the cloud computing application service system include: the central server receives the externally uploaded application, saves the description information of the application to the application configuration information list, and applies the application Deployed to the application server in the application server cluster; the application server in the application server cluster uploads the running information of the loaded application to the application running information list on the central server for saving the correspondence between the application and the application server. ;

The application configuration information list includes the following information: an application ID, an application name, an application type, an application process name, and an application metadata identifier; the application operation information list includes the following information: an application process name and an application service address;

The proxy server receives the client request message, parses the client request message, determines the corresponding application, and distributes the client request message to the application server where the corresponding application is located according to the correspondence between the application and the application server. The proxy server parses the client request message when receiving the client request message, and identifies the application corresponding to the client request message by querying the application configuration information list on the central server, and queries the application on the central server. The configuration information list and the application running information list obtain the service address of the corresponding application, and distribute the client request message to the application server where the corresponding application service is located according to the obtained service address.

The method according to claim 5, wherein the proxy server creates an application context according to the description information of the application, including:

When receiving the client request message, the proxy server extracts the request parameter from the client request message, queries the application configuration information list in the central server, and searches for the application configuration information list item that meets the request parameter and the metadata label field, and then according to the application configuration information list item. The information about the processing application context in the metadata label field in the application configuration information list item creates an application context.

The method according to claim 5, wherein the central server further saves a resource list; the resource list includes the following information: a resource name, a resource type, an application context type, a positioning algorithm name, and a positioning algorithm parameter; The application processes the task requested by the client request message, and the data resource location according to the application context includes: after receiving the client request message, the application according to the application in completing the task requested by the client request message The resource and the corresponding information in the resource list are used for resource location.

The method according to claim 5, wherein the proxy server parses the client request message when receiving the client request message, and identifies the client by querying the application configuration information list on the central server. The application corresponding to the end request message includes:

When receiving the HTTP request message, the proxy server searches for the application metadata tag field on the central server according to the uniform resource locator URL in the request message, and includes an application configuration information list item with the URL-based information, according to The application name in the found application configuration information list item identifies the application corresponding to the client request message;

Or,

When receiving the Rpc request message, the proxy server searches for the application configuration information list item whose application name field is consistent with the remote calling service name on the central server according to the remote calling service name in the request message, according to the found application. The application name field in the configuration information list item identifies the application corresponding to the request message;

The obtaining, by the application configuration information list and the application running information list on the query center server, the service address of the corresponding application includes: searching, by the proxy server, the application process name in the searched application configuration information list item, The application process name field includes an application running information list item that is consistent with the application process name, and obtains the service address information of the application from the found application running information list item.

The method according to claim 5, wherein the method further comprises:

Dividing a plurality of application servers in the application server cluster into a plurality of different groups;

Saving an application server list and an application server grouping list on the central server; wherein the application server list includes the following information: an application server name, a group name to which the application server belongs, and an application server address; the application server grouping list includes: an application server group name And application server description information in the group;

When receiving the externally uploaded application, the central server deploys the application to a single application server according to external instructions, or deploys to multiple servers belonging to the same group.

The method according to claim 9, wherein the deploying the application to the application server in the application server cluster by the central server comprises:

The method according to claim 10, wherein the application server list on the central server further comprises: a server port pool range;

The method also includes:

After the daemon on each application server is started, obtain the port pool range of the application server from the application server list on the central server, test the port number in the port pool range that has not been turned on, and mark it as available;

When an application process is started, if the dynamic port in the corresponding application process deployment information list item is marked as a dynamic port, the daemon process learns the port number required by the application process according to the service port in the corresponding application process deployment information list item. Quantity, and extract the corresponding number of port numbers from the port pool range of the application server to the application process, and mark the assigned port number as occupied;

When the application process exits, the daemon returns the port number occupied by the application process to the port pool.

12. The method according to claim 10, wherein the method further comprises:

The client establishes a connection with the central server, and provides the central server with the application process identification information to be accessed by the central server; the central server reads the application process list and the application operation information list, and returns a record matching the application process identification information provided by the client to the client. The client parses the received content, and selects a record for routing;

When the application process list or the application running information list changes, the central server notifies the client that the client re-acquires the record from the central server that matches the application process identification information that it wants to access.

13. The method according to claim 10, wherein the method further comprises:

Add a control terminal connected to the central server;

The control terminal sends a request to the central server to start the specified application process, and the central server sends the request to the corresponding daemon, and the daemon starts the specified application process, and the application process connects to the daemon, and the daemon sends the request to the application process. , the application process invokes a service startup method;

The control terminal sends a request to the central server to stop the specified application process, and the central server sends the request to the corresponding daemon, and the daemon sends the request to the specified application process, and the application process invokes the stop method of the service, and the daemon stops. The application process.

The method according to claim 10, wherein a control terminal connected to the central server is added, the method further comprising the process of updating the application process, and updating the specified application process A to the application process A' specifically includes:

The control terminal sends a request to update the A to A' to the central server, and the central server sends the request to the corresponding daemon. The daemon stops the application process A first, then slams ', and overwrites with A' to start a new one. Application processΑ';

Or,

The control terminal sends a request for updating with the A' to the central server, and the central server sends the request to the corresponding daemon, the deployment package of the daemon, and the application process A, the application process A, and the start to the center The server registers; then, the control terminal sends a request for updating A to the central server, and the central server sends the request to the corresponding daemon, and the daemon sends the request to the application process A, and the application process A deletes itself on the central server. Registration information, the application process A stops.

The method according to claim 10, further comprising: performing a hot update process on the application, specifically: the central server sends an update instruction to a daemon of the corresponding application server; the daemon processes the new application. , starting a new application process, the new application process establishes a connection with the central server, the central server records the connection information in the application running information list for the new application process; the central server updates the application process name in the application configuration information list, and This change is synchronized to all listening clients.

The method of claim 10, further comprising: configuring the application configuration information list on the central server, specifically:

Parsing the application's JAVA application release jar package, and saving the parsed data in the application component list and the application package list; wherein, the application component list includes: an application type, an application version, an application name, an application metadata annotation, an input parameter type, Output parameter types, dependencies, and package identifiers; the application package list includes: the package identifier, the package version, and the service address where the package is located;

A list of application configuration information is generated based on the application component list and the application package list.

The method according to claim 5, wherein the method further comprises: performing grayscale publishing on the application in the application service platform system, wherein the application configuration information list further comprises: a grayscale publishing factor; For applications that do not use grayscale publishing, set their corresponding grayscale publishing factor to null;

After receiving the client request message, the proxy server identifies the application corresponding to the client request message by using the application configuration information list on the query center server. If multiple applications are found, the proxy server selects the following manner;

The proxy server first matches its grayscale publishing factor in an application whose grayscale publishing factor is not empty. If the matching hits, the selected application is selected. If there is no matching hit, the application whose grayscale publishing factor is empty is selected.

The method according to claim 17, wherein the grayscale publishing factor is a conditional expression;

The proxy server first matches its grayscale publishing factor in an application whose grayscale publishing factor is not empty, including:

The proxy server parses the client request message, determines a corresponding list item in the application configuration information list on the central server, creates an application context according to the information in the corresponding list item, and matches the grayscale publishing factor according to the created application context. The condition information matches the grayscale release factor, and if it meets the condition expressed by the grayscale release factor, it hits.

The method according to claim 17 or 18, wherein, after the application B of the application B and the call B is issued, the corresponding upgrade versions B' and A' are gray-scaled, and B is 'The gray factor is set to match the version number of A', then the process after the client requests the message to route to A' is as follows:

A, in the application configuration information list, look for the application to be called, find B and B,; because B, the grayscale publishing factor is not empty, so first match; A, get the version number of itself and match B, the gray Degree release factor, hit; A, select B, as the application to call.

The method according to claim 5, wherein the method further comprises:

Add a global configuration database that is connected to the central server to hold the configuration information of the application;

The application server sends a configuration information request message to the central server;

After receiving the configuration information request message sent by the application server, the central server retrieves the corresponding configuration information from the global configuration database and returns it to the application server.

The method according to claim 20, wherein the default configuration information and the special configuration information are saved in the global configuration database;

After receiving the configuration information request message sent by the application server, the central server retrieves the corresponding configuration information from the global configuration database and returns the information to the application server. The central server receives the configuration information request message sent by the application server, according to the The maximum matching principle matches the matching parameters in the configuration information request message, and returns the matched default configuration information or special configuration information to the application server.

22. The method according to claim 20, wherein the method further comprises:

The terminal initiates a configuration update request to the central server;

The central server updates the configuration information in the global configuration database, and finds the connection of the corresponding application process, and sends a configuration update request through the connection;

The corresponding application process re-acquires the configuration information from the central server, refreshes the configuration information, and returns the result to the central server; the central server returns the result to the terminal.

The method according to claim 20, further comprising: the application server acquiring the configuration information from the local location of the application server;

The application server switches between the mode of obtaining the configuration information from the central server remotely and the mode of obtaining the configuration information from the local device by switching the remote loading module and the local loading module.

The remote loading module is configured to send a configuration information request message to the central server, and receive configuration information returned by the central server. The local loading module is configured to obtain configuration information locally from the application server.

The method according to claim 10, wherein the method further comprises:

Add a global monitoring database connected to the central server, a monitoring server connected to the global monitoring database; and add a native log database to each application server;

Save different monitoring policies in the global monitoring database;

The daemon process and the application process in the application server obtain the corresponding monitoring policy from the global monitoring database through the central server, monitor according to the acquired monitoring policy, save the monitoring result data to the local log database, and correspondingly according to the monitoring policy The monitoring result data is uploaded to the global monitoring database through the central server, and an alarm flag is attached when the acquired data exceeds the threshold;

The monitoring server displays the monitoring result data in the global monitoring database and prompts the alarm.

The method according to claim 24, wherein the monitoring process in the application server is performed according to the acquired monitoring policy, including:

The system resource counters are monitored by the daemon in the application server; the monitored indicators include: CPU metrics, memory metrics, disk metrics, NIC traffic metrics, or MySQL metrics.

The method according to claim 24, wherein the application process in the application server performs monitoring according to the acquired monitoring policy, including:

The design program embeds the counter, embedding the embedded counter of the designed program in the application process;

The application process in the application server monitors the program embedded counter according to the acquired monitoring policy.

27. The method according to claim 26, wherein the design program inline counter comprises: the design program inline counter comprises a plurality of categories with unique names; each category comprises a plurality of fixed columns and multiple names The only instance;

The method according to any one of claims 24 to 27, wherein the method further comprises:

The monitoring server updates the monitoring policy in the global monitoring database, and then sends a monitoring policy update notification to the daemon and/or application process in the specified application server;

After receiving the monitoring policy update notification, the daemon and/or the application process in the specified application server obtains the corresponding updated monitoring policy from the global configuration server.

The method according to claim 5, wherein in the development of the application, the method further comprises: generating an extension based on the plug-in system Eclipse, the extension creating and managing engineering components, implementing a version-based upgrade System, create application framework code, implement generation of RemoteAppBean calling code, assist in managing dependency information, and implement injection debugging of the application.

30. The method of claim 29, wherein the generating of the RemoteAppBean calling code by the extension comprises:

When developing an application that needs to access RemoteAppBean, the extension gets all the exposed RemoteAppBeans from the development management server and displays its information to the developer, and the developer selects the RemoteAppBean to be called.

The extension plugin obtains the following information from the reflection information of the selected RemoteAppBean: application name and type information; the type information includes type information of the request, the response, and the context;

The extension generates a request and response type entity class based on the obtained information;

The extension creates a proxy class based on the request and response entity type and inserts the proxy class into the application that needs to access the RemoteAppBean.

31. The method according to claim 30, wherein the method further comprises: displaying dependency information between the created applications, and detecting the dependency information during the update process of the application to determine whether to update the application.

The method according to claim 31, wherein the detecting the dependency information in the update process of the application to determine whether to perform the update of the application comprises:

When the application A is updated with the upgraded application A', it is determined whether there is an application B that depends on the application A;

If it exists, it is judged whether the request and response parameters of the application A' are compatible with the request and response parameters of the application A, and the update is allowed, otherwise the update is not allowed.

33. The method according to claim 29, wherein the implementing the injecting debugging of the application by the extension comprises: the extension plugin launching the application locally;

The launched application creates a connection with the proxy server, and sends a configuration parameter to the proxy server to debug the application; the configuration parameter of the application to be debugged defines a user within the specified range;

After receiving the client request message, the proxy server first matches the configuration parameter of the application to be debugged, and if the matching succeeds, sends a client request message to the initiated application processing, and returns the processed application. The result is sent to the client. If the match is unsuccessful, the client request is distributed to the application server where the corresponding application is located.

The method according to claim 5, wherein the method further comprises:

Implementing a plurality of said application service platform systems, adding a gateway in each application service platform system, and communicating between the application service platform systems through the gateway;

An application service platform system that only supports data and applications related to users in the application service platform system is defined as a peer-to-peer system; data and application applications of users and other users within the application service platform system will be hosted. The platform system is defined as a non-peer system;

The application component RemoteAppBean is remotely invoked through the gateway to access the application service platform system.

35. The method according to claim 34, wherein the accessing the RemoteAppBean to the application service platform system by using the gateway comprises:

If a RemoteAppBean is only associated with a user in a peer system, add a peer system annotation to the application metadata annotation of the RemoteAppBean; if a RemoteAppBean is not associated with a user in a particular peer system, the application element of the RemoteAppBean No equivalent system labeling is added to the data annotation;

Routing information of each RemoteAppBean that is not related to a user in a specific peer system is synchronized by the gateway between the application service platform systems;

Access to a cross-application service platform system of RemoteAppBeans that are not associated with users in a particular peer system is implemented based on the synchronized routing information.

36. The method according to claim 35, wherein the synchronizing the routing information of each RemoteAppBean that is not related to the user in the specific peer system by the gateway between the application service platform systems comprises:

The central server in each application service platform system finds the RemoteAppBean that does not include the peer system annotation in the application metadata annotation deployed in the application service platform system, as the RemoteAppBean that needs to be synchronized, and configures the corresponding application of the RemoteAppBean that needs to be synchronized. The information list item is sent to the gateway of the application service platform system, and the gateway of the application service platform system sends the received corresponding application configuration information list item information to the gateway in the other application service platform systems;

The gateway that receives the corresponding application configuration information list item is processed as follows: For each application configuration information list item received, if there is a corresponding item in the local application configuration information list, and the application process name is not the gateway Ignore, if there is no corresponding item or exists in the local application configuration information list but the application process name is the gateway, the local application configuration information list is updated with the received application configuration information list item, and is updated. The remote system field is added to the application configuration information list item, and the value of the field is set to the source system of the received application configuration information list item.

37. The method according to claim 36, wherein the implementing, by the synchronized routing information, access to a cross-application service platform system of a RemoteAppBean that is not related to a user in a specific peer system comprises:

When accessing a RemoteAppBean that is not related to a user in a specific peer system, first obtaining a corresponding application configuration information list item from a central server of the application service platform system;

Check whether the application metadata annotation in the corresponding application configuration information list item includes the peer system annotation;

If the peer system annotation is included, the target application service platform system is determined according to the application context of the RemoteAppBean; if the peer system annotation is not included, the target application service platform is determined by the remote system field in the corresponding application configuration information list item. System

Obtaining, according to the determined target application service platform system, the address of the gateway of the target application service platform system, and forwarding the access request to the gateway of the target application service platform system through the gateway of the application service platform system;

After receiving the access request, the gateway of the target application service platform system forwards the request to the corresponding RemoteAppBean according to the application configuration information list and the application operation information list on the central server in the system.

38. An application service platform system, the system comprising: a proxy server and a cloud computing application service system, wherein an application server cluster in the cloud computing application service system is loaded and runs an application, and the cloud computing application service The description information of the application and the correspondence between the application and the application server are saved in the system;

39. The system according to claim 38, wherein: the application service platform system is configured with: a basic framework class library and a business framework class library;

The underlying framework class library, which defines and implements implementations of various AppBean-based ftH types, application context interfaces, and basic application context types to provide iftH core functionality; wherein different AppBean base types correspond to different types of applications for handling different Type of signaling;

A business framework library for customizing the functions of the business according to the characteristics of the business;

The application deployed in the cloud computing application service system is based on the ^ftH framework class library and the business framework class library, and loads and runs an application to implement a service requirement function;

The proxy server is configured to receive a client request message, and route the received client request message based on the basic framework class library and the service framework class library.

40. The system of claim 39, wherein:

The service framework class library also provides an interface for extending the AppBean base type corresponding to the new type application, and an interface for extending the application context for the new type application;

The application context consists of two parts in the data composition:

Universal resource identifier URI: includes the user's index information, responsible for subsequent resource location;

Additional data: Includes attribute information for the app.

The system according to any one of claims 38 to 40, wherein the cloud computing application service system comprises: a central server, a resource server, and an application server cluster composed of a plurality of application servers;

The application configuration information list includes the following information: an application ID, an application name, an application service type, an application process name, and an application metadata annotation; the application operation information list includes the following information: an application process name and an application service address;

a resource server, configured to save a data resource that needs to be accessed when each application on the application server processes the task requested by the client request message;

The proxy server, when receiving the client request message, is configured to identify an application service corresponding to the client request message by using an application configuration information list on the query center server, and then query the application configuration information list and application on the central server. The service information list obtains the service address of the corresponding application, and distributes the client request message to the application server where the corresponding application service is located according to the obtained service address;

The central server is further configured to save a resource list; the resource list includes the following information: a resource name, a resource type, an application context type, a positioning algorithm name, and a positioning algorithm parameter;

42. The system of claim 41, wherein:

The proxy server is configured to: when the HTTP request message is received, find, according to the uniform resource locator URL in the request message, that the application metadata label field on the central server includes an application configuration that is related to the URL information. The information list item identifies the application corresponding to the client request message according to the application name in the searched application configuration information list item; or

The proxy server is configured to: when the Rpc request message is received, find an application configuration information list item that is consistent with the remote calling service name on the central server according to the remote calling service name in the request message, according to The application name field in the found application configuration information list item identifies the application corresponding to the request message;

The proxy server is configured to search for the central server according to the name of the application process in the searched application configuration information list item. The application process name field includes an application operation information list item that is consistent with the application process name information, obtains the service service address information of the application from the found application operation information list item, and uses the service address information of the application to serve the client. The end request message is distributed to the application server where the corresponding application is located;

The proxy server is configured to create an application context according to the information about the processing application context in the application metadata label field in the found application configuration information list item.

43. The system according to claim 41, wherein a plurality of application servers in the application server cluster are divided into a plurality of different groups;

The application server list and the application server grouping list are saved on the central server;

The application server list includes the following information: an application server name, a group name to which the application server belongs, and an application server address; the application server grouping list includes: an application server group name and an application server description information in the group;

The central server is configured to deploy the application to a single application server according to an external instruction when receiving the externally uploaded application, or deploy to multiple servers belonging to the same group.

44. The system of claim 43 wherein:

A daemon is deployed on each application server;

The application server list is also saved on the central server; the application process list includes: an application process identifier, a dynamic port identifier, an application server name, an application server group name, a deployment package interface, and a service port;

a central server, configured to determine, according to information in the application server list, the application server grouping list, and the application process list, a list of application process deployment information that should be started on each application server; each item in the application process deployment information list includes: Application process ID, dynamic port tag, deployment package interface, and service port;

The central server records its connection information in the daemon status information list for each daemon that establishes the connection, and records its connection information in the application operation information list for each application process that establishes the connection.

The system according to claim 44, wherein the system further comprises: a control terminal connected to the central server; the control terminal sends a request to the central server to start the specified application, and the central server sends the request to the corresponding guardian The process starts, the daemon starts the application process, and the application process connects to the daemon, and the daemon sends the request to the application process, and the application process starts the specified application;

The control terminal sends a request to the central server to stop the specified application, and the central server sends the request to the corresponding daemon, and the daemon sends the request to the application process, and the application process stops the specified application, and the daemon stops the application process. .

46. The system according to claim 41, wherein, in the system, grayscale is issued to the application, the application configuration information list further includes: a grayscale publishing factor; and for an application that does not use grayscale publishing, The corresponding grayscale publishing factor is empty;

The system according to claim 41, wherein the system further comprises: a global configuration database, configured to save configuration information of the application; the configuration information includes default configuration information and special configuration information;

The application server is configured to send a configuration information request message to the central server, and receive configuration information returned by the central server. The central server is configured to: after receiving the configuration information request message sent by the application server, request the configuration information according to the maximum matching principle. The matching parameters are matched, and the matched default configuration information or special configuration information is returned to the application server.

48. The system of claim 47, wherein:

The central server is further configured to receive a configuration update request initiated by the terminal, update the configuration information in the global configuration database, and find a connection of the corresponding application process, and send a configuration update request through the connection, so that the corresponding application process is re-routed. The central server obtains configuration information, refreshes the configuration information, and returns the result to the central server;

The central server returns the results to the terminal.

The system according to claim 47, wherein the application server comprises: a remote processing module and a local processing module;

a remote loading module, configured to send a configuration information request message to the central server, and receive configuration information returned by the central server; and a local loading module, configured to obtain configuration information locally from the application server;

The application server switches between the mode of obtaining configuration information remotely from the central server and the mode of obtaining configuration information locally by switching the remote loading module and the local loading module.

50. The system of claim 44, wherein the system further comprises: a global monitoring database coupled to the central server, a monitoring server coupled to the global monitoring database; each application server further including a native log database ; Global monitoring database for saving different monitoring strategies;

The daemon process and the application process in the application server obtain the corresponding monitoring policy from the global monitoring database through the central server, monitor according to the acquired monitoring policy, save the monitoring data to the local log database, and according to the monitoring policy The corresponding monitoring result data is uploaded to the global monitoring database through the central server, and an alarm flag is attached when the acquired data exceeds the threshold;

The monitoring server is used to display the monitoring result data in the global monitoring database and prompt the alarm.

51. The system of claim 50, wherein:

The daemon in the application server monitors system resource counters according to the obtained monitoring policy; the monitored indicators include: CPU indicator, memory indicator, disk indicator, network card traffic indicator or MySQL indicator;

The application embedded process counter is embedded in the application process in the application server, and the application process in the application server monitors the embedded counter of the program according to the acquired monitoring policy;

The program inline counter includes: a plurality of categories with unique names; each category includes a plurality of fixed columns and a plurality of instances with unique names.

52. The system of claim 50 or 51, wherein

The monitoring server is further configured to update the monitoring policy in the global monitoring database, and then send a monitoring policy update notification to the protection process and/or the application process in the specified application server;

After receiving the monitoring policy update notification, the protection process and/or the application process in the specified application server obtains the corresponding updated monitoring policy from the global configuration server.

The system according to claim 41, wherein the system further comprises: an extension plugin for implementing injecting debugging of the application;

The extension is used to launch an application locally; the launched application creates a connection with a proxy server, and sends a configuration parameter to the proxy server to debug the application; the configuration parameter of the application to be debugged defines a user within a specified range;

After receiving the client request message, the proxy server first matches the configuration parameter of the application to be debugged, and if the matching succeeds, sends a client request message to the application processing initiated on the plug-in, and the launched application is The returned processing result is sent to the client. If the matching is unsuccessful, the client request is distributed to the application server where the corresponding application is located.

54. The system according to claim 41, wherein the application service platform system further comprises a gateway, and the gateway communicates with a gateway in another application service platform system to implement access of the application across the application service platform system;

The central server is configured to find an application configuration information list item corresponding to an application that needs to be accessed across platforms in the application service platform system, and send the information to the gateway of the application service platform system;

The gateway is configured to send the received corresponding application configuration information list item information to a gateway in another application service platform system; and receive an application configuration information list item sent by a gateway in another application service platform system, and The list of local application configuration information on the server is handled as follows:

The system according to claim 54, wherein, when the application is to be accessed across the application service platform system, the gateway first obtains a corresponding application configuration information list item from the central server of the application service platform system, and views the corresponding application. Whether the application metadata annotation in the configuration information list item includes the peer system annotation; if the peer system annotation is included, the target application service platform system is determined according to the application context of the application; if the peer system annotation is not included, Determining, in the corresponding application configuration information list item, a target application service platform system; obtaining, according to the determined target application service platform system, an address of the gateway of the target application service platform system, and forwarding the application access request to the target application Gateway to the service platform system;