Closed haoel closed 2 years ago
propose 1 is a kind of extension of EaseMesh. It's a product feature. And it's a natural way since EaseGress states to extensible with Controllers
and Filters
.
propose 2 or 3 are more like a kind of integration solution.
product feature preferred.
The internal mesh controller designed for the external service registry shows below.
There are some points:
just sync data from embedded Etcd(required)
, or plus sync data to Etcd(optional)
.The real problem here is: We want to fix the problem about communication between two heterogeneous systems. And we list two potential proposals
First, it is the bi-directional sync for external registry and internal registry. Services in each system still used their own registry with more services from another system. Second, it uses ingress controller to handle the incoming traffic from external services (ingress controller will automatically generate mesh service rules). So we need to sync external services to internal registry only. But we also need to tell external services the EaseMeshService-Mapping-Port in a kind of way.
Characteristics | Bi-directional Sync Data | Ingress Controller as Proxy |
---|---|---|
Complete info showing | All registries | Only in internal registry |
EaseMesh services calling external services | External services register accessible ip:port | External services register accessible ip:port |
External services calling EaseMesh services | External services need authority to access pod in k8s (EaseMesh service instance is accessible by pod.IP) | External services call ingress controller with different ports standing for diffrent EaseMesh service |
Syncing data | Bi-directional sync between external and internal registry | One-directional sync from external to internal registry |
Limitation | Some external registries lost part of required features | Port limitation of k8s ingress controller (need every node of k8s open a lot of same ports) |
NOTES:
Ingress controller saved one-directional sync process, but besides the port-range limitation, it seems that EaseMeshService-Mapping-Port is also dynamic info needed to be sync in real-time (two-directional sync in kind of lighweight version). So I think the bi-directional way is better.
Currently, our mesh can be compatible with Eureka/Nacos/Consul client, and we use the EG's etcd as service discovery.
There is a highly possible scenario we need to consider here - two different types of architectures( Spring Cloud vs Ease Mesh) running together, both of them need to be discovered by each other.
Here are serveral proposals: 1) proxy the service's register/discovery action to the original service registry, but replace the with its mesh sidecar.
2) sync up the service discovery data between Ease Mesh and Spring Cloud.
3) using an Anti-corruption Layer. Note: this pattern is used for isolating the old system, but actually the Spring Cloud is not.
How to achieve this, we need to discuss deeply.