Go Language Distributed system configuration Management practice — Go Archaius

Source: A configuration Source is a standard interface that allows you to access different configuration sources by implementing a Source that defines which resource the configuration comes from. The configuration can come from the configCenter, from local files, from environment variables, or from the startup command line. Source is responsible for caching configuration items into local memory. The user can choose to load any source implementation.

The Config Center Source is different from other sources in that it contains a client abstraction that can connect to different ecosystems. Currently, it connects to Ctrip’s open source configuration center Apollo.

Config Manager: is responsible for integrating and managing the configuration of all sources. Each source can define its priority. When obtaining the configuration from Manager, if two different sources have the same configuration, the configuration with the highest priority will be taken.

Event Dispatcher: Users can monitor configuration changes through Archaius API. When configuration items inside source are added, updated or deleted, the listener will be notified.

Source priority: The priorities are Config Center, CLI, ENV, and file in descending order. When the same configuration items are configured, only the ones with higher priorities take effect. In a distributed system, remote configuration centers are expected to have maximum priority, whereas when running a standalone process locally, the common thinking is that command line arguments take precedence over environment variables and over local file content. With such a mechanism in place, users no longer need to write code to handle configuration item validation logic.

Config Factory: Encapsulates the API for event and Config Manager

Archaius API: Encapsulates the underlying implementation and provides a friendly API for developers to use

Access to the configuration

There are two different ways to get a configuration:

1. Call the Archaius API Get method

2. Register listeners

Event triggering is determined by the soruce developer, and each source behaves differently:

The command line and environment variables do not generate any events. When Archaius runs, the configuration items are already fixed and can only be retrieved using the Get method. After startup, the file source will pull the local file content and convert it into configuration items (the conversion algorithm can be customized to determine the configuration items), and then continuously monitor the change of the local file. When there is any change, the local configuration will be refreshed and notified to the listener. Therefore, both methods are supported. The Config Center source behaves differently from a file. After startup, it periodically pulls the configuration of the configuration center, compares each configuration item, and triggers different types of events.

Configuration Item Configuration

Suppose your program has a configuration file called A.yaml that reads as follows

registry:
  enabled: true
  interval: 30sCopy the code

There are two ways to think about how to treat raw data, right

First, split the configuration items into Java Properties style configurations:

registry.refresh: true

registry.interval: 30s

Go Archaius opens up the File Handler interface, allowing you to decide how to process the contents of a file as a configuration item

In the remote configuration center, the key value is managed according to the behavior of the File handler. When you want to change Registry. Refresh, you change the configuration item and value in the configuration center.

Similar to the configuration items of the switch class, this Java Properties management is fine, with an event triggered when a configuration item changes.

But there’s one category of configuration items that doesn’t work this way, and this is the second, like the route management profile for Go Chassis:

It is often necessary to change the configuration items on a large scale, so using a shred approach to manage in the configuration center will cause a large number of events to be triggered by the Go Archaius runtime, and the user experience will be greatly reduced, looking for scattered configuration items to change one by one. The correct behavior is to have the file name as the key in the configuration center and the file content as the value. If you need to change the route name, you only need to find the corresponding file name. After you change the file name, you can deliver the file name once. Only one event is triggered to complete the route change.

Developers should determine how to deal with configuration items based on actual scenarios. You can also implement your own handler to determine the configuration item shape

Configure runtime hot loading

Configuration can be changed at any time at run time through a unified configuration center or local file (not recommended in a distributed environment, but still recommended for local debug to test the program’s hot load logic), so the next problem to solve is the configuration at run time.

The trick here is to use read/write locks in the GO language. I use the go Chassis middle route configuration to illustrate

During the operation of go chassis, a large number of concurrent data will constantly access the router config cache. The read lock in a read/write lock is used for each access to the cache. After use, the read lock is unlocked.

To register a listener with archaius, you need to write the logic of the listener. Every time the event starts, it will build a structure data from the data in archaius, and then store the data in the local cache. First, use the write lock of lock to lock the router config, and after update, unlock the write lock.

With this mechanism, it is possible to hot-load configuration items at run time without restarting the service.