Mechanism of SPI
The framework defines interfaces. Different users have different requirements and therefore need different implementations. SPI is a service discovery mechanism built into the JDK that completely decouples interfaces from implementations. We only declare interfaces; the implementation class is selected in the configuration. You define an interface and place a text file with the same name as the interface in the meta-INF /services directory. The contents of the file are the implementation classes of the interface, separated by newlines.
Dubbo does not use the JDK’s own SPI, but implements it by itself. The reason is that Java SPI iterates through the SPI configuration file and instantiates all implementation classes when looking for extension implementation classes, which is a waste of resources. So Dubbo implemented an SPI on its own, gave each implementation class a name, went to the file by name to find the fully qualified name of the corresponding implementation class and loaded the instantiation, loading it on demand.
Dubbo uses the Javassist dynamic proxy, Javassist, which is simple, fast and easy to generate bytecode.
What is dubbo?
Interface oriented remote method invocation, load balancing, intelligent fault tolerance, is essentially an RPC framework (dubbo+ ZooKeeper + load Balancing… Dubbo = Remote procedure call (dynamic proxy + network procedure) + Provider, consumer
The invocation process starts from Proxy, which holds an Invoker object. After invoking invoke, it is necessary to obtain the Invoker list of all callable remote services from Directory through Cluster. If certain routing rules are configured, For example, if an interface can only call a node, filter the Invoker list again. The rest of the Invoker load balancing through LoadBalance to select a load balancing. And then through Filter to do some statistics, and then through the Client to do data transmission, such as using Netty to transmit.
The reason why invoker is encapsulated is to mask the details of the invocation and expose an executable so that the caller can simply use it and initiate invoke calls to it. It may be a local implementation, a remote implementation, or a cluster implementation.
A method calling an interface will invoke the previously generated proxy class, and then select an Invoker from the routing filtering and load balancing mechanism in the cluster to initiate a remote call. At this time, the request and the request ID will be recorded and wait for the response of the server. The server accepts the request and finds the map that was exposed by its arguments, gets the corresponding EXPORTER, and eventually invokes the real implementation class. The result is assembled and returned with the ID of the previous request. After receiving the response, the consumer will find the previously recorded request through the ID, and then plug the response into the corresponding Future after finding the request, wake up the waiting thread, and finally the consumer gets the response and the process is finished.
Dubbo architecture design
Load Balancing Policy
Random, polling, least active, consistent hash
Retry mechanism
Failure automatic switchover (retry other servers), fast failure (failure immediately reported error), ignore failure, parallel scheduling, broadcast call
Service fusing
Dubbo itself has no circuit breaker mechanism, and is generally combined with the Hystrix implementation to resolve service avalanches.
Load balancing scheme
1. Centralized structure based on reverse proxy (HARDWARE F5, software Nigix)
Pain points: Centralized nodes are easy to become system bottlenecks, with low EFFICIENCY of HTTP transmission and operation and maintenance (troublesome configuration and deployment)
2. Embed your app’s internal decentralized architecture
Decentralized rack, client branch chain server, dynamic service registration and discovery, RPC efficiently complete network transmission
3. Service Mech architecture based on independent agent process
Agents are deployed independently on one host with multiple consumer common agents on one host (sidecar mode, service grid)
The agent
1. Gateway
2. Forward proxy (VPN)
3. Direction Agent (NIGIX)
What is a springcloud
Springcloud is a kind of model, based on the concrete implementation of SpringCloud Netflix (restful), SpringCloud Alibaba is actually a one-stop Internet micro-service architecture, designed to meet the three indicators (high availability, high performance, high concurrency). Either horizontal scaling or vertical scaling is implemented.
CAP
C: consistency A: Availability (high availability + high performance) P: partition fault-tolerant (failover)
C+P = financial system
A+P = Internet system
At the same time, the microservice architecture also needs to solve four major problems, namely: how to distribute client requests, how to communicate between microservices, how to govern services, and how to deal with service failure? (Retry, flow limiting (filter), fusing (timeout), service degradation (local cache)
Spring Cloud AlibbA related components
1. Registry (NACOS)
Discovery mode on the Client Discovery mode on the ZooKeeper server Eruka Server Discovery mode NacOS Integrates with the Ribbon by defaultCopy the code
The name service is similar to docker. The service is no longer accessed by IP address, but can be accessed by service name ID
The provider:
Consumer:
(1) Write a configuration class to inject restTemplate (display HTTP)
(2) controller
Using final means that you can create only once, which is thread-safe
(3) Use FEign for HTTP requests
(4) Load balancing test
Nacos comes with load balancing (polling, weighted polling, least connections, hash IP)
2. Configuration Center (nacOS Config)
(1) Dynamically obtain configuration parameters
(2) Multi-environment configuration
3. Communication Protocol (DuBBO)
Internal RPC and external REST
Why abandon ZooKeeper? Zk is a CP system with strong consistency, while NACOS is an AP, which is suitable for the registry
ZooKeeper does not support cross-room routing. Unlike Eureka, ZooKeeper has the concept of zone, giving priority to local routing. 2. When routing in this machine room, when there is a problem in this machine room, you can route to another machine room 3. 4. ZooKeeper When there are too many nodes, if service nodes change, you need to notify the machine at the same time, which causes "stampede effect" and causes the network adapter to fill up instantly and is easy to be notified repeatedlyCopy the code
Dubbo serialization starts hessian2 by default, and now kryo is popular, specifically for the Java language
Externalized configuration of Dubbo (exactly the same as before)
4. Distributed Transaction Solution (SEATA)
5. Log Collection and Analysis (ELK)
6. Circuit breaker mechanism
(1) Create fallback class
Specify Sentinal in configuration file, then @Componet inject (component)
(2) Add fallback to service
(3) Check on the control panel
7. Message Queue (rocketMQ)
Database subtable (remote live) = “Snowflake algorithm + ShardingSphere
Database distributed middleware support is required, and Sharding Sphere is recommended.