By learning Apollo's architecture, it will take you in-depth understanding of the basic principles of microservice architecture
1. Introduction
Apollo [refer to appendix] is a production-level configuration center product developed and open sourced by Ctrip's framework department. It can centrally manage the configuration of applications in different environments and different clusters. After configuration changes, it can be pushed to the application side in real time. And with standardized permissions, process governance and other features, it is suitable for microservice configuration management scenarios.
Apollo is currently relatively hot in the domestic developer community, with more than 5k stars on Github, and many domestic Internet companies have landing cases. It can be said that Apollo is currently the product of Number1 in the product field of the configuration center, and its maturity and enterprise-level features are far Far stronger than the Spring Cloud Config product in the Spring Cloud system.
Apollo adopts a distributed microservice architecture. Its architecture is a bit complicated. Although Song Shun, the author of Apollo, has given an architecture diagram, if there is no certain foundation of distributed microservice architecture, ordinary developers and even architects are also very It's hard to understand at once. In order to let everyone better understand Apollo's architecture design, I spent a little time reanalyzing Apollo's architecture in my own way. Only when you fully understand Apollo's architecture can you better deploy and use Apollo in production practice. In addition, by learning Apollo's architecture, you can deeply understand some of the basic principles of microservice architecture.
Two, architecture and modules
The following figure is the architecture diagram given by Song Shun, the author of Apollo:
If there is not enough basis for the distributed microservice architecture, and some framework products of Ctrip (such as Software Load Balancer (SLB) are not understood, then this architecture diagram is not easy to understand at first sight (in fact, the first time I read it) I didn't understand this structure.) Let's put it here first, and after I re-analyze this structure later, it will be easy for everyone to look back and look at this structure.
The following are seven modules of Apollo, four of which are core modules related to functions, and the other three are modules that assist in service discovery:
Four core modules and their main functions
| Module | The main function |
|---|---|
| ConfigService | Provide configuration acquisition interface Provide configuration push interface to serve Apollo client |
| AdminService | Provide configuration management interface Provide configuration modification release interface to serve the management interface Portal |
| Client | Get the configuration for the application, support real-time update to obtain the service list of ConfigService through MetaServer, use the client soft load SLB method to call ConfigService |
| Portal | The configuration management interface obtains the service list of AdminService through MetaServer, and calls AdminService by using the client soft load SLB method |
Three auxiliary service discovery modules
| Module | The main function |
|---|---|
| Eureka | Used for service discovery and registration of Config/AdminService registration instances and regular report heartbeat and ConfigService live together deployment |
| MetaServer | Portal accesses MetaServer to obtain the address list of AdminService through the domain name Client accesses MetaServer to obtain the address list of ConfigService through the domain name, which is equivalent to an Eureka Proxy logical role, which is deployed together with ConfigService |
| NginxLB | Cooperate with domain name system, assist Portal to access MetaServer to obtain AdminService address list and domain name system, assist Client to access MetaServer to obtain ConfigService address list and domain name system to assist users to access Portal for configuration management |
Three, architecture analysis
Apollo Architecture V1
If you do not consider the problem of service discovery in the distributed microservice architecture, the simplest architecture of Apollo is shown in the following figure:
Key points:
- ConfigService is an independent microservice that serves Client for configuration acquisition.
- Client and ConfigService maintain a long connection. Through a push & pull mode, real-time configuration updates are achieved while ensuring that configuration updates are not lost.
- AdminService is an independent microservice that serves Portal for configuration management. Portal performs configuration management and release by calling AdminService.
- ConfigService and AdminService share ConfigDB, which stores the configuration information of the project in a certain environment. ConfigService/AdminService/ConfigDB must be deployed in each environment (DEV/FAT/UAT/PRO).
- Protal has an independent PortalDB that stores metadata information about user permissions, projects, and configurations. Protal only needs to deploy one copy, and it can manage multiple environments.
Apollo Architecture V2
In order to ensure high availability, both ConfigService and AdminService are deployed in a stateless manner in a cluster. At this time, there is a service discovery problem: How does the Client find the ConfigService? How does Portal find AdminService? In order to solve this problem, Apollo introduced the Eureka service registry component in its architecture to realize service registration and discovery between microservices. The updated architecture is shown in the following figure:
Key points:
- After Config/AdminService is started, it will register to the Eureka service registry and send keep-alive heartbeats regularly.
- Eureka is deployed in a cluster and uses a distributed consistency protocol to ensure that the state of each instance is eventually consistent.
Apollo Architecture V3
We know that Eureka is a Java client with its own service discovery. If Apollo only supports Java client access and does not support client access in other languages, then Client and Portal only need to introduce Eureka’s Java client to implement services. Discovery function. After the target service is discovered, it can be routed to the target service instance through the client soft load (SLB, such as Ribbon). This is a classic microservice architecture, based on Eureka to achieve service registration discovery + client Ribbon to achieve soft routing, as shown in the following figure:
Apollo architecture V4
In Ctrip, there are not only Java, but also many legacy .Net applications. The author of Apollo also considered that after open source to the community, many customer applications are non-Java. But Eureka (including Ribbon soft load) natively only supports Java clients. If you want to develop Eureka/Ribbon clients for multiple languages, the workload is very large and uncontrollable. To this end, the author of Apollo introduced the role of MetaServer, which is actually an Eureka Proxy, exposing Eureka's service discovery interface in the form of a simpler and clearer HTTP interface, so that Client/Protal can be queried through a simple HTTPClient Address list of Config/AdminService. After obtaining the address list of the service instance, a simple client-side soft load (Client SLB) strategy routing is used to locate the target instance and initiate a call.
Now there is another question. MetaServer itself is also statelessly deployed in a cluster, so how can Client/Protal discover MetaServer? A traditional approach is to use hardware or software load balancers. For example, Ctrip uses the expanded NginxLB (also known as Software Load Balancer). The operation and maintenance configures a domain name for the MetaServer cluster and points to the NginxLB cluster. Perform load balancing and traffic forwarding. Client/Portal indirectly access the MetaServer cluster through the domain name + NginxLB.
The architecture after the introduction of MetaServer and NginxLB is shown in the following figure:
Apollo Architecture V5
The V4 version is a relatively complete overview of the Apollo architecture. There is still the last link left: Portal is also deployed in a stateless cluster mode. How do users discover and access Portal? The answer is also a simple traditional approach. Users access the Portal cluster indirectly through domain name + NginxLB.
Therefore, the V5 version includes the final Apollo architecture overview of the user side, as shown in the following figure:
Four, conclusion
- After my analysis in the third part, I believe that everyone will have a clearer understanding of Apollo's microservice architecture. As a question, everyone will look back at the architecture diagram given by Song Shun in the second part. Can you understand it now? ? How does it correspond to my architecture? As a reminder, Song Shun’s perspective is a top-down perspective, while mine is a side perspective.
- ConfgService/AdminService/Client/Portal are Apollo's four core microservice modules, which cooperate with each other to complete the configuration center business function. Eureka/MetaServer/NginxLB is a module that assists in service discovery between microservices.
- Apollo adopts a microservice architecture design. The architecture and deployment are somewhat complicated, but each service has a single responsibility and is easy to expand. In addition, Apollo only needs one set of Portal to centrally manage the configurations in multiple environments (DEV/FAT/UAT/PRO), which is a highlight of its architecture.
- Service discovery is the foundation of the microservice architecture. In Apollo's microservice architecture, both Eureka registry-style service discovery and NginxLB centralized proxy-style service discovery are used.
Appendix:
https://github.com/ctripcorp/apollo