Configuration Center Internet architecture system in a very important piece, but why is there distribution center , is not necessary to have a beginning configuration center , it really solve any problem , this is a problem to be discussed today.
With the increasingly complex Internet services, users and traffic volume increases, " the service of layered " architecture evolution is the only way.
As shown above, the application calls the service site, upstream service calls the underlying service dependencies can become very complicated.
For the same service:
(1) upstream of which tend to have a plurality of call;
(2) In order to ensure high availability, it is often serve several nodes of the cluster;
As shown above, the service user-service center the user has three nodes, ip1 / ip2 / ip3 upstream service, any node when the machine does not affect the availability of services.
So the question is :
How caller maintain downstream services cluster configuration?
When the service node cluster decrease, the caller whether there is perception?
Early: "Configuration possession" architecture
"Configuration possession" is the primary stage arranged upstream downstream call, each upstream has a unique private profiles, each record being called the downstream node configuration information.
As Figure:
(1) The user has a user-service center ip1 / ip2 / ip3 three nodes;
(2) service1 call center users, it has a unique profile s1.conf, which cluster is configured with us ip1 / ip2 / ip3;
(3) service2 also called user-centered, empathy have a configuration file s2.conf, recorded us cluster is ip1 / ip2 / ip3;
(4) web2 also called user-centered, empathy w2.conf, the cluster is configured with us ip1 / ip2 / ip3;
Voice-over: is not very familiar with? Most of the company, so all the early play.
"Configuring the possession of" What are the disadvantages architecture is it?
Look at a change in capacity demands:
(1) detects the operation and maintenance node ip1 decrease drive performance, future research To inform ip1 offline node;
(2) Since May 8 to do big promotion operational activities, future traffic will surge in R & D to prepare two additional nodes ip4 and ip5;
At this point how to do it?
Head of the center requires the user to notify all upstream callers, modify the "possession" of the configuration, and restart the upstream connection to the new cluster up. After no traffic on ip1, inform the operation and maintenance node offline ip1 to complete the expansion volume reduction procedure.
What's wrong with this approach it?
When the high business complexity, higher number of R & D, service dependencies, the more complex, not so simple.
One problem : the caller pain, changes in volume are you modify the configuration and reboot Why the hell was I? This is a typical "reverse dependency" architecture, by arranging the downstream coupling, unreasonable.
Second problem : the service side pain, ta do not know how many upstream to call his own, often only be located upstream of the following ways:
-
The group shouted
-
Mail inquiry
-
Find ip by connecting, via ip ask operation and maintenance, to find the person responsible for the machine, and then the corresponding call service through the machine to find the person in charge
Voice-over: Is it deja vu?
Either way, are likely to miss, leading to ip1 has been difficult to flow off the assembly line, the flow ip4 / ip5 difficult even migrated. How to optimize it?
Mid-term: "Global" architecture
Upgrading infrastructure is not in one step, the first to use the lowest cost to solve the problem a "modify the configuration reset" above.
"Global" architecture: for universal service , the establishment of a global profile, eliminate configuration possession:
(1) operation and maintenance level norm, the new global configuration file, for example /opt/global.conf;
Narrator: If you configure more, attention to good vertically split configuration.
(2) For the service side, if a universal service, the cluster configuration information in global.conf years;
(3) for the caller, the caller is prohibited possession configuration, the configuration must be read from the downstream global.conf in general;
Global Configuration what good is it?
(1) If the downstream volume changes, only need to modify a configuration global.conf, without the need to modify the respective upstream;
(2) at the time the caller reboot automatically migrate to the cluster after expansion will come up;
(3) modify the cost is very small, reads the configuration file directory it was different;
Global Configuration What inadequate?
If the caller has not restarted, there is no way to migrate to the new cluster traffic go up.
There is no automatic traffic migration towards achieving it?
The answer is yes, you only need to introduce two components is not complicated , it will be able to achieve the caller's automatic migration flows:
(1) file monitoring component FileMonitor
Role is to monitor changes in the file, starting a timer, regularly monitor ModifyTime md5 file or can be easily achieved, when the file changes, the implementation of the callback.
(2) dynamic connection pooling assembly DynamicConnectionPool
"Pool connected component" is a sub-assembly in the RPC-client, used to maintain the connection between the plurality of RPC-server nodes. The so-called "dynamic connection pool" refers to the connection pool can dynamically increase and decrease.
Voice-over: with lock to exclusive, very easy to implement.
After the introduction of two components:
(1) Once the global profile changes, file monitoring callback assembly embodiment;
(2) If a dynamic connection pool configuration components found reduced the number of nodes connected to a corresponding dynamic destruction, if the increased number of nodes on a dynamic connection is established, automatically the downstream node of a compatibilizer and volume reduction;
Final version: "Configuration Center" architecture
"Global" architecture is a fast landing, solve the "modify the configuration reset" problem solution, but it is still not resolved, the service provider "do not know how many upstream calls himself" the problem.
If you do not know how much upstream to call his own:
"According to the caller limiting"
"Draw the global architecture dependency graph"
And other such requirements would be difficult to achieve, how do?
"Configuration Center" architecture can perfect solution.
Contrast "Global Configuration" and "Configuration Center" organization chart, you will find is configured by a static file upgraded to dynamic service :
(1) the entire configuration of the service center subsystem zk, conf-center, DB configuration store, conf-web composed arranged background;
(2) all downstream service configuration, the background provided by the configuration center;
(3) upstream of all necessary to pull configuration, the need to configure the central register, the downstream pull service configuration information (ip1 / ip2 / ip3);
When the service needs to downstream expansion volume reduction:
(4) conf-web configuration setting the background, add ip4 / ip5, reducing IP1;
(5) conf-center services will be pushed to change the configuration already registered concerns related to the configuration of the caller;
(6) combined with dynamic connection pool assembly, to complete the automatic expansion and compression volume;
"Configuration Center" architecture what good is it?
(1) the caller does not need to restart;
(2) from the serving center arranged upstream clearly know dependencies, thereby limiting embodiment according to the caller;
(3) it is easy to obtain from the global configuration center architecture dependency;
A pain point, while addressing the pain point two.
"Configuration Center" architecture has what it insufficient?
As a result, system complexity is relatively high;
Secondly, the configuration of the high reliability requirements of the center, a global hanging hanging.
to sum up
What is actually going to solve the pain points?
Pain upstream : downstream expansion, change the configuration of the upstream restart;
Downstream pain : do not know who rely on their own;
In short, difficult to implement service management.
Exactly how to solve the pain points?
First, the "Configuration possession" architecture;
Second, the "Global Profiles" architecture;
Third, the "Configuration Center" architecture;
Know, I know why.
