The classic Sidecar Mesh deployment architecture has many advantages, such as smooth upgrade, multi-language, less business intrusion, etc., but it also brings some additional problems, such as:
-
The performance loss caused by Proxy will become especially obvious in network calls with complex topologies
-
Architectural complexity brought about by traffic interception
-
Sidecar Lifecycle Management
-
The deployment environment is limited, and not all environments meet the sidecar traffic interception conditions
There must be more flexible options In response to the problem of the Sidecar Mesh model, the Dubbo community has made the idea and thinking of directly connecting Dubbo to the control plane since a long time ago, and took the lead in proposing the concept of Proxyless Mesh in the domestic open source community. Of course, in terms of the concept of Proxyless, the most It was originally proposed by Google.
The Proxyless mode makes the microservices return to the deployment architecture of the 2.x era. As shown in the figure above, it is very similar to the Dubbo classic service governance mode we saw above, so this mode is not new. Dubbo has been like this from the very beginning. Design Patterns. However, compared with the Mesh architecture, Dubbo2 does not emphasize the unified control of the control plane, which is exactly what Service Mesh emphasizes, emphasizing the standardized control and governance of traffic, observability, certificates, etc., which is also an advanced place for the Mesh concept.
Directly implement xDS protocol analysis through Dubbo3 SDK of different language versions, realize direct communication between Dubbo and Control Plane, and then realize unified control of control face traffic control, service governance, observability, security, etc., and avoid the performance brought by Sidecar mode Attrition and deployment architecture complexity.
In the Dubbo3 Proxyless architecture mode, the Dubbo process will communicate directly with the control plane, and the Dubbo process will continue to maintain the direct communication mode.
-
Use minicube and docker to build an experimental environment
-
Use istioctl to view the content of the xds protocol
-
Combined with dubbo to implement the logic of bootstrap file.
-
Modify the netty channel to add supprt for istio-agent mode.
-
Validation the logic. More information can be found here[apache/dubbo#10567 (comment)].
This stage completes the content of configuration initialization. While not using a proxy for data plane communication, it still requires an agent for initialization and communication with the control plane. First, the agent generates a bootstrap file at startup, in the same way that it generates bootstrap files for Envoy. This tells Dubbo how to connect to istiod, where to find certificates for data plane communications, and what metadata to send to the control plane. Next, the agent acts as an xDS proxy, connecting and authenticating with istiod on behalf of the application. Finally, the agent obtains and rotates the certificate used in the data plane communication.
-
Pull Requests
The agent feature is completely optional for the user. Just follow the instructions in Dubbo Proxyless
use-agent=true
To enable agent mode
-
Note: Since the native xDS protocol cannot support getting the mapping from interface to application name, you need to configure providedBy parameter to mark which application this service comes from.
-
Support for more routing modes.
-
Support dubbo application-level service discovery.
-
In the future, we will realize automatic service mapping relationship acquisition based on the control plane of Dubbo Mesh. At that time, Dubbo will be able to run under the Mesh system without independent configuration parameters, so stay tuned.