Author: Idle fish technique — search for chess
Any business system needs rapid iterative delivery in the process of rapid growth, and Inspection Treasure business is no exception. This process inevitably introduces “bad smells” into the system code. Let’s take a look at a small optimization and some thoughts made recently by The inspection treasure.
What is “Inspection treasure”
Here is a brief introduction to the inspection service of idle fish. When shopping for expensive items such as digital products, trendy shoes and luxury bags, buyers may be worried about getting fake goods or items that don’t match the seller’s description. Sellers also hope to get a good price for their high-quality goods. In order to solve the problem of trust between buyers and sellers, Xianyu cooperates with professional organizations to provide authoritative inspection reports for all inspection treasure products. When the buyer orders the goods, the seller will deliver the goods to the inspection center, the inspection center issues the inspection report, the buyer can decide to buy or not to buy according to the report. Inspection treasure service was loved by users as soon as it was launched, and countless fans were attracted in a short time.
The girl said to me, “Let’s have a new category.
The inspection treasure has been online for more than half a year, and the demand iteration speed tends to be stable. Thanks to the excellent overall architecture design, I can Cover the back-end development by myself at present. However, there are still some “pain points” in the process of requirements iteration. For example, I hope that when the operation students keep coming to me to add new categories, I can solve the problem more quickly and easily. At present, the first batch of products supported by Inspection Treasure online include: mobile phone, tablet, notebook, fashionable shoes, luxury bags, luxury watches, luxury accessories, luxury clothing. The follow-up inspection treasure service will cover more categories, so that everyone can sell and buy at ease.
Different categories have different inspection fee calculation strategies, different introduction page URLS, different service providers, different price ranges that can be upgraded (only products in the specified price segment can be upgraded inspection treasure service), different internal codes, etc. Most of this is managed through configuration, of course, but configuration is scattered across multiple systems, multiple keys, and some of it is hard-coded into the code. Configuration is distributed in multiple systems mainly because different configuration systems focus on different, such as some configuration systems for development students, some for operation students; Hard coding in Code is basically like some global constant Code that needs to be typed into dependent JAR packages. The problem of hard-coded configuration is that new online categories need to be released by the server side code, which is affected by holidays and network blocking. The release cycle is long and not flexible enough.
In fact, this is a common and easy to ignore scenario. The configuration associated with a link needs to be closed to an “atomic configuration” (referring to a minimum delivery unit). Excessive and scattered configuration items may bring many negative effects:
• Increased maintenance costs: The change process is cumbersome and multiple configurations need to be modified. • Error-prone: prone to mismatch, missing match and unaware of the situation; • Extended change time: Each configuration needs to be modified and approved. • Consistency problem: If multiple configurations on a link depend on time sequence, the delay delivered by the configuration system may cause consistency problems and require additional means to ensure final consistency. However, this problem does not exist in atomic configurations.
In order to optimize this problem, and to support the rapid launch of new categories, Inspection Treasure has just made a special optimization: normalized transformation of configuration. The goal is to release new categories online free, at the same time unified configuration according to the category of a closed.
Simple, simple way to add a class
Firstly, the two main links are sorted out:
• Product upgrade link • Order fulfillment link
The link involves multiple applications, and the configuration types are diverse: String, Boolean, Map, and Integer. The Existing Mach Cloud delivery platform meets the requirements of this configuration center. Mach provides independent configuration definitions and configuration instance capabilities. The configuration definition uses JSON Schema to restrict the configuration content. Configuration instances can create multiple instances of different delivery periods, priorities, and environments.
Here I use a simplified example to illustrate the link. For example, I tease out the three configurations for each category:
, inspection treasure service description page URL: string type, should be charged by the inspection fee: numeric types, classification of the mesh can upgrade the inspection service treasure: string list type (I explain this, are used to configure multiple classification, such as basketball shoes, sandals, canvas shoes and so on all can open inspection bao chao footwear orders inspection service)
Under Mach I created a new configuration called “Checkbox configuration set” and first defined JSON Schema:
Then create a configuration instance and set the validity period and priority. In the end, Mach filled in the three configuration details. Mach generated the corresponding GUI fill in page based on the data type of the configuration item. For example, string is a text input field. Array is a list of text boxes with + buttons; The number type is a text input box with numeric validation.
Here is an example not to post page screenshots, with text:
•introductionPageUrl: www.taobao.com/yanhuobao/i…: 39•cateIdUnderScene: [123, 234, 345]
OK, now we can pull the configuration information through the Mach service interface. We can get the JSON string of the configuration instance from the interface and parse it through FastJSON.
Of course, the structure we define for the configuration may not be exactly the same as the actual data structure. We will parse the above configuration into a configuration DO object containing the following three variables:
The QPS for online services are very high, and these configurations do not require up-to-date values in real time, so we do a local cache, and of course saving the parsed ConfigDO object is the best option.
Fireworks are easy to cold, less wheel
There are a lot of Mach configurations referenced in an application, and each configuration resolves to a different DO data structure, but caching itself for every use is a recipe for repeated development and waste of resources. So we’ve introduced a generic configuration cache pool in passing.
The cache pool uses Guava’s LoadingCache. By abstracting a ConfigValueParser, each configuration user can implement its corresponding parsing logic.
Implement the parse logic in parseConfig and return the parsed YhbConfigDO object as mentioned above.
When used, it can be obtained directly:
YhbConfigDO yhbConfigDO = configMachReader.get(CONFIG_MACH_ID);
conclusion
In this paper, through a recent optimization of configuration normalization by an inspector, we introduce the possible problems caused by the associated configuration dispersion in the product link and the optimization scheme. I hope I can help you.
References
[1] www.taobao.com/yanhuobao/i… : www.taobao.com/yanhuobao/i…