Writing in the front
Started service invocation between using the domain name, domain name is actually a good thing, it is convenient to use, but all call request must go DNS and load balancing, performance is relatively close, and in the middle parts turn into a single point of performance bottlenecks and potential risk, then everyone is found that it is better to direct the end-to-end call, Then you need something to connect the two ends of the call chain, and that’s the registry.
Image source analysis and comparison of major micro service registry
The registry provides registration discovery of services used to connect the Provider and Consumer endpoints of the invocation link. A registry to manage service scalability capacity, failover, traffic distribution, core functions such as itself also need high availability, properly handle cross-regional deployment case registry data consistency between nodes, so I tend to think the registry is a product of a systematic bias, the value of it depends on the scale and matching service system of governance, Although its idea came into being very early, but it is not easy to scale down, the small service scale itself does not depend on the registry obviously, and the means of implementation is not fixed. Large services put more demanding demands on the location and function of the registry.
CP 还是 AP
Whether to choose strong consistency or high availability, the current mainstream technology selection tends to the latter, but this does not mean that CP component does not exist, but AP component more fit the positioning of the Internet for the registry.
High availability of Internet systems is always at the top of the list, because the time a system is down is often directly linked to property damage. Service list in a short time for more than one or two nodes, the less one or two nodes, this flow for most service awareness is not obvious, only need to register center within a short window of time to achieve consistent state can, registry should not affect at run time in a normal call the connectivity between two endpoints.
Pass the ZK?
CP is represented by ZooKeeper, which is also a very popular component for registries today, thanks in part to Dubbo. In ZooKeeper, Dubbo uses two nodes in a tree structure to maintain the Provider and Comsumer of the service respectively. The list is registered under these two nodes. The health check of the service depends on the temporary node feature provided by ZooKeeper. In fact, it is bound to the life cycle of the session, but the problem of temporary nodes is that data is easy to lose. Once the faulty node in the cluster is restarted and the service list is lost, the service may be broken in a large area. PDD, an e-commerce upstart, once had this problem.
Photo credit: Dubbo
The most critical problem of CP is that it cannot support Dr In the machine room. For example, there is network isolation between the three machines room ABC and the other two machines room C, and the ZooKeeper node deployed in the machine room C cannot provide data writing, which means that the Provider deployed in the machine room C cannot be expanded or shrunk or restarted. It is best to keep the Provider intact during a failure. Otherwise, any operation of the Provider is risky and will directly affect the Comsumer deployed in equipment room C.
By the way, I think ZooKeeper is really nice, because it’s designed to be a distributed coordination service, not designed for registries, so you can’t evaluate it like a registry. Zookeeper basically has all the features you want, so you can use that as a Curator. Election is provided, ZAB is provided, TPS is a bit low (actually it’s ok) but still meets most service sizes.
Had been a struggle
Eureka — Netflix’s influencer component, represented in the AP registry. In retrospect, Eureka 1.x is a far-fetched implementation, because its architecture from the day it was born meant that problems would occur when the data scale grew. The overall scalability of the cluster was very low, and each additional Eureka node meant an additional data flow between the whole point-to-point network. However, the data flow of the peer-to-peer mechanism can easily flood the NETWORK adapter, causing pressure on the server. According to public data, Eureka will have significant performance bottlenecks and even service unavailability at around 5,000 instances.
However, on the other hand, Eureka has a clear architecture, convenient operation and maintenance deployment, and Eureka is implemented as a registry recommended by SpringCloud and has a considerable number of domestic users. It can be seen that there is no problem with Eureka’s performance if the service scale is appropriate. As can be seen from ctrip’s shared information, Its internal registry is also similar to Eureka’s implementation, so there is no absolutely perfect architecture design, it is the most important to fit their own business needs.
In-depth interpretation of Eureka architecture for microservices registry by Ma Junwei
The Eureka server multi-node architecture is somewhat decentralized, intentionally maintaining the stateless nature of each node, but at the cost of each node holding the full amount of data, new data can be written to any node, and then broadcast from this node to other nodes to achieve consistency.
Data is not persisted and is only stored in memory, which provides better read and write performance and shorter response time. However, it cannot handle data bottlenecks. Data synchronization caused by large node expansion may cause the risk of overrunning network cards, which is similar to redis cluster. The client will report heartbeat periodically for 30 seconds, and the client cache service list is nothing to talk about. One interesting thing about Eureka is that its cluster nodes implement a self-protection mechanism to predict whether a cluster problem or a client problem. The implementation is simple but the idea is practical.
Eureka 2.0’s design document was written with the idea of a read-write split cluster, which was essentially made to improve cluster performance and capacity. Unfortunately, this is deprecated as 2.0 is now deprecated and will not be replaced with a full-service product for a while.
Image source network
Sofa-Registry = Future?
Although there is no Eureka 2.0, the implementation of similar ideas can be seen from ant open-source Sofa-Registry, which was derived from Ali’s ConfigServer. According to the public data, Ali is the first to implement the practice of reading and writing separation in the Registry in China.
Image source: ConfigServer Architecture, by Hao Tian Ku
The immediate benefit of this architecture is that it can support massive data. The session clusters in the first layer can be extended infinitely and communicate with each other completely. The session cluster maintains all the topological relationships required by the registry in memory, and the clients only connect to a part of the machines in the session cluster. If one session machine dies, the client will choose another one to reconnect. The data cluster in the back stores all source data by fragmentation, ensures high availability through primary and secondary copies between fragments, and then pushes the source data to the session cluster for storage for clients to read.
The disadvantages are also obvious. The manpower input and operation and maintenance costs of this architecture are definitely higher than those of Eureka.
Cross-geographical deployment
This is an almost inevitable problem for registries. High availability, machine room disaster recovery, and network latency will all require registries to be able to be deployed across geographies, which brings up another issue of data synchronization.
In this case, it is no longer possible to ensure data consistency between remote registries through client registration or replication of data flow of cluster nodes. Instead, a separate data synchronization component will be developed to realize data synchronization between registries through trans-regional dedicated lines. If the dedicated lines are disconnected, At this time, registries in each region can still independently serve the invocation of services in the region. When the dedicated line is restored, the data of the two regions will continue to be synchronized, merged and corrected, and finally achieve consistency. The nacOS-Sync component is an open source data synchronization service from the Nacos project.
Write in the last
The article has skipped over some of the concepts common to registries, such as layering of data models, local caching of service lists, the way health checks are done, push-pull trade-offs, etc., and I don’t think it makes much sense to go into the details.
A lot of times, I think the most important thing to understand about a component is to understand its architectural evolution. This is a valuable treasure of experience, and you can grasp and learn where and why the architecture is evolving each time.