Product feeding system

Abstract

The invention discloses a product input delivery system, which comprises a system configuration center, a system multi-terminal public capability plug-in set component, a public cross-terminal service component, a Graphql-based client interface data request component, an oss file server component, a login component, an input channel and a product type, differentiated processing of role services, a log burying point component and a high-concurrency deployment strategy based on a cloud platform. The reusability of the component is greatly improved, and compared with a common development mode, the development efficiency has obvious advantages and is improved.

Description

Technical Field

[0001] The present invention relates to the field of product delivery, and in particular to a product delivery system. Background Art

[0002] In the product delivery system, the architecture of the front-end system is often relatively backward, and often encounters complex business scenarios such as high concurrency, multiple products, multiple channels, and multiple roles; the following dilemmas are often encountered:

[0003] 1. The front-end is overloaded with large-scale concurrent access traffic, and the service cannot be accessed;

[0004] 2. There are many channels for submitting applications, with different product types and inconsistent roles. Many front-end architecture systems have low adaptability to the technical side of the above problems and low scalability, resulting in insufficient ability to digest business needs and making it difficult to be agile.

[0005] 3. For relatively complex submission processes, the core public capabilities are often not extracted, the business coupling of products in the process is too large, resulting in the inability to extract the core submission standards, too low component function reuse between business lines, and the system is too bloated.

[0006] 4. There is no or very little log monitoring (including user behavior and system-level and business-level log data) in the application process nodes. It is difficult or impossible to do corresponding log analysis on various types of data at various stages of project operation to provide good technical support for project maintenance, operation analysis, performance attribution, etc. for later personnel.

[0007] 5. For the application process of the same scenario, the front-end of many projects finds it difficult to cope with the delivery needs of multiple channels (h5, app, WeChat applet, Douyin applet), and completely use a set of codes to adapt to multiple terminals.

[0008] In the game of dealing with the above problems or phenomena that plague front-end developers, how to find a development theory that suits your own team in these predicaments, and summarize and precipitate a set of scientific and effective methods, technical theories, and architectural solutions that conform to the modern agile development model will become a very realistic technical need for front-end development, and even a new direction and new trend of thought.

[0009] Because the delivery channel system is essentially business-oriented, the architecture of many systems is based on the business of each company, and most of them are self-developed. There are few or basically no open source frameworks or solutions for us to learn from. However, most development scenarios and implementations focus on back-end capabilities, while the front-end focuses more on business attributes. Overall, there are the following disadvantages:

[0010] 1. The coupling degree of businesses is often too tight, and the public capabilities of the application process are not abstract enough, making it difficult to adapt and expand to similar processes of other businesses.

[0011] 2. Implementation can often only be done for different scenarios of different products, or targeted personalized development for different scenarios of the same product. This will result in the same product often having multiple projects and several sets of codes, high development and maintenance costs for personnel, and a waste of manpower and material resources.

[0012] 3. Due to various reasons, many products have tight project schedules and are unable to process, collect and report project logs. As a result, in the later stages of the project, the project operation and maintenance side cannot effectively conduct scientific data analysis on the project, and cannot well support business expansion and decision-making analysis. Summary of the invention

[0013] In view of the above problems, the present invention is proposed to provide a product feeding and delivery system that overcomes the above problems or at least partially solves the above problems.

[0014] According to one aspect of the present invention, a product delivery system is provided, which includes: a system configuration center, a system multi-terminal public capability plug-in set component, a public cross-terminal business component, a GraphQL-based client interface data request component, an OSS file server component, a login component, delivery channels, product types, differentiated processing of role business, a log tracking component and a high-concurrency deployment strategy based on a cloud platform.

[0015] Optionally, the system configuration center specifically includes:

[0016] When the system is built and running, common configuration parameters need to be reasonably and scientifically distinguished through different files and namespaces, and the modification is centralized in the configuration center component;

[0017] The system-level parameter configuration is responsible for the top-level basic configuration of the project, including the project version, global variables that the project depends on, and package build parameter settings; the business-level parameter configuration refers to the top-level parameters that are strongly related to the business;

[0018] Whether it is the system or business access to the system configuration, it is exposed and communicated to the outside world through the standard interface of ESM.

[0019] Optionally, the system multi-terminal public capability plug-in set components specifically include:

[0020] The system encapsulates some common capabilities of different terminals into plug-ins. The underlying layer combines the cross-terminal framework capabilities of uniapp and creates specific function folders in the / src / plugins directory of the project.

[0021] To adapt to different ports and business scenarios, with the help of uniapp's multi-terminal conditional compilation statements, through strategy mode, a set of code can be used to load code functions for different ports and scenarios to achieve cross-terminal adaptation capabilities.

[0022] Optionally, the public cross-end service component specifically includes:

[0023] The public business cross-end components are integrated based on different scenarios and terminals for some common public business modules.

[0024] The implementation method is that the front-end interface uses uniapp's multi-terminal conditional compilation capability to build scripts through differentiation, and a set of codes builds the front-end code for different terminals and scenarios;

[0025] In terms of background interface services, the apollo-server service of the node technology middle platform service is combined with the policy model component of the middle platform to initialize the business interface of the corresponding namespace on demand. With the on-demand acquisition feature of graphql, the schema data model based on graphql is used to pull data structures according to scenario and role needs, exposing different interface data to terminals and scenarios.

[0026] Optionally, the graphql-based client interface data request component specifically includes:

[0027] Apollo normalizes the data. When a nested structure is requested through a GraphQL query, the data is stored in the client cache in a normalized data structure.

[0028] Read data directly from the Apollo Client cache using an identifier.

[0029] Optionally, the OSS file server component specifically includes:

[0030] The front-end static resources are integrated to adapt to different terminals and business scenarios, and the image resources are personalized. The file resources are hosted on Alibaba Cloud using the OSS file storage function of Alibaba Cloud, and the image is scaled with the help of the characteristics of Alibaba Cloud file storage.

[0031] OSS supports adjusting the size of images stored in the bucket through image scaling parameters, and makes different compatibility adaptations for the same image resource based on different business scenarios and ports.

[0032] Optionally, the login component specifically includes:

[0033] The first stage is to transform login into a microservice and abstract login into a public SSO service. Each platform or port to be connected obtains a unique clientId through registration application on SSO to ensure the uniqueness of the application, and sends the background service address and the front-end page address of the successful callback to the SSO service. The address and clientId are associated with each other and intercepted uniformly through the gateway. After the gateway obtains the clientId, it is forwarded to different background services through nginx based on the registration information at the time of application, and the zero-time token in the gateway authentication is also brought;

[0034] The second stage is the actual login. The front-end obtains the token with authentication and logs in using the OTP mobile phone number. After success, the zero-time token will be replaced with the token of the target background service. The front-end will then put the token for logging into the background service in the head request header to complete the login authentication behavior.

[0035] Optionally, the differentiated processing of the application channel, product type, and role business specifically includes:

[0036] Different channels, products, and roles are differentiated and smoothed out in the front-end node middle-office service. The submission channels, product types, and roles are all implemented in the form of plug-ins. Each plug-in is understood as a fully functional microservice. The microservices are independent and unaffected by each other. If you want to use them, you must inject them into the service registration component in appollo-server before you can use them.

[0037] Optionally, the log tracking component specifically includes:

[0038] Use uni.getSystemInfoSync().platform and PLATFORM to determine the current system's operating environment and terminal, and call the uni-app log reporting SDK file provided by the Sensors log platform on the client's entry page;

[0039] Call sensors.init injection as needed, and then manually report the pv and uv data of business-critical scenarios on the page where you want to report data. System logs are automatically uploaded by default.

[0040] Optionally, the high-concurrency deployment strategy based on the cloud platform specifically includes:

[0041] The front-end and back-end services deployed on the cloud platform will be sniffed out through the service discovery of the gateway service;

[0042] Both front-end and back-end services are hosted in the form of microservices on Docker's microservice cluster. The link tracking, log center, and monitoring center components of the operation and maintenance monitoring center are used to monitor the operating status of the cloud platform mounted services in real time. With the help of Docker's service orchestration capabilities, the service traffic is dynamically adjusted to ensure stable input and output of core business services.

[0043] The present invention provides a product delivery system, which includes: a system configuration center, a system multi-terminal public capability plug-in set component, a public cross-terminal business component, a client interface data request component based on graphql, an OSS file server component, a login component, delivery channels, product types, differentiated processing of role business, a log point component, and a high-concurrency deployment strategy based on a cloud platform. The reusability of the components is greatly improved, and compared with the ordinary development model, the development efficiency has obvious advantages and improvements.

[0044] The above description is only an overview of the technical solution of the present invention. In order to more clearly understand the technical means of the present invention, it can be implemented according to the contents of the specification. In order to make the above and other purposes, features and advantages of the present invention more obvious and easy to understand, the specific implementation methods of the present invention are listed below. BRIEF DESCRIPTION OF THE DRAWINGS

[0045] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other accompanying drawings can be obtained based on these accompanying drawings without paying creative work.

[0046] Figure 1 A block diagram of a product delivery system provided by an embodiment of the present invention;

[0047] Figure 2 A functional diagram of a system configuration center provided by an embodiment of the present invention;

[0048] Figure 3 A system multi-terminal public capability plug-in set component provided by an embodiment of the present invention;

[0049] Figure 4 A schematic diagram of a login component provided in an embodiment of the present invention;

[0050] Figure 5 A schematic diagram of the mvvm file organization structure provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0051] The exemplary embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. Although the exemplary embodiments of the present disclosure are shown in the accompanying drawings, it should be understood that the present disclosure can be implemented in various forms and should not be limited by the embodiments set forth herein. On the contrary, these embodiments are provided to enable a more thorough understanding of the present disclosure and to fully convey the scope of the present disclosure to those skilled in the art.

[0052] The terms "comprises" and "having" and any variations thereof in the description embodiments, claims and drawings of the present invention are intended to cover non-exclusive inclusions, for example, including a series of steps or units.

[0053] The technical solution of the present invention is further described in detail below in conjunction with the accompanying drawings and embodiments.

[0054] like Figure 1 As shown, the present invention provides a product delivery system, using a system based on

[0055] uniapp+Vue+Apollo-Server+Apollo-Client+graphql+node+docker+nginx related technologies implement the entire front-end overall architecture, including: system configuration center components, public cross-end business components, public cross-end plug-in set components, login components, log tracking components, oss static file storage components, and multi-end back-end API interface adapter service components.

[0056] 1. System configuration center functions, such as Figure 2 As shown, including:

[0057] When the system is built and running, some common configuration parameters (including business level and system level) are required to be reasonably and scientifically distinguished through different files and namespaces, and are centrally processed and modified in the configuration center component to facilitate future expansion and maintenance. The current module design is as follows:

[0058] The system-level parameter configuration is mainly responsible for the top-level basic configuration of the project, such as the project version, global variables that the project depends on, and package build parameter settings; the business-level parameter configuration refers to the top-level parameters that are strongly related to the business, such as the public configuration parameters for business product launches. Whether the system or the business accesses the system configuration, it is exposed and communicated to the outside world through the standard interface of esm.

[0059] 2. System multi-terminal public capability plug-in set components, such as Figure 3 As shown, including:

[0060] It is a plug-in that encapsulates some common capabilities of different terminals. The underlying layer combines the cross-terminal framework capabilities of uniapp and creates specific function folders in the / src / plugins directory of the project.

[0061] For example, / src / plugins / ocr / index, the orc folder mainly implements the OCR function, and the index file is the main entry point for the function. In order to adapt to different ports and business scenarios, with the help of uniapp's multi-terminal conditional compilation statements, it starts with #ifdef or #ifndef plus %PLATFORM% and ends with #endif. Through the strategy mode, a set of codes is used to load the code functions of different ports and scenarios to achieve cross-terminal adaptation capabilities.

[0062] 3. Public cross-end business components, including:

[0063] Public business cross-end components are mainly aimed at some common public business modules, based on different scenarios and terminal abstract integration, to improve component reuse rate, reduce development costs, and improve development efficiency. The implementation method is that the front-end interface uses uniapp's multi-terminal conditional compilation capabilities, and through differentiated build scripts, a set of codes builds front-end codes for different terminals and scenarios; in terms of back-end interface services, combined with the apollo-server service of the node technology middle platform service, through the middle platform's policy model component, the business interface of the corresponding namespace is initialized on demand, and with the on-demand acquisition feature of graphql, the schema data model based on graphql is used to pull the desired data structure according to different scenarios and role needs, and expose different interface data for different terminals and scenarios.

[0064] 4. GraphQL-based client interface data request component - apollo-client, including:

[0065] In order to enable the client to quickly use graphql to request backend data, the open source component of vue-apollo is used. The apollo-client component is used well on the vue side. The instance of apollo-client is mounted on the instance of vue, and the query and mutation methods of graphql are accessed through this.$apollo, which is convenient for the client to request data. Of course, Apollo will normalize your data. When a nested structure of data is requested through a GraphQL query, the data will be stored in the client cache in a normalized data structure. Therefore, reading data directly from the Apollo client cache through an identifier improves the performance of interface requests and saves valuable network traffic resources.

[0066] 5. OSS file server components, including:

[0067] For the integration of static resources on the front end, to adapt to different terminals and business scenarios, and to personalize the adaptation of image resources, we use the OSS file storage function of Alibaba Cloud to host file resources on Alibaba Cloud. With the characteristics of Alibaba Cloud file storage, when you need to speed up loading time, save storage space, reduce bandwidth costs, or present images at a suitable size, you need to scale images. OSS supports adjusting the size of images stored in the bucket through image scaling parameters. Based on different business scenarios and ports, different compatible adaptations can be made for the same image resource, and there is no need to organize different resources for different scenarios and ports to adapt to complex scenarios.

[0068] 6. Login components, such as Figure 4 As shown, including:

[0069] The login component is mainly responsible for the adaptation and integration of user logins in different business scenarios and ports. Because it needs to be compatible with various platforms and multiple application scenarios, the login component unpacks the login into two stages: the first stage is to transform the login into a microservice and abstract the login into a public SSO service. Each platform or port to be connected obtains a unique clientId through the registration application on SSO to ensure the uniqueness of the application, and sends the background service address and the front-end page address of the callback of the successful call to the SSO service. The address and the clientId are associated with each other and are uniformly intercepted by the gateway. After the gateway side obtains the clientId, it will be forwarded to different background services through nginx based on the registration information at the time of application, and will also bring the zero-time token in the gateway authentication; the second stage is the actual login. The front-end obtains the token with authentication and performs OTP mobile phone number login. After success, the zero-time token will be replaced with the token of the target background service. The front-end will subsequently put the token of the login background service in the head request header to complete the login authentication behavior. It provides a unified way to log in to each business product line. The subsequent processing of different businesses is done through a unified maintenance and management location, which enables rapid access and processing for different businesses, effectively improving development efficiency.

[0070] 7. Differentiated processing of business such as application channels, product types, and roles, including:

[0071] Different channels, products, and roles are smoothed out and processed in the front-end node middle-end service. The application channels, product types, roles, etc. are all implemented in the form of plug-ins. Each plug-in is understood as a fully functional microservice. These microservices are independent and do not affect each other. If you want to use them, you must inject them into the service registration component in appollo-server before you can use them. Then the policy model component instantiates the services (different products, roles, channels) of the corresponding policy scenarios through the policy identifiers defined by the front-end and back-end of the interface. The instantiated services will enter the namespace of the corresponding products according to different policies, and then access the corresponding interfaces in combination with roles and channels to return the required data. The plug-in set model also provides a good expansion and continuous adaptation integration interface for future needs for multiple business attributes. All plug-ins are progressive enhancements to the main service and can be fully hot-swapped, minimizing the impact of branch business functions (or attributes) on the main service (i.e., atomic-level decoupling of business interfaces).

[0072] 8. Log tracking components, including:

[0073] This component mainly handles system-level functions and network anomalies, as well as the function of reporting buried data of business functions. This component determines the current system's operating environment and terminal through uni.getSystemInfoSync().platform and PLATFORM, and calls the log reporting SDK file of uni-app provided by the Sensors log platform on the client's entry page. Call sensors.init injection as needed, and then manually report pv, uv and other data of key business scenarios on the page where you want to report data. System logs are automatically uploaded by default. This provides good technical support for project maintenance, operation analysis, performance attribution, etc. for later personnel.

[0074] 9. High-concurrency deployment strategy based on cloud platform (docker), including:

[0075] The service will sniff out the front-end and back-end services deployed on the cloud platform (docker) through the service discovery of the gateway service (gateway->f5->nginx->load balancing...). Of course, the front-end and back-end services will be hosted on the docker microservice cluster in the form of microservices. The link tracking, log center, monitoring center and other components of the operation and maintenance monitoring center will be used to monitor the operation status of the cloud platform mounted services in real time. With the help of the service orchestration capabilities of docker, the service traffic can be dynamically adjusted to achieve stable input and output of core business services.

[0076] 10. Public business components based on the MVVM model, including:

[0077] Public business components are planned and abstracted based on the MVVM model, decoupling data, presentation, and business logic to ensure high availability, light coupling, and hot swapping under the premise of complete single functions. The organizational structure of each business component is as follows: Figure 5 As shown:

[0078] A: Contains a components folder (the aggregated business module components extracted from the page and associated with this business module)

[0079] B: A config.js file (used to process some public variables related to the business unit defined by the front end in some components, which are generally hard-coded data);

[0080] C: A controllers.js file (used to handle some data interaction logic of this business unit class, data changes, additions, deletions, modifications, and other logical operations are all handled here);

[0081] D: a data.js file (generally handles some metadata processing, basically some initialization variables, and interface request logic);

[0082] E: An index.vue file (the data related to the front-end framework is hung at the entrance, and the files in ABCD are hung on the corresponding nodes).

[0083] Beneficial effects: 1. Such file division can effectively divide the functions of business components. Each file has its own corresponding functions and the division of responsibilities is clear.

[0084] 2. As far as this component unit is concerned, after the granularity of the component is refined, each file is like a small building block, which can be fully implemented "where needed" (that is, what we call hot plugging). The components can be freely combined in a more flexible way, and the functional modules can be decoupled internally. The reusability of the components is greatly improved. Compared with the ordinary development model, the development efficiency has obvious advantages and improvements.

[0085] 3. Such file structure processing is easily decoupled from the UI framework. B, C, and D are the soul of the component. The interactive processing of business data can be completely separated. No matter you are react, vue, or angular, after the framework is changed, you only need to rewrite part of the UI interface. The cost of migration is very small, which fully realizes the idea of ​​data-driven UI.

[0086] 4. Low maintenance cost. Centralized logical processing of data facilitates future maintenance. Semantic API interface enables you to see the functions of business components at a glance. It is easy for others to understand and maintain, and the future business learning cost is low.

[0087] The above specific implementation methods further illustrate the objectives, technical solutions and beneficial effects of the present invention in detail. It should be understood that the above are only specific implementation methods of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the scope of protection of the present invention.

Claims

1. A product delivery system, characterized in that: The delivery system includes: a system configuration center, a system multi-terminal public capability plug-in set component, a public cross-terminal business component, a graphql-based client interface data request component, an oss file server component, a login component, an entry channel, a product type, differentiated processing of role business, a log tracking component, and a high-concurrency deployment strategy based on a cloud platform.

2. A product delivery system according to claim 1, characterized in that: The system configuration center specifically includes: When the system is built and running, common configuration parameters need to be reasonably and scientifically distinguished through different files and namespaces, and the modification is centralized in the configuration center component; The system-level parameter configuration is responsible for the top-level basic configuration of the project, including the project version, global variables that the project depends on, and package build parameter settings; Service-level parameter configuration refers to top-level parameters that are strongly related to the business; Whether it is the system or business access to the system configuration, it is exposed and communicated to the outside world through the standard interface of ESM.

3. A product delivery system according to claim 1, characterized in that: The system multi-terminal public capability plug-in set components specifically include: The system encapsulates some common capabilities of different terminals into plug-ins. The underlying layer combines the cross-terminal framework capabilities of uniapp and creates specific function folders in the / src / plugins directory of the project. To adapt to different ports and business scenarios, with the help of uniapp's multi-terminal conditional compilation statements, through strategy mode, a set of code can be used to load code functions for different ports and scenarios to achieve cross-terminal adaptation capabilities.

4. A product delivery system according to claim 1, characterized in that: The public cross-end service components specifically include: The public business cross-end components are integrated based on different scenarios and terminals for some common public business modules. The implementation method is that the front-end interface uses uniapp's multi-terminal conditional compilation capability to build scripts through differentiation, and a set of codes builds the front-end codes for different terminals and scenarios; In terms of background interface services, the apollo-server service of the node technology middle platform service is combined with the policy model component of the middle platform to initialize the business interface of the corresponding namespace on demand. With the on-demand acquisition feature of graphql, the schema data model based on graphql is used to pull data structures according to scenario and role needs, exposing different interface data to terminals and scenarios.

5. A product delivery system according to claim 1, characterized in that: The graphql-based client interface data request component specifically includes: Apollo normalizes the data. When a nested structure is requested through a GraphQL query, the data is stored in the client cache in a normalized data structure. Read data directly from the Apollo Client cache using an identifier.

6. A product delivery system according to claim 1, characterized in that: The OSS file server components specifically include: The front-end static resources are integrated to adapt to different terminals and business scenarios, and the image resources are personalized. The file resources are hosted on Alibaba Cloud using the OSS file storage function of Alibaba Cloud, and the image is scaled with the help of the characteristics of Alibaba Cloud file storage. OSS supports adjusting the size of images stored in the bucket through image scaling parameters, and makes different compatibility adaptations for the same image resource based on different business scenarios and ports.

7. A product delivery system according to claim 1, characterized in that: The login component specifically includes: The first stage is to transform login into a microservice and abstract login into a public SSO service. Each platform or port to be connected obtains a unique clientId through registration application on SSO to ensure the uniqueness of the application, and sends the background service address and the front-end page address of the successful callback to the SSO service. The address and clientId are associated with each other and intercepted uniformly through the gateway. After the gateway obtains the clientId, it is forwarded to different background services through nginx based on the registration information at the time of application, and the zero-time token in the gateway authentication is also brought; The second stage is the actual login. The front-end obtains the token with authentication and logs in using the OTP mobile phone number. After success, the zero-time token will be replaced with the token of the target background service. The front-end will then put the token for logging into the background service in the head request header to complete the login authentication behavior.

8. A product delivery system according to claim 1, characterized in that: The differentiated processing of the application channel, product type, and role business specifically includes: Different channels, products, and roles are differentiated and smoothed out in the front-end node middle-office service. The submission channels, product types, and roles are all implemented in the form of plug-ins. Each plug-in is understood as a fully functional microservice. The microservices are independent and unaffected by each other. If you want to use them, you must inject them into the service registration component in appollo-server before you can use them.

9. A product delivery system according to claim 1, characterized in that: The log tracking component specifically includes: Use uni.getSystemInfoSync().platform and PLATFORM to determine the current system's operating environment and terminal, and call the uni-app log reporting SDK file provided by the Sensors log platform on the client's entry page; Call sensors.init injection as needed, and then manually report the pv and uv data of business-critical scenarios on the page where you want to report data. System logs are automatically uploaded by default.

10. A product delivery system according to claim 1, characterized in that: The high-concurrency deployment strategy based on the cloud platform specifically includes: The front-end and back-end services deployed on the cloud platform will be sniffed out through the service discovery of the gateway service; Both front-end and back-end services are hosted in the form of microservices on Docker's microservice cluster. The link tracking, log center, and monitoring center components of the operation and maintenance monitoring center are used to monitor the operating status of the cloud platform mounted services in real time. With the help of Docker's service orchestration capabilities, the service traffic is dynamically adjusted to ensure stable input and output of core business services.

Images