posts-go/posts/2022-10-26-reload-config.md

75 lines
1.7 KiB
Markdown
Raw Normal View History

2022-10-26 15:07:51 +00:00
# Reload config
This serves as design draft of reload config system
```plantuml
@startuml Reload config
skinparam defaultFontName Iosevka Term SS08
participant admin
participant other_service
participant config_service
participant storage
== Admin handle ==
admin -> config_service: set/update/delete config
config_service -> storage: set/update/delete config
== Other service handle ==
other_service -> other_service: init service
activate other_service
other_service -> storage: make connection
loop
other_service -> storage: listen on config change
other_service -> other_service: save config to memory
end
deactivate other_service
other_service -> other_service: do business
activate other_service
other_service -> other_service: get config
other_service -> other_service: do other business
deactivate other_service
@enduml
```
2023-08-05 18:56:25 +00:00
Config storage can be any key value storage or database like etcd, Consul,
mySQL, ...
2022-10-26 15:07:51 +00:00
If storage is key value storage, maybe there is API to listen on config change.
2023-08-05 18:56:25 +00:00
Otherwise we should create a loop to get all config from storage for some
interval, for example each 5 minute.
2022-10-26 15:07:51 +00:00
2023-08-05 18:56:25 +00:00
Each `other_service` need to get config from its memory, not hit `storage`. So
there is some delay between upstream config (config in `storage`) and downstream
config (config in `other_service`), but maybe we can forgive that delay (???).
2022-10-26 15:07:51 +00:00
Pros:
- Config can be dynamic, service does not need to restart to apply new config.
2023-08-05 18:56:25 +00:00
- Each service only keep 1 connection to `storage` to listen to config change,
not hit `storage` for each request.
2022-10-26 15:07:51 +00:00
Cons:
- Each service has 1 more dependency, aka `storage`.
- Need to handle fallback config, incase `storage` failure.
- Delay between upstream/downstream config