Swoft microservice architecture diagram
As shown in the above figure, a mainstream micro-service architecture will be composed of a traffic proxy layer, a gateway, a registration center, and a service layer. When the service is complex, it will be split into two layers: the basic service layer and the aggregation service for clear responsibilities. The layer consists of several main parts.
The proxy layer is generally located at the entrance of the traffic and can be implemented based on LVS load balancing, f5 load balancer, GLB Director, Nginx/OpenResty and other middleware. Specific details can be found in the official documentation, and will not be repeated here.
Usually, some of the aggregated service interfaces in our system need to be exposed to the outside world, which inevitably encounters some general appeals such as: some interfaces need to be logged in before they can be called (authentication/authentication), some Some excuses need to limit the frequency of calls (current limit), and in some cases, multiple interfaces of the old and new versions should be used at the same time (A/B Test)... What should I do? You are sure to think smart. If you are in a single application, you can use the Facade mode as the facade of the entire system to uniformly schedule or filter all requests. This not only reduces the burden on external callers, but also To some extent, enhance the security of the system. There are many excellent general-purpose open source gateway implementations, such as Kong, Orang, and the relatively new Ingress Gateway.
The core of the entire distributed service governance is the registration center, which is mainly used to realize the automatic registration and discovery of each service instance. In fact, when service is started and there are not many services, several services can be directly called in the configuration of the service corresponding to the service, but when the service is gradually increased, the manual maintenance method will be extremely difficult. Maintenance and updates are not timely, we need to introduce the registration center. At present, there are many implementations of mainstream open source registration centers, such as: Consul, ETCD, Eureka, and even Zookeeper. Different registration centers have different CAP choices and business performance. Interested students can refer to this comparison document .
When we are still a single application, we can save commonly used configuration items in a local configuration file. But when our service instances run in hundreds of thousands of nodes, the correct complexity of manually maintaining these configurations becomes high. At this time we need to introduce a configuration center to uniformly manage the configuration of all services. There are many open source configuration centers, such as K8S ConfigMap, Ctrip open source Apollo, Spring Cloud Config and so on.