megaease/easemesh

[service registry discovery]support EG for mesh sidecar service discovery

benja-wu opened this issue · 4 comments

benja-wu commented

Background

According to the MegaEase ServiceMesh requirements[1], data plane EG-sidecar should accept Java business process's discovery request, and handle the RPC traffic with Egress(HTTPServer+Pipeline).

Proposal

Discovery relied on structures

  1. Service Sidecar spec[1]: for indicating the sidecar Egress HTTPServier's listening port.
  2. Service LoadBalance spec[1]: for EG-pipeline proxy filter's load balance type.
  3. Service instance lists: for Pipeline proxy filter's IP pool and port.
  4. Other resilience specs: TODO, in next resiliences about issues.

Control Plane

  • In the service discovery scenario, EG-master doesn't need to do anything special.

Data Plane

Java business process

  1. Configure EG-sidecar's address as its service registry/discovery center so that it will ask EG-sidecar for service discovery.
  2. Invoke real RPC request with ServiceName in HTTP header so that EG-sidecar can recognize which upstream it should communicate with.

EG-sidecar

  1. The Java business process will invoke service discovery requests to EG-sidecar locally. The EG-sidecar supports Eureka/Consul[2][3] service discovery protocol. All Eureka API can be found here.[4] And it will always return 127.0.0.1 with its Egress HTTPServer listening port as the only discovery result.

  2. Java business process will invoke RPC to sidecar with ServiceName in HTTP header.

  3. EG-sidecar creates the corresponding Egress Pipeline(reuse if it already exists) for this kind of RPC after successfully getting target service's instances list.

  4. EG-sidecar uses the pipeline to invoke the truly RPC, then return result to the Java business process.

  5. sequence diagram
    Service-Registry-discovery sequence

  6. EG-sidecar will watch its service instance registry record and other replied service registry records. Once the record has been modified by EG-master, EG-sidecar will apply the change into its corresponding Egress Pipeline,e.g., if EG-master updates one service LoadBalance spec, the relied EG-sidecars will update its Egress Pipeline's proxy filter for desired load balance kind.

Reference

[1] mesh requirements https://docs.google.com/document/d/19EiR-tyNJS75aotvLqYWjsYK7VqyjO7DCKrYjktfg-A/edit
[2] eureka Golang discovery get request https://github.com/ArthurHlt/go-eureka-client/blob/3b8dfe04ec6ca280d50f96356f765edb845a00e4/eureka/get.go#L18
[3] consul catalog service discovery structure https://github.com/hashicorp/consul/blob/api/v1.7.0/api/catalog.go#L187
[4] Eureka API list https://github.com/Netflix/eureka/wiki/Eureka-REST-operations

benja-wu commented

After discussion with @zhao-kun and @xxx7xxxx, Sidecar will only create the corresponding egress pipeline when the java process invokes the RPC request. And the sequence diagram above had been updated too.

zhao-kun commented

I'll reserve my comments. Even I don't think it's a good design, I think that the design could be compromised with some conditions, so I accept it.

benja-wu commented

I'll reserve my comments. Even I don't think it's a good design, I think that the design could be compromised with some conditions, so I accept it.

Your comments about one pipeline for mesh life cycle, I will mark it to the next milestone. Cause that new design will impact the EG original model greatly if we adapt the current HTTPPipeline for it.
So I think a deeper consideration is necessary for comparing the Pros/Cons. I will open a new issue for this discussion after EaseMesh M1. Thx.

benja-wu commented

Merged into mesh branch already