CN112817624A

CN112817624A - Real Native-based gray scale heat deployment system

Info

Publication number: CN112817624A
Application number: CN202110119988.3A
Authority: CN
Inventors: 赵存; 高宇健; 欧平均
Original assignee: Guangzhou Yike Mingyi Information Technology Co ltd
Current assignee: Hangzhou Yike Information Technology Co ltd
Priority date: 2021-01-28
Filing date: 2021-01-28
Publication date: 2021-05-18
Anticipated expiration: 2041-01-28
Also published as: CN112817624B

Abstract

The invention discloses a gray scale heat deployment system based on a React Native, which comprises a gitlabrunner module, a web end module, a server end module and a client end module; the invention provides a real native application-based gray scale hot deployment system which realizes automatic release, gray scale control and incremental issuing.

Description

Real Native-based gray scale heat deployment system

Technical Field

The invention relates to the field of hot deployment of software, in particular to a gray scale hot deployment system based on a real Native.

Background

Powerful marketing middleboxes need to be constructed in large-scale Saas software to support flexible and changeable scenes needed by merchants in online and offline integrated marketing. The software allows the merchant to establish custom rules aiming at different scenes and make different marketing preferential strategies. The system has many problems, such as difficulty in performing gray scale hot deployment to perform system upgrade management, difficulty in realizing distributed processing in transaction processing, lack of system construction in a powerful expression mode, extremely high requirements of marketing systems on printing statistics, difficulty in realizing rapid mobile terminal printing at present, and the like. Among them, how to perform grayscale thermal deployment to perform upgrade management of the system becomes one of important issues.

The fact Native is a cross-platform mobile development framework with a FaceBook open source, mobile applications can be written by using JavaScript, and after the mobile applications are put on the shelf in various application markets, the applications can be updated by issuing packaged JavaScript codes without re-submitting audit.

Currently, the existing hot deployment schemes mainly include:

1) and integrating the code push service of the open source of Microsoft. The scheme has the advantages that integration is simple, enterprises save development cost, but the defects are obvious, the code push service is abroad, the timeliness of hot deployment is low, the problem of update failure can occur, the packaging needs to be executed at a terminal, the packaging is tedious and easy to make mistakes, the packaged files are downloaded in full, and user flow is wasted.

2) And self-building service to store the packaged JavaScript file, and integrating SDK downloading by the client. The scheme has the advantages that the service is stable and controllable, the defects are obvious, the packed file is downloaded in full, the customer flow is wasted, and the terminal is also required to execute the packing command.

3) Based on Jenkins, self-constructed service and client integrated SDK downloading. This scheme utilizes the linear operating mechanism of Jenkins, disposes the packing script, can pack the issue under the Jenkins workstation clicks during the issue, and is convenient quick, but grey scale controllable is hardly accomplished to this kind of mode, has the problem of the extravagant customer flow of full download equally.

Disclosure of Invention

The invention overcomes the defects of the prior art, provides a read Native application-based thermal deployment scheme, and provides a read Native-based gray scale thermal deployment system which realizes automatic release, gray scale control and incremental issuing.

The technical scheme of the invention is as follows:

a gray scale heat deployment system based on reach Native comprises a gitlab runner module, a web end module, a server end module and a client end module;

the gitlab runner module is used for executing a packaging task, deploying running service based on the platform through the open source code hosting platform, wherein the running service runs through corresponding execution task files, and the task files realize the executed tasks, including dependent downloading and packaging; triggering the task file through an external interface corresponding to the open source code hosting platform;

the web end module is used for releasing gray levels, triggering the packing function of the gitlab runner module, uploading the package to the server after packing is finished, and completing one packing task; after receiving the packed file, the server stores the version and the gray mode of the release into a database to finish one-time application release;

the server module is used for storing and transmitting the packed execution task file; the server module comprises database tables and packages _ diff, wherein the packages table records the release of each version, and the information comprises package download links, version numbers, gray scale modes, whether diff packages exist or not and whether the diff packages can be downloaded or not; the packages _ diff table records file information after diff issued each time; after receiving the package uploaded by the gitlab runner module, the server checks whether the package table has the package with the same version, and if not, records the corresponding information released at this time to the table packages; if the packet exists, generating differentiated contents by using a text difference method, storing the differentiated contents into an old packet for replacement, and simultaneously recording the differentiated contents into a packages _ diff table to complete a differentiation process;

when the request of the client module arrives, the server module checks the packages table according to the version number carried by the request, and if the corresponding version number does not exist, a no-update package is returned; if the corresponding version number exists, whether the gray scale condition is met or not is checked, if the gray scale condition is not met, no updating package is returned, if the gray scale condition is met, whether a difference package exists or not is checked, a complete package downloading link is issued and exists, and a downloading link return is obtained from a table packages _ diff;

when the gray scale release of a certain time is suspended from the web side module, the server side module marks whether the release record corresponding to the packages table can be downloaded or not as no, and at the moment, the client side module returns no update package when requesting to reach;

the client module requests the interface to check and update every time the client module is started, the server module returns a related result according to the interface parameters, and the client module receives the returned result; if no update package exists, ending the process; if the update package exists, downloading the package; after the downloading is finished, judging whether the packet is a difference packet or not, if not, storing the packet to the local, marking the packet as current _ packet, and marking the running packet as previous _ packet; if the difference packet is the current packet, combining the content of the difference packet to the existing packet by using a text difference method, storing the content of the difference packet to the local, marking the stored packet as current _ packet, and marking the running packet as previous _ packet;

and starting and acquiring the packet marked as current _ packet for running next time, if the current _ packet running for the first time is broken down, deleting the packet marked as current _ packet, and changing the packet marked as previous _ packet into current _ packet for running next time.

Further, the request of the client module includes version number, system version, network condition and region information.

Further, the grayscale condition is that the version of the android system is greater than 8, the grayscale condition is not satisfied when the version of the android system carrying the information requested is 7, and the grayscale condition is satisfied when the version of the android system is 9.

Further, the difference package is the downloaded package information carrying the information whether the difference package information is carried in the downloaded package information.

Furthermore, the text difference method has fewer processing steps, and the addition is carried out after deletion in the processing, and the deletion is more after the addition; wherein, the optimal selection is carried out by the shortest path search problem of the graph; specifically, the longest substrings with the same file head are removed; and for the tail part, the longest substring is obtained by taking the shorter character string as a basis, then the longest substring is removed, and the rest part of the file is subjected to diff packet processing.

Compared with the prior art, the invention has the advantages that:

according to the invention, an effective closed loop of React Native application thermal deployment is formed through a gitlab runner module, a web end module, a server end module and a client end module; and a hot deployment scheme based on reach Native application is provided, and automatic release, gray level control and incremental issuing are realized.

In the specific software gray level issuing process, because the packaged js code character strings are thermally deployed, most codes are the same in the two thermal deployments before and after, and only a small amount of codes are changed, an operation of pinching the head and removing the tail is firstly performed, and the longest substring with the same head is removed; for the tail part, the longest substring is solved by taking the shorter character string as the basis, then the longest substring is removed, and the rest is subjected to a diff packet process, so that the diff packet process can be accelerated.

Drawings

FIG. 1 is a schematic diagram of an automated packaging process for gray scale thermal deployment according to the present invention;

FIG. 2 is a schematic view of the gray scale hot deployment inspection updating process according to the present invention;

FIG. 3 is a schematic diagram illustrating an example of an optimal path for deploying grayscale heat according to the present invention;

FIG. 4 is a schematic diagram of an example of a gray scale thermal deployment shortest path selection according to the present invention;

FIG. 5 is a schematic diagram of hierarchical items within a marketing center of the present invention;

FIG. 6 is a schematic diagram of the hierarchy within the hierarchy item of the present invention;

FIG. 7 is a hierarchical view of the hierarchy of the present invention;

FIG. 8 is a schematic diagram of the parent-child relationship of the hierarchy of the present invention;

FIG. 9 is a flow chart of rule validation of the present invention;

FIG. 10 is a flow diagram of a distributed transaction process of the present invention;

FIG. 11 is a diagram of an example of a distributed transaction of the present invention.

Detailed Description

Reference will now be made in detail to the embodiments of the present invention, wherein like or similar reference numerals refer to like or similar elements or elements of similar function throughout. The embodiments described below with reference to the drawings are exemplary only, and are not intended as limitations on the present invention.

It will be understood by those skilled in the art that, unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. It will be further understood that terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of the prior art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein.

Reference numerals in the various embodiments are provided for steps of the description only and are not necessarily associated in a substantially sequential manner. Different steps in each embodiment can be combined in different sequences, so that the purpose of the invention is achieved.

The invention is further described with reference to the following figures and detailed description.

Example 1:

a gray scale heat deployment system based on real Native comprises a gitlab runner module, a web end module, a server end module and a client end module.

The gitlab runner module is used for executing a packaging task, deploying running service based on the platform through the open source code hosting platform, wherein the running service runs through corresponding execution task files, and the task files realize the executed tasks, including dependent downloading and packaging; and the task file is triggered through the corresponding external interface of the open source code hosting platform. Namely, gitlab is a free open source code hosting platform and can be deployed privately. runner is a kind of operating service based on gitlab, which executes tasks through the gitlab-ci.yml file in the project, which can write various execution tasks, such as npm package download corresponding dependency, package, etc. When runner is triggered, runner examines the [ gitlab-ci.yml file in the project, performing the relevant task. The runner trigger mode has various modes, such as monitoring code change of a certain branch, such as the trigger through a gitlab api, and generally triggering through the gitlab api.

The web end module is used for releasing gray levels, triggering the packing function of the gitlab runner module, uploading the package to the server after packing is finished, and completing one packing task; and after receiving the packed file, the server stores the version and the gray mode of the release into a database to finish one-time application release.

For example, there is a coupon function point, the function point code is in release/coupon branch, when the function point needs to be released, the release/coupon branch is selected on the web side, the release version is filled, the gray mode (in proportion: for example, 30%; in system version: for example, android 8, in network environment, etc.) is selected, and the release is clicked, at this time, the gitlab api https:// gitlab. example, com/api/v3/proj ects/1/pipeline is called. And triggering a configuration file, namely gitlab-ci.yml, in the gitlab runner inspection project, executing a packaging task, uploading the package to the server module after the packaging is finished, and finishing the packaging task once. And after receiving the packed file, the server module stores the version and the gray mode of the release into a database to finish one-time application release.

The server module is used for storing and issuing the packaged JavaScript for executing the task file; the server module comprises database tables and packages _ diff, wherein the packages table records the release of each version, and the information comprises package download links, version numbers, gray scale modes, whether diff packages exist or not, whether the diff packages can be downloaded or not and the like. The packages _ diff table records file information (if any) after diff issued each time, namely the differential file package. After receiving the package uploaded by the gitlab runner module, the server checks whether the package table has the package with the same version, and if not, records the corresponding information released at this time to the table packages; if the difference exists, generating differentiated content by using a text difference method, storing the differentiated content into an old package for replacement, and simultaneously recording the differentiated content into a packages _ diff table to complete a differentiation process.

When the request of the client module arrives (the request of the client module comprises information such as a version number, a system version, network conditions, regions and the like), the server module checks a packages table according to the version number carried by the request, and if the corresponding version number does not exist, a no-update package is returned; if the corresponding version number exists, whether a gray scale condition is met or not is checked (for example, the gray scale condition is that the gray scale condition is larger than 8, the gray scale condition is not met when the android system version carrying the request is 7, and the gray scale condition is met when the android system version is 9), no update package is returned when the gray scale condition is not met, whether a difference package exists or not is checked when the gray scale condition is met, a complete package download link is issued and exists, and the download link return is acquired from a table packages _ diff.

When the gray scale publishing from the web side module is suspended, the server side module marks whether the downloadable field of the publishing record corresponding to the packages table is negative, and at the moment, the client side module returns no update package when the request is reached.

The client module requests the interface to check and update every time the client module is started, the server module returns a related result according to the interface parameters, and the client module receives the returned result; if no update package exists, ending the process; if the update package exists, downloading the package; after the downloading is finished, judging whether the packet is a difference packet or not, if not, storing the packet to the local, marking the packet as current _ packet, and marking the running packet as previous _ packet; if the difference packet is the current packet, merging the content of the difference packet into the existing packet by using a text difference method, storing the content of the difference packet into the local, marking the stored packet as current _ packet, and marking the running packet as previous _ packet. The difference package is the downloaded package information which carries the unique identification information of whether the difference package is the downloaded package information.

In conclusion, each real Native product line (such as chain diaries, laugh shop diaries, poke micro shops and the like) can be accessed to the system, when a new function point or bug needs to be issued, the system can be operated on, and one-time hot deployment can be rapidly completed. When a new function point is released, the user feeds back bug, and the influence on a large number of users can be reduced by suspending the release of the function.

Specifically, the text difference method has fewer processing steps, and is more newly added after deleted in processing than newly added; wherein the optimal selection is made by a shortest path search problem of the graph. Namely, the longest substrings with the same heads of the files are removed; and for the tail part, the longest substring is obtained by taking the shorter character string as a basis, then the longest substring is removed, and the rest part of the file is subjected to diff packet processing.

The text difference method comprises three operations of delete, insert and equal, wherein delete represents deletion operation, insert represents insertion operation and equal represents the same retention. The processing is carried out according to the principle that the processing steps are less, and the addition is carried out after the deletion in the processing, and the deletion is more after the addition. Specifically, if the source text is src ═ abcaba and the target text is dst ═ CBABAC, there are several ways from the source text to the target text:

the first method is as follows: -A, -B, C, -A, B, + A, B, A, + C (-for delete, + for insert, no sign added for equal);

the second method comprises the following steps: -a, + C, B, -C, A, B, -B, A, + C;

the third method comprises the following steps: + C, -A, B, -C, A, B, -B, -A, + C;

the first available set is represented as:

steps [ "deleteA", "deleteB", "equalC", "deleteA", "equalbb", "insertA", "equilib", "insertC" ], completing the conversion in nine Steps.

The second way can represent a set as:

steps [ "deleteA", "insert c", "equalB", "deleteC", "equalA", "equalB", "deleteB", "equalA", "insert c" ], and the conversion is completed in nine Steps.

The third way can represent the set as:

steps [ "insert c", "deleteA", "equal b", "deleteC", "equal a", "equal b", "deleteB", "deleteA", "insert a", "insert c" ], and the conversion is completed in ten Steps.

Obviously, the mode is more intuitive than the mode II, namely, the new addition after deletion is better than the deletion after the new addition, and the conversion steps are minimum. Thus conforming to the text differencing method. Wherein, determining as in the first and third modes, finding the shortest transformation step is obviously a typical shortest path search problem, still in the above transformation example, the structure is as shown in fig. 3, where the horizontal axis is src content, the vertical axis is dst content, each path from the top left corner to the bottom right corner in the figure represents a diff step, delete to the right, insert to the bottom, and equal to the diagonal (the original content remains unchanged).

The selection path is as follows:

(0,0)->(1,0)

(1,0)->(2,0)->(3,1)

(3,1)->(3,2)->(4,3)->(5,4)

(5,4)->(6,4)->(7,5)

(7,5)->(7,6)

the diff step represented by the path is: -A, -B, C, + B, A, B, -B, A, + C.

The src is successfully converted to dst by using the above path, but the path is not necessarily the path with the least steps, so that the path needs to be found by using dynamic planning and Myers algorithm thought, which is as follows:

first, parameters d and k are defined, d representing the length of the path and k representing the value of the current coordinate x-y. And defining an optimal coordinate, wherein the optimal coordinate represents the coordinate with the maximum x value under the condition that the d and k values are fixed. The larger x is, the more right is indicated, and more priority deletion operations are performed.

Specifically, starting from the coordinate (0,0), where d is 0 and k is 0, then d is gradually increased, and the corresponding optimal coordinate at each value of k is calculated. Since the diagonal does not affect the path length either to the right (x +1) or down (y +1) per step, when d is 1, there are only two values of k, either 1 or-1.

When d is 1 and k is 1, the optimal coordinates are (1, 0).

When d is 1 and k is-1, the optimal coordinates are (0, 1).

Since k is either 1 or-1 when d is 1, which means that one step is taken on the basis of d being 1 when d is 2, k has only three possible values, namely-2, 0 and 2.

When d is 2 and k is-2, the optimal coordinates are (2, 4).

When d is 2 and k is 0, the optimal coordinates are (2, 2).

When d is 2 and k is 2, the optimal coordinate is (3, 1).

And so on until we find a d and k value, reach the final target coordinate (7, 6). Establishing a horizontal axis representing d, a vertical axis representing k, and an optimal coordinate in the middle as shown in fig. 4, it can be known that when d is 5 and k is 1, the target coordinate (7,6) is reached, so that the shortest intuitive path is (0,0) - > (1,0) - > (3,1) - > (5,4) - > (7,5) - > (7,6), and the corresponding diff packet is as follows: -A, -B, C, + B, A, B, -B, A, + C. As described above, when d is 5, the optimal coordinates corresponding to all k must be known first, and when d is 4, the answer must be known first, and when d is 3, the shortest path can be obtained by analogy.

In the specific software gray level issuing process, because the packed js code character strings are thermally deployed, the two thermal deployments are largely performed, most codes are the same, and only a small part of codes are changed, a head-pinching and tail-removing operation is performed firstly, and the longest substring with the same head is removed; for the tail part, the longest substring is solved by taking the shorter character string as the basis, then the longest substring is removed, and the rest is subjected to a diff packet process, so that the diff packet process can be accelerated.

The hot-deploy js code as above is as follows:

yr＝v.create({app:{marginHorizontal:"auto",width:500}}),br＝vr；Un. registerComponent("App",(function(){return br})),Un.runApplication ("App",{rootTag:document.getElementById("react-root")})}])；

and then the width is changed from the original 500 to 308 due to the change of the product requirement, and the changed js code is as follows:

yr＝v.create({app:{marginHorizontal:"auto",width:308}}),br＝vr；Un. registerComponent("App",(function(){return br})),Un.runApplication ("App",{rootTag:document.getElementById("react-root")})}])；

because there are many repeated character strings in the beginning and end, in order to speed up the operation, the beginning and end are equal, and the corresponding process is equal. Assume that the head transform is denoted as Step1, the middle unequal transform is denoted as Step2, and the tail equal partial transform is denoted as Step 3.

Step1 equal (0,48), where 0,48 represents that the two code segments are equal from the starting position to the position where the length of the character string is 48.

Step2？

Step3 equal (51,300) where 51,300 indicates that the two pieces of code are equal from position 51 to the end (assuming a string length of 300).

Then now we can find Step2, i.e. the minimum transformation Step from src-500 to dst-308, and the minimum Step obtained using the above described dynamic programming concept is described as: -5, +3, 0, -0, + 8. Note that Step2 ═ delete (49, '5'), insert (49, '3'), equal (50,50, '0'), delete (51, '0'), insert (51, '8') ]. The whole transformation step is as follows: step ═ q (0,48), delete (49, '5'), insert (49, '3'), eq (50,50, '0'), delete (51, '0'), insert (51, '8'), equal (51,300) ]. Wherein, the first parameter of delete and insert represents the character position corresponding to the operation character string, and the second parameter represents the character of operation. The equal first and second parameters represent the starting and ending positions of the operator sub-string, and the third parameter is a specific operator character (which may not be present). The step of recording the Package diff table file is the change step, the client does not need to download the complete hot deployment code each time, the diff Package file is downloaded, and the complete code can be obtained according to the diff Package file.

Example 2:

as shown in fig. 1 to 11, a new management system for marketing. The marketing system is constructed by a marketing condition module and an interest module, because activities and link entries are many, such as time-limited discount, holiday promotion, membership care and the like; but as long as the types and numbers of the hierarchy items involved are the same, the marketing rules can be considered to be of the same type. As exemplified in the marketing rules in fig. 1, each has two marketing rules of three hierarchical terms. Therefore, when the hierarchy item is applied to the marketing medium discount strategy, the method specifically comprises the following steps:

101) marketing scene analysis: analyzing a marketing condition module and a rights and interests module corresponding to the activities according to the corresponding activities and the link entries; the marketing condition module analyzes the applicable condition of the corresponding activity.

102) A condition building step: according to the application condition of the activity analyzed by the marketing condition module, confirming the quantity of the hierarchy items required by the activity, wherein the specific hierarchy items can be represented by beginning with hier keywords; and expressing the hierarchy in the hierarchy item by using the hierarchy, and realizing the calling of the activity marketing condition module by setting a corresponding interface.

The hierarchy (level) is provided with at least one hierarchy from high to low from the inside of the hierarchy item. For example, a commodity level item may be a "primary category", "secondary category", "commodity" level from high to low; the regional hierarchy items comprise 'city', 'county', 'village and town', and the like from high to low as required; the time dimension may be from high to low in "year", "month" and "day", or may be in "year", "month" and "week" layers, as shown in fig. 2.

Each layer comprises at least one corresponding member, the members are discrete and hierarchical, and when the number of the members is multiple, a full range of special members are also set and represent all the members of the layer. Lower members in the same hierarchy item are positioned in the range of upper members; whereas an upper member comprises a lower member. Members between different hierarchy items are independent of each other. For example, at the regional level:

[ hierArea ] [ Ningbo City ]

[ hierArea ] [ Hangzhou City ]

[ hierArea ] [ Hangzhou City ] [ West lake region ]

In particular, a special member represents all value ranges of the layer, called all values for short, for example [ hierArea ] [ hangzhou city ] [ all ] represents all counties in hangzhou.

103) And (4) right and interest confirmation step: the equity module gives corresponding discount equity or gives a proper gift package according to the activity condition set up by the marketing condition module in the step 102).

The data of the members of each hierarchy under the hierarchy item is stored in a relational table of the database, and the stored data structure type adopts a hierarchical relationship and/or a parent-child relationship. Taking the regional hierarchy as an example, the hierarchical relationship is shown in fig. 3, and each Level occupies one table field. The parent-child relationship is shown in fig. 8, the upper-lower Level relationship is expressed by fixing two fields code and pcode, and the parent-child relationship is a Level.

The corresponding interface comprises a hierarchy item name, a definition of a hierarchy, a top-level member, a father member of a certain member, a lower-level member list of a certain member and translation of a certain member, and the reading of the relationship between the members and the members is facilitated; the implementation level item model comprises a set of level and level interfaces and base classes, and when a new level item is identified and defined by the business layer, a new class can be rapidly implemented through secondary development. Specifically, the interface and base class of the hierarchy and hierarchy, which is defined as follows, takes java language as an example:

where the reference to Member is defined as follows:

wherein the level reference is defined as follows:

naturally, for two storage structure types of the hierarchy and the parent and the child, a corresponding toolkit can be packaged, so that the application layer can read the members and the relations from the table conveniently.

Step 102) the plurality of hierarchy items generate expressions representing different rules by concatenating the expressions. That is, for a marketing scenario, several hierarchical items are identified, each hierarchical item is assigned a membership value, and the membership values are combined together to form an expression. The hierarchical expression also defines a rule; expressions representing different rules may be generated by setting combinations of different member values.

For example, assume that a membership discount activity at a merchant involves the following three hierarchical items and their hierarchical definitions (the hierarchies are in order from high to low):

member (hierMember), there are two levels:

levelCustomer (Member level)

levelMember (Member individual)

The store (hierShop) has three levels:

levelArea (Large area)

levelCity (City)

levelShop

The commodity (hierSpu) has two levels:

levelBrand (trade brand)

levelSpu (commercial product)

According to the above hierarchy, there is the following set of rule definitions:

rule one, which indicates that diamond-level members can enjoy a discount when buying seven wolves and jagol brand clothing in a martial arts shop, the hierarchical expression is:

[ HierMember ], [ Diamond Member ], [ Hiershop ], [ Huadong region ], [ Hangzhou City ], [ Wulin shop ], { [ HierSpu ], [ seven wolf ], [ HierSpu ], [ Yagol ] }

Rule two: representing that the silver member can enjoy a discount when purchasing all brands of clothing in the martial store, the hierarchical expression is:

[ silver Member ], [ Hiershop ], [ Huadong region ], [ Hangzhou City ], [ Wulin shop ], [ HierSpu ], [ all brands ] }

The relational table of the database comprises an index module, and the index module comprises a rule metadata definition table and a rule definition table; the index module is established, so that the query is convenient and the efficiency is high.

And if the number of the hierarchy items corresponding to the corresponding marketing activities is not more than ten, storing each hierarchy item, and if the number of the hierarchy items is not more than ten, enabling the rest hierarchy items to be empty, namely enabling unused multi-definition hierarchy items to be empty.

The rule definition table is used for storing specific rules, and comprises key fields, weight fields and related fields; the weight field is used for determining which rule is used by taking the weight field as priority when two or more rules simultaneously meet the activity condition; the member data stored in each hierarchy item is single or multiple, and commas are used for separating multiple member data.

The rule retrieval module extracts corresponding members as parameters according to each hierarchy item of the activity condition, retrieves in a rule definition table according to the group of parameter members, and hits the rule if all hierarchy item members of a certain rule contain or are equal to the group of parameter members; after all matched rules are searched out, the business layer determines to select the rule with the highest weight according to the weight, or combines and uses all the rules, and finally carries out subsequent processing according to the preferential information defined in the interest module.

The rules defined by the hierarchical item expressions are exemplified as follows, when a client places an order in a store, the software application layer can know who the client is (such as Zhang III, the member level is silver), which store places the order (such as Wulin shop) and what commodity is purchased (such as JB 002) in the current context scene, and the member parameter group is assembled according to the context information, and the structure is as follows:

[ HierMember ] - [ silver Member ] - [ ZhangIII ], [ HierShop ] - [ Huadong district ] - [ Hangzhou City ] - [ Wulin shop ], [ HierSpu ] - [ Jiumu ] - [ Niumu ] - [ Menu ] in summer in 2020 J.J. JB002 type in summer ] }

Using this set of parameter members to search in the "rule definition table" above, it is found that "rule two" described above is satisfied. Because the relational database is adopted, the algorithm of rule retrieval can be realized by directly using SQL statements, and the core segments of SQL statements are as follows:

if a comma is used to separate a plurality of member values stored in the hiern _ value field, it is also possible to indicate that one of the member values is satisfied. Taking Mysql database as an example, the find _ in _ set function of the database may be used instead of the expression, such as:

a rule verification module is also included, as shown in fig. 9, in contrast to the rule retrieval module, the rule verification module verifies whether the rule is satisfied by comparing a set of parameter members given in advance with a specified rule of a hierarchy item.

The system adopts an MQ-based distributed transaction method for transaction realization, and comprises a transaction message service module and a transaction message client plug-in module.

The transaction message service module comprises a message receiving module, a commit/rollback message module and a message checking module;

the received message is a received message interface provided by the transaction message service module and is used for being called by a transaction initiating end of the transaction message service module; after the transaction initiating terminal calls the message receiving interface, the transaction message service module caches message data to the cache server;

the transaction message service provides a commit/rollback message interface for the commit/rollback message to be called by a transaction initiating terminal of the transaction message service module; after the transaction initiating terminal calls the submission message interface, the transaction message service takes out the message data from the cache server, sends the data to the MQ server, and deletes the message data from the cache server after the transmission is successful; after the transaction initiating terminal calls the rollback message interface, the transaction message service deletes the message data from the cache server;

message checking processing, after a transaction initiating terminal calls a message receiving interface of a transaction message service, if a commit/rollback message interface of the transaction message is not called accidentally, message data cannot be forwarded and deleted, and in order to avoid data inconsistency caused by the situation, the transaction message service starts a timing task and regularly checks messages which are not forwarded and deleted in time; checking whether the transaction message which is not processed overtime exists, calling back an interface of a transaction initiating terminal, confirming whether the local transaction of the initiating terminal is successfully completed or not, submitting the message when the local transaction is successful, and rolling back the message when the local transaction is failed;

and the transaction message client plug-in module is used for realizing that the transaction message client plug-in is embedded into the transaction initiating terminal and the transaction receiving terminal.

The transaction message client plug-in module intercepts spring local transaction operation at a transaction initiating end, and performs transaction message related processing before and after the spring local transaction submitting or rolling back operation;

before committing the spring local transaction: the transaction initiating terminal calls a transaction message service receiving message interface in an asynchronous mode to realize that a transaction message client-side plug-in checks whether the receiving message interface is successfully called before spring local transaction is submitted, and normally submits the transaction when the spring local transaction is successfully submitted; if the interface call of the received message fails, rolling back the local transaction;

after spring local transaction commits: calling a transaction message service submission message interface;

after rolling back the spring local transaction: invoking a transaction message service rollback message interface.

The transaction message client plug-in module plays a role in assisting the receiving end to check whether the message is processed at the transaction receiving end, so that the message is prevented from being processed repeatedly; if the message can not be repeatedly consumed, when the transaction message client plug-in receives the message, the transaction message ID is written in the local table, and whether the transaction message ID exists is checked to ensure that the message is consumed only once.

As shown in fig. 11, taking the member charging and point sending service as an example:

the business requirement is that each member charges 1 yuan and sends 1 point. The user enters the recharging subsystem, and the message is accurately transmitted through receiving the message, submitting/rolling back the message and checking and processing the message, and the message is confirmed for multiple times to ensure the accuracy of the message.

The deployment and subsequent upgrade management of the system adopt a gray scale hot deployment mode based on real Native, and the gray scale hot deployment mode comprises a gitlab runner module, a web end module, a server end module and a client end module.

For example, there is a coupon function point, the function point code is in release/coupon branch, when the function point needs to be released, the release/coupon branch is selected on the web side, the release version is filled, the gray mode is selected (in proportion: for example, 30%; in system version: for example, android 8, in network environment, etc.), and the release is clicked, at this time, the gitlab api https:// gitlab. example, com/api/v3/projects/1/pipeline is called. And triggering a configuration file, namely gitlab-ci.yml, in the gitlab runner inspection project, executing a packaging task, uploading the package to the server module after the packaging is finished, and finishing the packaging task once. And after receiving the packed file, the server module stores the version and the gray mode of the release into a database to finish one-time application release.

the first available set is represented as:

The second way can represent a set as:

The third way can represent the set as:

The selection path is as follows:

(0,0)->(1,0)

(1,0)->(2,0)->(3,1)

(3,1)->(3,2)->(4,3)->(5,4)

(5,4)->(6,4)->(7,5)

(7,5)->(7,6)

the diff step represented by the path is: -A, -B, C, + B, A, B, -B, A, + C.

When d is 1 and k is 1, the optimal coordinates are (1, 0).

When d is 1 and k is-1, the optimal coordinates are (0, 1).

When d is 2 and k is-2, the optimal coordinates are (2, 4).

When d is 2 and k is 0, the optimal coordinates are (2, 2).

When d is 2 and k is 2, the optimal coordinate is (3, 1).

The hot-deploy js code as above is as follows:

Step2？

Printing is taken as an essential function in the whole marketing, at present, the logic of analyzing data into printing instructions is realized at different terminals (iOS, Android and the like), the repeated work is caused, and the maintenance cost is very high, so that the system also integrates a visual editing method of a printing template for printing conveniently, particularly at a client use end, part of functions of the system are transplanted into a WeChat applet for facilitating the use and simplification of software, and the editing function of the visual template is realized by depending on the WeChat applet. Because the PC end has a complete printing implementation mode, and the mobile end has difficulty in realizing effective and rapid printing. The visual template editing function can also preset a large number of rich standard templates besides self-defining template editing. The technology of the visual editing function is realized by matching React Hooks with the assemblies of WeChat MovableArea and MovableView. The MovableArea and MovableView components provide basic moving capacity for materials, bidirectional binding of data is achieved through read useEffect Hook, views and data are bound, and a foundation is laid for subsequent actual printing. Whether bar code or plain text, support custom entry (static) and data reading (dynamic) ways, selectable as desired.

The template data can be stored at a printing center server after the template is edited, the front end only needs to transmit the template id and the corresponding goods data during subsequent printing, the printing center can perform pre-analysis on the template after receiving a request, and when a part needing to read the data is encountered, the goods data in the request can be read and filled to a corresponding position, and finally the goods data are analyzed into a printing instruction to be returned to the front end. After the front end receives the printing instruction, the instruction is directly transmitted to the printer for printing operation without any redundant action. The whole process is simple and rapid.

The terminal of the system is optimized by a network optimal line, when the terminal is started, a plurality of lines are firstly obtained from a service central point and cached in a local server to provide speed measurement service, all primary inlets are firstly detected, no line is selected, and then secondary is selected, wherein the primary difference of the secondary is bandwidth/stability/reliability. Static variables and guard times (4 seconds by 2 seconds to 8 seconds) were added at the end to prevent duplicate testing of the best line. The initiation of the line test adopts concurrent speed measurement, connection, reading and writing can be completed within 2 seconds, and the best line selection can be completed once in 4 seconds at worst. And when all speed measuring threads are finished and the optimal line is selected, the global variable can be updated at the fastest speed. Only after the foreground has the network without strength prompting, the optimal line detection is triggered, and the detection is asynchronous, so that the main service cannot be influenced. The method can be realized by a simple and conventional client selection algorithm without greatly increasing the burden of the existing Internet.

The foregoing is only a preferred embodiment of the present invention, and it should be noted that, for those skilled in the art, several modifications and decorations can be made without departing from the spirit of the present invention, and these modifications and decorations should also be regarded as being within the scope of the present invention.

Claims

1. The utility model provides a grey scale heat deployment system based on reach Native which characterized in that: the system comprises a gitlab runner module, a web end module, a server end module and a client end module;

2. The fact Native based grayscale thermal deployment system of claim 1, wherein: when the request of the client module includes version number, system version, network condition, and region information.

3. The fact Native based grayscale thermal deployment system of claim 1, wherein: the gray scale condition is that the version of the android system is larger than 8, the gray scale condition is not met when the version of the android system carrying the information is 7, and the gray scale condition is met when the version of the android system is 9.

4. The fact Native based grayscale thermal deployment system of claim 1, wherein: the difference package is the downloaded package information which carries the information whether the difference package is the difference package information or not.

5. The fact Native based grayscale thermal deployment system of claim 1, wherein: the text difference method has fewer processing steps, and the addition after deletion in the processing is more than the deletion after addition; wherein, the optimal selection is carried out by the shortest path search problem of the graph; specifically, the longest substrings with the same file head are removed; and for the tail part, the longest substring is obtained by taking the shorter character string as a basis, then the longest substring is removed, and the rest part of the file is subjected to diff packet processing.