Original link: https://www.kawabangga.com/posts/4545
When I was working at Ant Financial, I saw and used a lot of poorly designed systems, including the worst thing called an AntX, and I still shudder when I think about it now.
The specific implementation has not been remembered clearly, because I have never really mastered it. Just remember that this is actually a dynamic configuration system. To use it, you need to write 3 template files in your application, one of which will be rendered first, and then use these variables to render another template; the rendering process uses The obtained variables are configured on a web interface and do not exist in the code; some of the actual render results are injected into actual variables when the program is compiled, and it seems that some of them are injected at runtime.
Complex template files, each template still uses a different syntax, needs to be configured in the web, the configuration distinguishes between compile-time and runtime variables, and distinguishes between different environment variables. This sounds like a disaster, and I believe that there are not many people in the entire company who can explain the process of generating the final configuration clearly. In the end, everyone also admitted that the system could no longer be maintained. There are many variables in the program that are not actually used, but the program runs well, and no one has the motivation to sort it out. In the end, it was decided to write a new configuration system to replace it.
Config is a user-oriented thing, and should be simple, easy to understand, and avoid ambiguity like UI. There are countless accidents caused by configuration errors. In fact, many of them are caused by the generation gap in the understanding of configuration authors and users. This blog will talk about configuration practices that I think are good.
There should be one– and preferably only one –obvious way to do it.
There are many kinds of software input, command line parameters, environment variables, stdin, configuration files, etc. can be used as configuration items to control the behavior of the software. Many software provide multiple configuration methods for the same configuration, which increases the complexity.
For example, this BUG of Etcd: grpc gateway defaults to false when –config -file is used, and true when –config-file is not used . Even –config-file=/dev/null becomes false . It took a long time to investigate.
I think for the software on the server side, in fact, most of the configuration needs to be configured from the configuration file. I tested my ideas in the lobbyboy project . As a server-side software, lobbyboy can only input all configurations from the configuration file. There are no other command line parameters except -c to change the Path of the configuration file.
The command line of Nginx does not have many parameters, and most of the configuration is controlled through configuration files.
Of course, for the client-side software, it is more complicated. Many parameters support the configuration of environment variables, args, and xxxrc files at the same time, which will be more user-friendly. For example, the configuration file reading order of iredis is:
- Options from command line
-
$PWD/.iredisrc -
~/.iredisrc(this path can be changed withiredis --iredisrc $YOUR_PATH) -
/etc/iredisrc - default config in IRedis package.
The configuration of client software should preferably conform to the XDG Base Directory Specification .
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
To make the configuration simpler, you can consider the following issues when designing:
- Is this configuration necessary? Is the default value sufficient for the user in most scenarios?
- Is it possible for multiple configurations to be unambiguously articulated with one configuration?
- Think about it this way: When adding a new configuration, how can the configuration be explained in the least amount of language?
In UI design, every pixel is important, and every space must be saved. Adding too many unnecessary things will make the UI unintuitive. The configuration is also, the configuration is not an infinite file, the addition of the configuration will bring costs, not the cost of running the program, but the cost of people, which is more important than the performance of the operation.
When it comes to dynamic configuration, many times I wonder if this is a pseudo-requirement. Applications today are designed to be stateless and can be restarted at any time. So when I modify the configuration, can I change the configuration file and redeploy it? Of course, if there are thousands of instances, modification speed may become an issue.
When there is a dynamic configuration function, a misunderstanding is that developers will put all configurations that “feel like they may be modified in the future” into dynamic configuration. In fact, I think all configurations can be used as hardcode first. If you find that you need to modify more, then move them to configuration files or dynamic configuration.
Json is definitely a bad configuration language. The nice thing about it is that there is no ambiguity between machine reading and parsing, unlike Yaml.
But it is too unfriendly to human editors:
- json is just easy to parse but too hard to edit and very error prone. For example, [] is not allowed to add
,at the end, otherwise a format error will occur. In this way, every time you edit, adding a line will appear two lines of diff. - json in json is even more nightmare. I found a rule that where there is json, there will be json in json (meaning that there are some values in json, which are strings, and strings are just json added with escape). There may even be json in json in json.
- For example, many lists are designed as
items:[{key: name, valye:jack}], and a list already has two levels of nesting. - Json is not friendly enough for line editors, such as sed and awk.
- Comments are not supported, making it impossible to give a self-explain example in the document.
If the implementation is hard to explain, it’s a bad idea.
If the implementation is easy to explain, it may be a good idea.
Many configuration names are tied to the implementation, which may be a mindset. To come up with a good name for a configuration, try to forget the implementation details and think about how the configuration can be explained plainly, unambiguously, and easily remembered.
A typical example is the configuration try not to use double negation. For example disallow_publish , it is better to use allow_publish .
There is a configuration in uWSGI called harakiri , which means “suicide” in Japanese, which means that if a process does not complete the processing of the request within the specified time, it will exit. Relatively appropriate.
I think the configuration of the save trigger time of Redis is well designed:
################################ SNAPSHOTTING ################# ############### # # Save the DB on disk: # # save <seconds> <changes> # # Will save the DB if both the given number of seconds and the given # number of write operations against the DB occurred. # # In the example below the behaviour will be to save: # after 900 sec (15 min) if at least 1 key changed # after 300 sec (5 min) if at least 10 keys changed # after 60 sec if at least 10000 keys changed # # Note: you can disable saving completely by commenting out all "save" lines. # # It is also possible to remove all the previously configured save # points by adding a save directive with a single empty string argument # like in the following example: # # save "" save 900 1 save 300 10 save 60 10000
Sadly, there seems to be no pattern to follow for this design.
Postscript: Actually, this article has been in the draft box for a long time. I just have some ideas, but I don’t know how to describe it more appropriately. Configuration, like naming variables, is a difficult topic to talk about. This article just expresses some messy ideas in scribbles. After reading the article 4 suggestions for designing server software configuration , I decided to send out the long-sleeping article in the draft box. Readers are welcome to communicate.
The post Designing Configuration Items Like Designing UI first appeared on Kawabanga! .
This article is reprinted from: https://www.kawabangga.com/posts/4545
This site is for inclusion only, and the copyright belongs to the original author.