Shulou(Shulou.com)06/01 Report--

This article mainly introduces "the detailed introduction of the Go language micro-service development framework Go chassis". In the daily operation, I believe many people have doubts about the detailed introduction of the GE language micro-service development framework Go chassis. The editor consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful to answer the doubts of "the detailed introduction of the Go language micro-service development framework Go chassis". Next, please follow the editor to study!

Architecture

Source: configuration source is a standard interface that can be accessed from different configuration sources by implementing a source, which defines which resource the configuration comes from, the configuration can come from the configuration center configcenter, from the local file, from the environment variable, or from the startup command line. Source is responsible for caching configuration items to local memory. The user can choose to load any source implementation.

Config center source: the configuration center source is different from other source. It contains an client abstraction that can interface with different ecosystems. Currently, it docks with Ctrip's open source configuration center Apollo.

Config manager: responsible for integrating and managing the configuration of all source. Each source can define priority. When obtaining the configuration through manager, if two different source have the same configuration, then the configuration with the highest priority will be taken.

Event Dispatcher: users can listen for configuration changes through Archaius API. When new, updated or deleted configurations are added, updated or deleted within the source, the listener will be notified.

Source priority: the priority is Config center,CLI,ENV,file from high to low. When there are the same configuration items, only the configuration with high priority takes effect. In a distributed system, a remote configuration center should have the highest priority, while when running an independent process locally, the general thinking is that command-line parameters take precedence over environment variables and over the contents of local files. With such a mechanism, users no longer need to write code to deal with the configuration item validity logic.

Config Factory: API encapsulating event and config manager

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

Get configuration

There are two different ways to get a configuration:

1. Call the Get method of archaius API

two。 Register listener

The trigger of the event is determined by the soruce developer, and the behavior of each source will be different:

The command line and environment variables do not generate any events, and the configuration items are fixed when archaius is run, and can only be obtained using the Get method. The file source will pull the contents of the local file once after startup and convert it to a configuration item (you can customize the conversion algorithm to determine the configuration item shape), and then continue to listen for changes in the local file. When any changes occur, the local configuration will be refreshed and notified to the listener. So both methods are supported. Config center source behavior is different from files, after startup, it will periodically pull the configuration of the configuration center, and compare the different configuration items each time, and trigger different types of events.

Configuration item form

Suppose the program has a configuration file called a.yaml, which contains the following

Registry: enabled: true interval: 30s copy code

There are two ways to consider how to deal with this raw data.

First, split the configuration items into java properties-style configurations:

Registry.refresh: trueregistry.interval: 30s

Go archaius opens the file handler interface to allow you to decide how to process the contents of a file as a configuration item

Then in the remote configuration center, the management of key value should follow the behavior of file handler. When you want to change the registry.refresh, you have to change the configuration item and value in the configuration center.

Similar to switch configuration items, this java properties is managed well, triggering an event when a configuration item changes.

But there is one type of configuration item that is not suitable for this management, and this is the second way, such as the route management profile in go chassis:

Usually, a wide range of configuration items need to be changed, so if you also use a sharding method to manage in the configuration center, it will cause a large number of events to trigger during the go archaius runtime, and users will greatly discount the user experience, looking everywhere for scattered configuration items and changing them one by one. The correct behavior is to use the file name as the key in the configuration center and the file contents as the value. When users need to change, you can find the corresponding file name. If you send it at once after modification, it will only trigger an event to complete the routing change.

Developers should judge how to deal with configuration items according to the actual scenario. You can also implement handler to determine the configuration item shape.

Configure run-time hot loading

If you can change the configuration at any time through a unified configuration center or local files (it is not recommended to log in to the machine to change the files in the distributed environment, but it is recommended to use files to test the hot loading logic of the program in the local debug), the next problem to be solved is that the configuration takes effect at run time.

The trick here is to use read-write locks in the go language. I'll use the routing configuration in go chassis to illustrate.

When go chassis runs, there will always be large concurrent data access to the router config cache, using a read lock in lock, each time a read lock is used to access the cache, and after use, unlock the read lock.

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

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

At this point, the study on the "detailed introduction to the Go language micro-service development framework Go chassis" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.