Compatible with Spring Cloud service discovery

[Hao Chen]

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 IP:Port 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.

[exudong]

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.

[Yun Long]

Proposal

The internal mesh controller designed for the external service registry shows below.

There are some points:

1. Embedded Etcd is the one and only one store representing all information anytime.
2. External service registry co-exists with embedded etcd.
3. Service registry framework will implement all APIs, the drivers which missed some features will be warned.
4. The external service registry could be configured as just sync data from embedded Etcd(required), or plus sync data to Etcd(optional).
5. The adaptation of the external service registry is a framework with drivers such as Eureka/Nacos/Consul.

[Yun Long]

Follow Up

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:

• k8s in the table means the same k8s cluster with EaseMesh

Proposal

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.