Swoft Micro Service Architecture diagram
As shown in the figure above, a mainstream Microservice architecture consists of a traffic agent layer, a gateway, a registry, a service layer (when the business is complex, and in order for the responsibility to be clear, it is usually broken down into two tiers of the basic service layer and the aggregation service), a configuration center, a data layer, and so on.
The agent layer is generally located at the portal of traffic, can be based on LVS load balancing, f5 load balancer, GLB Director, Nginx/OpenResty and other middleware to achieve. Details can be seen in the official documentation, which will not be repeated here.
In general, some of the aggregation service interfaces in our systems need to be exposed to the outside world, which inevitably encounters some universal claims such as: some interfaces need to be logged in before they can be invoked (authentication/authentication), and some excuses need to limit the frequency of calls (streams), There are also cases where multiple interfaces of the old and new versions are to be used at the same time (A/b Test) ... What do we do at this moment? Smart, you must have thought, if in the case of monomer applications, you can use the Facade model as the facade of the entire system, all requests for unified scheduling or filtering, which can not only reduce the burden of external callers, but also to a certain extent to enhance the security of the system. There are many excellent universal open source gateway implementations, such as: Kong, Orang, as well as the current relatively new Ingress Gateway and so on.
The core of the whole distributed service governance when registering the center, which is mainly used to realize the automatic registration and discovery of each service instance. In fact, at the beginning of the service, service is not many times, several services can be written in the configuration of the corresponding service configuration directly called, but when the service gradually increased this way of manual maintenance will lead to extremely difficult to maintain and update is not timely, this time we need to introduce the registration center. At present, there are many implementations of the mainstream open source registration center, such as: Consul, ETCD, Eureka, and even Zookeeper, and so on, different registration centers in CAP trade-offs and business performance are also interested students can refer to this comparison document .
When we are still a monolithic application, we can save the commonly used configuration items in the local configuration file. But when our service power runs in hundreds of nodes, the correct complexity of manually maintaining these configurations becomes high. This is when we need to introduce a configuration center to uniformly manage the configuration of all services. There are many open source configuration center implementations, such as K8S's ConfigMap, Ctrip's Open source Apollo, Spring Cloud Config, and more.