Hierarchical architecture system

Abstract

The invention provides a layered architecture system, which comprises an application layer comprising a plurality of applications, and each application is configured with an application rule; the interface layer comprises a plurality of interfaces, and each application rule corresponds to at least one interface; the strategy engine unit is configured to analyze the application rule and call an interface corresponding to the application rule according to an analysis result of the application rule; the service layer comprises a component library, the component library comprises a plurality of components, and each component corresponds to one operation logic; and the flow arrangement unit is configured to set flow standards for the interfaces, and the set flow standards correspond to the corresponding components and the execution sequence of the components. According to the embodiment of the invention, loose coupling of application logic and bottom layer implementation is realized, and the quick response capability and research and development multiplexing capability of application scene change are improved by adopting a mode of configuring application rules.

Description

Technical Field

[0001] The present application relates to the field of e-commerce, and in particular, to a layered architecture system. Background Art

[0002] Compared with the rapid development of high-performance and high-availability architecture models in recent decades, the development of scalable architecture models has indeed faltered. When designing the system architecture, many applications neither consider the size of the team and the development of the application, nor the support of the basic technology, which makes the application logic and technology in the system architecture highly coupled. Therefore, when a set of technical architecture needs to support multiple application lines, it often appears to be unable to do so, resulting in the dilemma that the service architecture needs to be adjusted according to the application architecture. At the same time, in application scenarios with short delivery cycles and frequent changes, there is often a situation where the number of R&D personnel cannot meet the demand, and the stability of the system needs to be taken into account while developing application functions. The newly joined R&D personnel are often unfamiliar with the entire system architecture, which makes the cost of intervention development high.

[0003] Therefore, how to open up the capabilities of the system architecture so that new R&D personnel can better complete application co-construction is an important issue that needs to be urgently addressed in current architecture design. Summary of the invention

[0004] This application aims to propose a layered architecture system to solve the problem of large development workload when the current system architecture needs to support multiple applications.

[0005] According to one aspect of the present application, a layered architecture system is proposed, comprising: an application layer, comprising multiple applications, and each of the applications is configured with application rules; an interface layer, comprising multiple interfaces, wherein each of the application rules corresponds to at least one of the interfaces; a policy engine unit, configured to parse the application rules and call the interface corresponding to the application rules according to the parsing results of the application rules; a service layer, comprising a component library, wherein the component library contains multiple components, and each of the components corresponds to an operation logic; a process orchestration unit, configured to set process standards for the interfaces, and the set process standards correspond to the corresponding components and the execution order of the components.

[0006] According to some embodiments, the process orchestration unit includes: a workflow sub-unit, configured to configure a process standard for each interface; a componentized development sub-unit, configured to determine the corresponding components from the component library of the service layer according to the process standard, and determine the execution order of the corresponding components.

[0007] According to some embodiments, the process orchestration unit is further configured to perform real-time hot replacement of components corresponding to the process standard.

[0008] According to some embodiments, any two components in the component library are decoupled from each other.

[0009] According to some embodiments, the application layer is configured to configure a corresponding configuration file for each of the applications, and each of the configuration files includes application rules corresponding to the application; the policy engine unit is further configured to parse the configuration file and call an interface corresponding to the configuration file based on the parsing result.

[0010] According to some embodiments, the application layer is further configured to modify application rules corresponding to the application in response to a modification instruction of the configuration file.

[0011] According to some embodiments, the policy engine unit includes an execution engine subunit, and the execution engine subunit is configured to parse the configuration file and call an interface corresponding to the application rule.

[0012] According to some embodiments, each of the application rules corresponds to at least two interfaces, and any two interfaces corresponding to the same application rule are independent of each other.

[0013] According to some embodiments, the execution engine subunit is further configured to control the communication between the at least two interfaces corresponding to the same application rule in a data flow and / or event flow manner.

[0014] According to some embodiments, the at least two interfaces corresponding to the same application rule include a first interface and a second interface, and the first interface transmits output data and / or output events of the first interface to the second interface through the execution engine subunit.

[0015] According to the embodiments of the present application, by abstracting the reusable functions of multiple applications into multiple universal components, loose coupling of application logic and underlying implementation is achieved, and the rapid response capability to changes in application scenarios and R&D reuse capabilities are improved by adopting the method of configuring application rules.

[0016] It should be understood that the foregoing general description and the following detailed description are exemplary only and are not restrictive of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for describing the embodiments. By describing the exemplary embodiments in detail with reference to the drawings, the above and other objectives, features and advantages of the present application will become more apparent.

[0018] Figure 1 A device block diagram of a layered architecture system according to an exemplary embodiment of the present application is shown.

[0019] Figure 2 A schematic diagram of a process of abstracting the application flow of a supply chain platform according to an exemplary embodiment of the present application is shown.

[0020] Figure 3 A schematic diagram of an application isolation process according to an example embodiment of the present application is shown.

[0021] Figure 4 A schematic diagram of execution logic of an execution engine subunit according to an exemplary embodiment of the present application is shown.

[0022] Figure 5 A schematic diagram of a workflow execution process in a process orchestration unit according to an exemplary embodiment of the present application is shown.

[0023] Figure 6 A schematic diagram of a component-based development principle according to an example embodiment of the present application is shown.

[0024] Figure 7 A schematic diagram showing the principle of component thermal replacement according to an exemplary embodiment of the present application is shown.

[0025] Figure 8 A schematic diagram of a supply chain platform system architecture according to an example embodiment of the present application is shown.

[0026] Fig. 9 A schematic diagram showing the principles of a process orchestration according to an exemplary embodiment of the present application is shown.

[0027] Fig.10 A schematic diagram of a policy engine principle according to an example embodiment of the present application is shown.

[0028] Fig.11 An electronic device according to an exemplary embodiment of the present application is shown. DETAILED DESCRIPTION

[0029] Example embodiments will now be described more fully with reference to the accompanying drawings. However, example embodiments can be implemented in many forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this application will be comprehensive and complete and will fully convey the concepts of the example embodiments to those skilled in the art. In the figures, the same figures show the same or similar parts, and thus their repeated description will be omitted.

[0030] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of relevant countries and regions, and provide corresponding operation entrances for users to choose to authorize or refuse.

[0031] The described features, structures or characteristics may be combined in one or more embodiments in any suitable manner. In the following description, many specific details are provided to provide a full understanding of the embodiments of the present disclosure. However, those skilled in the art will appreciate that the technical solutions of the present disclosure may be practiced without one or more of these specific details, or other modes, components, materials, devices or operations may be adopted. In these cases, known structures, methods, devices, implementations, materials or operations will not be shown or described in detail.

[0032] The flowcharts shown in the accompanying drawings are only exemplary and do not necessarily include all the contents and operations / steps, nor must they be executed in the order described. For example, some operations / steps can be decomposed, and some operations / steps can be combined or partially combined, so the actual execution order may change according to actual conditions.

[0033] The terms "first", "second", etc. in the specification and claims of this application and the above-mentioned drawings are used to distinguish different objects, rather than to describe a specific order. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device that includes a series of steps or units is not limited to the listed steps or units, but optionally includes steps or units that are not listed, or optionally includes other steps or units inherent to these processes, methods, products or devices.

[0034] As mentioned above, when the system architecture of many applications was first built, neither the size of the team and the development of the application were considered, nor the support of the basic technology was considered, which resulted in a high degree of coupling between the application logic and technology in the system architecture. This means that when the application is subsequently expanded, the more changes are made, the greater the investment, and the greater the possibility of errors. Therefore, when a set of technical architecture needs to support multiple application lines, it often appears to be unable to do so, resulting in the dilemma that the service architecture needs to be adjusted according to the application architecture. Therefore, how to avoid too large a scope of changes during expansion is the main concern for the scalability of software architecture.

[0035] In order to solve the complicated hard-coding problem when the existing system architecture is expanded, according to the embodiment of this application, a policy engine that supports multi-application process orchestration services is proposed based on the construction of universal capabilities. In this embodiment, by abstracting the reusable capabilities of each application party, multiple uncoupled component modules are formed, and dynamic configuration and low-code process orchestration and other solutions are used to achieve rapid access to different application parties, and support rapid application iteration, improve the scene capabilities of application custom process classes, and improve the rapid response capabilities and R&D reuse capabilities of application process class scene changes, thereby achieving rapid iteration of products, greatly improving R&D efficiency, and achieving the purpose of reducing costs and increasing efficiency.

[0036] Before describing the embodiments of the present application, the terms appearing in the present application are first explained.

[0037] Engine: The supporting part of a program or a system. The engine is a highly abstract and encapsulated application scenario that is independent of the specific application scenario.

[0038] Process orchestration: Process orchestration is a method of managing application processes by breaking down application processes into multiple stages and steps to implement specific application logic. The key point is to decompose, aggregate, and orchestrate application processes at the bottom of the system to form a process that implements specific application logic.

[0039] Policy engine: is a software system for logical judgment and decision automation. It allows users to define a series of application rules, and then automatically execute these rules based on input data to make decisions or take actions. In this embodiment, the policy engine includes:

[0040] Rule definition: used to define application logic. The definition process does not require writing traditional code.

[0041] Logical separation: The configured application rules are separated from the application code, making the modification and maintenance of application rules more flexible and convenient.

[0042] Condition matching: The policy engine evaluates the application rule conditions based on the input data and performs the corresponding actions.

[0043] Easy to maintain: Because application rules are written in a declarative manner, changes to application logic can be made by modifying the rules instead of the code.

[0044] Diamond storage audit rules is a centralized service solution for persistent configuration information. Diamond not only simplifies the management process of configuration information, but also enhances the flexibility and scalability of the system.

[0045] Open Data Processing Service (ODPS) is a distributed processing service for TB / PB-level data with low real-time requirements. It mainly serves the storage and calculation of batch structured data, and can provide solutions for massive data warehouses and analytical modeling services for big data.

[0046] ScheduleX: A task scheduling service that is mainly used to manage and schedule scheduled tasks and workflows, especially suitable for complex task orchestration in big data processing scenarios.

[0047] MetaQ: A message middleware based on queue model.

[0048] Swift: "Middleware" in Swift is a way of handling HTTP requests and responses.

[0049] The specific embodiments of the present application are described in detail below in conjunction with the accompanying drawings.

[0050] Figure 1 A device block diagram of a layered architecture system according to an exemplary embodiment of the present application is shown. Figure 1 The device shown includes an application layer 101 , an interface layer 103 and a service layer 105 , as well as a policy engine unit 102 and a process orchestration unit 104 .

[0051] According to an embodiment of the present application, the application layer 101 includes multiple applications, and each application is configured with application rules.

[0052] In a specific embodiment, the application layer 101 is responsible for specific application implementation, including calling various resources to implement specific application functions.

[0053] According to an embodiment of the present application, the interface layer 103 includes multiple interfaces, wherein each application rule corresponds to at least one interface.

[0054] In a specific embodiment, the interface layer 103 is responsible for processing external requests and responses, including defining interface specifications and data transmission formats.

[0055] According to an embodiment of the present application, the policy engine unit 102 is configured to parse the application rules in the application layer 101 and call an interface corresponding to the application rules according to the parsing result of the application rules.

[0056] In this embodiment, the policy engine unit 102 serves as an implementation path between the application layer 101 and the interface layer 103. The application layer 101 does not directly call the interface of the interface layer 103 according to the application rules configured for each application, but calls the corresponding interface in the corresponding interface layer 103 after parsing the application rules of each application through the policy engine unit 102.

[0057] In some embodiments, a corresponding configuration file is configured for each application at the application layer 101, and each configuration file includes application rules corresponding to the application. The policy engine unit 102 is configured to parse the configuration file and call an interface corresponding to the configuration file according to the parsing result.

[0058] In other embodiments, the configuration file may also be configured in the policy engine unit 102, and the application in the application layer 101 may be associated with the corresponding configuration file. When the application in the application layer 101 is called, the policy engine unit 102 parses the configuration file corresponding to the application and calls the corresponding interface in the interface layer 103.

[0059] In a specific embodiment, the configuration file corresponding to each application defines the interface corresponding to the application and the implementation logic corresponding to the interface. When the implementation logic of the application needs to be added or modified, only the corresponding configuration file needs to be modified, that is, the corresponding interface or the operation logic corresponding to the interface needs to be modified.

[0060] According to an embodiment of the present application, the service layer 105 includes a component library, wherein the component library includes multiple components, and each component corresponds to an operation logic.

[0061] In order to enable rapid access and iterative upgrades to applications, in some embodiments, the operational logic in the application is metadataized, and key information, attributes, and features of each application in the application layer 101 are extracted and managed in a standardized manner to connect to each application, thereby achieving application isolation.

[0062] For example, the implementation logic in the application is abstracted into multiple atomic nodes, and the entire application logic is implemented through flexible orchestration within the atomic nodes and combined orchestration between atomic nodes.

[0063] In practice, according to the characteristics of each application, key information, attributes and features of each application are extracted, and dynamically choreographed strategies, i.e. application rules, are configured for each application. In a specific embodiment, application isolation is achieved by implementing logic in the application to correspond to the configured application rules according to data such as the attributes and features of the application.

[0064] Figure 2 A schematic diagram of an abstract process of an application flow of a supply chain platform according to an exemplary embodiment of the present application is shown. Figure 2 As shown, the supply chain is abstracted from the processes of generating hyperlink applications, determining commodity supply relationships (or product supply relationships), and transactions.

[0065] like Figure 3 As shown, in order to realize the automated operation of goods on the supply chain platform, the large stores in the supply chain are used as the unified caliber for dividing application lines. Different application parties maintain a set of standardized application rules at the bottom layer, including application identification, application name, large store ID and a series of dynamically choreographed strategies (that is, application rules), thereby establishing a mapping relationship between application line-large store-goods, so that the input, execution and output nodes of any process at the bottom layer of the system can correspond to the configured application rules of the specified application line through goods or stores, complete different application actions, and achieve the purpose of application isolation.

[0066] In this embodiment, the atomic nodes are configured as mutually decoupled components, each interface corresponds to a combination of one or more components, and in response to the modification of the configuration file corresponding to the application, the interface corresponding to the configuration file, or the component corresponding to the interface corresponding to the configuration file, is adjusted.

[0067] According to an embodiment of the present application, the process orchestration unit 104 is configured to set a process standard for the interface, and the set process standard corresponds to the corresponding components and the execution order of the components.

[0068] In this embodiment, the process orchestration unit 104 serves as a connecting bridge between the interface layer 103 and the service layer 105. The interface layer 103 does not directly call the components in the service layer 105, but calls the components according to the components and component sequence set by the process orchestration unit 104 for each application.

[0069] According to an embodiment of the present application, the policy engine unit 102 includes an execution engine subunit, and is configured to parse the configuration file and call the interface corresponding to the application rules. In practice, it is necessary to use the execution engine subunit to parse the configured application rules and execute the conditions and rules therein. In a specific embodiment, the application layer 101 does not directly call the interface of the interface layer 103 according to the application rules configured for each application, but performs unified parsing and scheduling through the execution engine subunit using the configured application rules to support the flexibility and diversity of the application logic.

[0070] In some embodiments, each application rule corresponds to at least two interfaces, and any two interfaces corresponding to the same application rule are independent of each other. In a specific embodiment, the execution engine subunit controls the communication between at least two interfaces corresponding to the same application rule in the form of data stream and / or event stream.

[0071] In some embodiments, the at least two interfaces corresponding to each application rule include a first interface and a second interface, and the first interface transmits output data and / or output events of the first interface to the second interface through the execution engine subunit.

[0072] like Figure 4 As shown, four application rules, namely, product functions, scheduled tasks, real-time messages and OpenApi, are configured for product applications. Each application rule configures corresponding decoupled interface services (i.e., atomic strategies, including OpenHyperlinkAuditService, OpenHyperlinkCopyService, OpenHyperlinkQuitService, OpenHyperlinkBiddingService, OpenHyperlinkCleanService, OpenHyperlinkManualAuditService, OpenHyperlinkSupplyService, and OpenHyperlinkSignUpService defined in the figure), and interface services do not communicate directly with each other. In practice, the application rules call the corresponding interface services through the execution engine sub-unit, and pass the output data and / or output events of the first interface to the second interface through the execution engine sub-unit. For example, the output data of OpenHyperlinkSignUpService is passed to OpenHyperlinkCleanService through the execution engine sub-unit.

[0073] According to the embodiments of the present application, the process orchestration unit 104 abstracts two capability models, namely workflow and componentized development, based on the generalized process. The workflow is used to formulate application processes, decouple the application process and the specific implementation logic, and provide a friendly programming interface. When faced with multiple different application demands, you only need to consider "what to do" in a specific process link and "what" the upstream and downstream processes are.

[0074] Figure 5 FIG. 1 shows a schematic diagram of a workflow execution process in a process arrangement unit according to an exemplary embodiment of the present application. Figure 5 As shown, in a specific application, the defined application process is: after the registration or update process, the manual review process is executed, and the registration or update process and the manual review process do not involve their respective implementation logics.

[0075] According to other embodiments, componentized development is used to carry the diversity of application logic, transforming the traditional waterfall-style code into an orchestration structure with components as the core concept, and the components can be arbitrarily orchestrated and decoupled from each other.

[0076] For example, Figure 6 As shown in the figure, the traditional waterfall-style code is transformed into an orchestration structure with components as the core concept. Figure 6 The components shown include a, b, s and d, and the arrangement rule is the order of a, b, s and d. In practice, the components can be Java components or Diamond components, and this application does not limit the component type.

[0077] For example, in a specific embodiment, the process orchestration unit 104 includes a workflow sub-unit and a componentized development sub-unit, wherein the workflow sub-unit is configured to configure a process standard for each interface; the componentized development sub-unit is configured to determine the corresponding component from the component library of the service layer according to the process standard, and determine the execution order of the corresponding component.

[0078] In some embodiments, the process arrangement unit is further configured to perform real-time hot replacement of components corresponding to the process standard. That is, when faced with a scenario where the application logic needs to be changed, a component can be added to the arranged logic flow in real time.

[0079] like Figure 7 As shown, the orchestration rule consisting of the order of components a, b, c and d is modified to a, c or b, s and d. The policy engine unit evaluates the application rule conditions according to the input data and determines whether the specific implementation is a, c, s and d or a, b, s and d.

[0080] The following uses a specific application scenario as an example to illustrate the method of hot replacement of components.

[0081] For example, in the system audit process, a series of audit rules are formulated, including sku verification, inventory verification, and fulfillment service threshold verification. As the application advances, there will be frequent demands to adjust the audit process. Therefore, when implementing the function, Diamond is used to store the audit rules, and the component library of the audit rules is abstracted, and the audit process is customized and quickly adjusted according to actual needs. According to this embodiment, the audit rules can be flexibly changed as needed without modifying the code or redeploying the system. This can improve the flexibility and maintainability of the system and meet the needs of quickly adjusting the application logic.

[0082] According to the embodiments of the present application, by abstracting the reusable functions of multiple applications into multiple universal components, loose coupling of application logic and underlying implementation is achieved, and the rapid response capability to changes in application scenarios and R&D reuse capabilities are improved by adopting the method of configuring application rules.

[0083] Figure 8 A schematic diagram of a supply chain platform system architecture according to an exemplary embodiment of the present application is shown, Figure 8The supply chain system architecture shown includes product layer, application layer, interface layer, service layer and support platform as well as strategy engine and process orchestration unit.

[0084] like Figure 8 As shown, in order to ensure that the differences between the layers are clear enough and the boundaries are detailed enough, the support platform adopts a big data processing platform (for example, ODPS) and relies on middleware systems such as ScheduleX, MetaQ, and Swift. At the same time, it relies on core external applications including the tag center, indicator center, and data center as support; process orchestration is used as a bridge between the service layer and the interface layer, and the policy engine is used as an implementation path from the interface layer to the application layer. Among them, the service layer is responsible for maintaining a series of component libraries for use by the upper layer, including calls to external systems and data processing; the interface layer is responsible for processing external requests and responses, including defining interface specifications and data transmission formats; the application layer is responsible for specific application implementation, including calling various resources and implementing specific functions. Through the introduction of process orchestration and policy engines, clear boundaries and connections between layers can be guaranteed, and at the same time, the flexibility and maintainability of the system are improved.

[0085] This application adopts the componentization concept to form a component library that is compatible with different application domains. In this implementation, the collection of component libraries is defined as the service layer, and the ability of the component library to provide services upward is uniformly implemented by process orchestration, which ensures clear boundaries and connections between the service layer and the interface layer, and effectively avoids the problem of service abuse leading to a sharp expansion of system complexity. At the same time, through process orchestration, there is no need for direct calls between components, but scheduling through the process engine, thereby reducing the coupling between components.

[0086] This embodiment uses process orchestration as its foundation and builds a tool-based and configurable low-code process orchestration engine to enable the application of customized process scenarios, thereby improving the ability to quickly respond to changes in application process scenarios and the R&D reuse capability.

[0087] Fig. 9 A schematic diagram showing a process arrangement principle according to an exemplary embodiment of the present application is shown, as shown in FIG. Fig. 9 As shown, the interface layer defines the component sets corresponding to the same interface for different applications, and the process orchestration defines the process standard for each application, that is, the execution sequence of the corresponding component set.

[0088] For example, when the process orchestration of the embodiment of the present application is used to execute the car manufacturing process, although different car models may have different appearance, performance and functional requirements, they all have some common basic modules, such as engine, chassis, body, etc. According to the embodiment of the present application, these modules can be abstracted and standardized. In order to meet different personalized needs and improve the production efficiency of the assembly line, the whole vehicle architecture is decomposed into several independent and interrelated modules (or components) according to certain principles to achieve the maximum commonality of module parts, and have the ability to produce different positioning and level models by adjusting and combining different modules.

[0089] In this embodiment, the policy engine is used to separate the application rules from the code and manage them in the form of configuration files to facilitate modification and expansion of the rules. At the same time, through the policy engine, new policies can be easily added or existing policies can be modified without modifying the underlying generalized interface, thereby improving the stability and maintainability of the system.

[0090] This embodiment realizes the automatic processing of application processes through the policy engine, completes the separation of application logic implementation and application system architecture, and can expand new application functions without changing the application system architecture.

[0091] like Fig.10 As shown, different application rules are configured for each application, where the application rules include the corresponding interface and the policy (or component) corresponding to each interface, and support addition and modification. When the application logic needs to be adjusted, only the logic of the corresponding interface needs to be added or modified. Among them, the implementation of different application logics is the policy. At the same time, by modifying the configuration, the specific policy to be used can be specified. In addition, since each application is isolated from each other, the influence between each other is avoided, which improves the stability of the system.

[0092] For example, for application A, the policy configured for the corresponding interface 1 is policy 1; for application B, the policy configured for the corresponding interface 1 is policy 2. Application A and application B do not affect the call to interface 1 of each other.

[0093] For another example, for application A, the policy configured for the corresponding interface 1 is policy 1; when the logic of interface 1 corresponding to application A needs to be modified to policy 2, it is only necessary to modify the configuration information of application A and change the policy of the corresponding interface 1 to policy 2. The entire modification process does not require modifying the underlying universal interface, thereby improving the stability and maintainability of the system.

[0094] Fig.11 An electronic device according to an exemplary embodiment of the present application is shown. Fig.11 The electronic device 200 according to this embodiment of the present application is described. Fig.11The electronic device 200 shown is merely an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0095] like Fig.11 As shown, the electronic device 200 is in the form of a general computing device. The components of the electronic device 200 may include, but are not limited to: at least one processing unit 210, at least one storage unit 220, a bus 230 connecting different system components (including the storage unit 220 and the processing unit 210), a display unit 240, etc.

[0096] The storage unit stores program codes, which can be executed by the processing unit 210, so that the processing unit 210 executes the methods described in this specification according to various exemplary embodiments of the present application. For example, the processing unit 210 can execute the following: Figure 1 The method shown in .

[0097] The storage unit 220 may include a readable medium in the form of a volatile storage unit, such as a random access memory unit (RAM) 2201 and / or a cache memory unit 2202 , and may further include a read-only memory unit (ROM) 2203 .

[0098] The storage unit 220 may also include a program / utility 2204 having a set (at least one) of program modules 2205, such program modules 2205 including but not limited to: an operating system, one or more application programs, other program modules, and program data, each of which or some combination may include an implementation of a network environment.

[0099] Bus 230 may represent one or more of several types of bus structures, including a memory unit bus or memory unit controller, a peripheral bus, an accelerated graphics port, a processing unit, or a local bus using any of a variety of bus architectures.

[0100] The electronic device 200 may also communicate with one or more external devices 300 (e.g., keyboards, pointing devices, Bluetooth devices, etc.), may also communicate with one or more devices that enable a user to interact with the electronic device 200, and / or communicate with any device that enables the electronic device 200 to communicate with one or more other computing devices (e.g., routers, modems, etc.). Such communication may be performed via an input / output (I / O) interface 250. Furthermore, the electronic device 200 may also communicate with one or more networks (e.g., a local area network (LAN), a wide area network (WAN), and / or a public network, such as the Internet) via a network adapter 260. The network adapter 260 may communicate with other modules of the electronic device 200 via the bus 230. It should be understood that, although not shown in the figure, other hardware and / or software modules may be used in conjunction with the electronic device 200, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0101] Through the description of the above implementation methods, it is easy for those skilled in the art to understand that the example implementation methods described here can be implemented by software or by combining software with necessary hardware. The technical solution according to the implementation method of the present application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, a USB flash drive, a mobile hard disk, etc.) or on a network, including several instructions to enable a computing device (which can be a personal computer, a server, or a network device, etc.) to execute the above method according to the implementation method of the present application.

[0102] The software product may use any combination of one or more readable media. The readable medium may be a readable signal medium or a readable storage medium. The readable storage medium may be, for example, but not limited to, a system, device or device of electricity, magnetism, light, electromagnetic, infrared, or semiconductor, or any combination thereof. More specific examples (non-exhaustive list) of readable storage media include: an electrical connection with one or more wires, a portable disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof.

[0103] Computer readable storage media may include data signals propagated in baseband or as part of a carrier wave, wherein readable program codes are carried. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The readable storage medium may also be any readable medium other than a readable storage medium, which may send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, device, or device. The program codes contained on the readable storage medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical cable, RF, etc., or any suitable combination thereof.

[0104] Program code for performing the operations of the present application may be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java, C++, etc., and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user computing device, partially on the user device, as a separate software package, partially on the user computing device and partially on a remote computing device, or entirely on a remote computing device or server. In the case of a remote computing device, the remote computing device may be connected to the user computing device through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0105] The computer-readable medium carries one or more programs. When the one or more programs are executed by a device, the computer-readable medium implements the aforementioned functions.

[0106] Those skilled in the art will appreciate that the above modules can be distributed in the device according to the description of the embodiment, or can be changed accordingly and only used in one or more devices different from the embodiment. The modules of the above embodiments can be combined into one module, or further divided into multiple sub-modules.

[0107] According to an embodiment of the present application, a computer program is provided, including a computer program or an instruction. When the computer program or the instruction is executed by a processor, the method described above can be executed.

[0108] The embodiments of the present application are described in detail above. Specific examples are used herein to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method and its core idea of ​​the present application. At the same time, changes or deformations made by those skilled in the art based on the ideas of the present application, the specific implementation methods and the scope of application of the present application, all belong to the scope of protection of the present application. In summary, the content of this specification should not be construed as a limitation on the present application.

Claims

1. A layered architecture system, characterized in that: include: The application layer includes a plurality of applications, and each of the applications is configured with application rules; An interface layer, comprising a plurality of interfaces, wherein each of the application rules corresponds to at least one of the interfaces; A policy engine unit, configured to parse the application rule and call an interface corresponding to the application rule according to the parsing result of the application rule; The service layer includes a component library, wherein the component library includes a plurality of components, and each of the components corresponds to an operation logic; The process arrangement unit is configured to set a process standard for the interface, and the set process standard corresponds to the corresponding components and the execution order of the components.

2. The layered architecture system according to claim 1, characterized in that: The process arrangement unit comprises: A workflow subunit, configured to configure process standards for each interface; The componentized development subunit is configured to determine corresponding components from the component library of the service layer according to the process standard, and determine the execution order of the corresponding components.

3. The layered architecture system according to claim 1, characterized in that: The process orchestration unit is also configured to perform real-time hot replacement of components corresponding to the process standard.

4. The layered architecture system according to claim 1, characterized in that: Any two components in the component library are decoupled from each other.

5. The layered architecture system according to claim 1, characterized in that: The application layer is configured to configure a corresponding configuration file for each application, and each configuration file includes an application rule corresponding to the application; The policy engine unit is further configured to parse the configuration file and call an interface corresponding to the configuration file according to the parsing result.

6. The layered architecture system according to claim 5, characterized in that: The application layer is further configured to modify the application rules corresponding to the application in response to the modification instruction of the configuration file.

7. The layered architecture system according to claim 6, characterized in that: The policy engine unit includes an execution engine sub-unit, and the execution engine sub-unit is configured to parse the configuration file and call an interface corresponding to the application rule.

8. The layered architecture system according to claim 7, characterized in that: Each of the application rules corresponds to at least two interfaces, and any two interfaces corresponding to the same application rule are independent of each other.

9. The layered architecture system according to claim 8, characterized in that: The execution engine subunit is further configured to control the communication between the at least two interfaces corresponding to the same application rule in a data stream and / or event stream manner.

10. The layered architecture system according to claim 9, characterized in that: The at least two interfaces include a first interface and a second interface, and the first interface transmits output data and / or output events of the first interface to the second interface through the execution engine subunit.

Images