Istio’s rogue API Gateway

The status quo

The following is the current architecture of our system, for a brief introduction:

  • The infrastructure is on huawei Cloud
  • Basically based onistio on k8sArchitecture.
  • istioVersion 1.3, so there are many components (Galley, Pilot, Citadel, Telemetry……)
  • Microservice backendspring bootThe monomer, the front end hasNodejs, vueEtc.
  • Application link monitoring is based onskywalking.istioThe communication layer is utilizedkialiVisual call chain
  • Others are more traditional
Historical architecture

The role of ISTIO as a service communication infrastructure is described here

  1. Inter-service communication, dependencyenvoy sidecar
  2. Registry, dependenciesistioControl surface
  3. Service governance (fuse, timeout, retry)This part is not completely cut, there’s somespring bootApplications rely onhystrix, will be changed to useistio.
  4. Traffic Management (ingress gateway,egress gateway, load balancing)
  5. Testing (error injection)

By decoupling these control surface functions from the traditional microservice architecture to ISTIO, the microservice application itself can be focused on business development, making it a simpler standalone SpringBoot application. Combined with the high scalability of K8S, the overall iteration speed and operation and maintenance efficiency of R&D are relatively high. The disadvantage is that the learning cost is high for both K8S and ISTIO, and the team needs at least two people with professional knowledge, which is risky for recruitment cost and system upgrade.

The false

Frankly, if I had designed the system in the first place, I would not have used such a “radical” approach and would have switched to a Spring Cloud-based architecture, which, of course, K8S would most likely have used. Unfortunately, I took over in the middle and thought about changing the architecture. However, due to the pressure of the company’s business and iteration, and the limited manpower, the risk of changing the architecture would be very high. Therefore, since I was caught by IStio, I had to go on, and when the time is ripe, I will parallel other architectures or switch back to the appropriate architecture. Here I would like to emphasize that the choice of architecture or selection is not for the sake of technology but for the sake of technology. It must be very suitable for the development status of the company at that time, business scenarios, team capabilities, recruitment costs and so on. Coincidentally, istio’s logo also looks like a sailboat.

API Gateway

Finally, the focus of this article, the API Gateway. I’ve written a previous article on this topic, and you can take a look at the API Gateway from a functional level without the current architecture.

Selection of API gateway and architecture design including BFF

Going back to our current architecture, you can see that although we have openResty upfront, there is no service on the application layer that acts as an API Gateway. However, neither openResty nor Nginx can fully meet the requirements of the cloud native API Gateway.

Of course readers who know About Istio might ask:

  • istio ingress gatewayDoesn’t it also function as a gateway?
  • Why didn’t it worknginx ingress controller ？

First of all, I admit that the functions of various Ingress controllers implemented based on K8S Ingress are becoming more and more perfect. If we did not use ISTIO, we might adopt this scheme, but we did. Then combined with K8S Ingress, the following problem will be solved as described in how to select an entry gateway for the service grid [1] :

  • K8s IngressIs independent inIstioThose outside the system need to be used separatelyIngress ruleAs a result, two sets of independent routing rules are configured for the system entry and interior, which complicates operation and management.
  • K8s Ingress ruleBecause of its weak function, the routing rules similar to those in the grid cannot be implemented in the entrance, and there is no gridsidecarAs a result, it is difficult to realize the grayscale publishing, distributed tracking and other service control functions for the application system as a whole.

The second, that’s rightistio ingress gatewayIn addition to the basic communication functions, there are other application layer functions. But let’s put it all togetherk8s ingress,istio ingress gatewayAnd our idealAPI Gateway, you will find that it is not perfect, mainly forAPIThis part of management lacks functionality.

In the future

Various IMPLEMENTATION solutions of API Gateway have been discussed above, and the conclusion is that it is difficult to find a Gateway with the capabilities of API Gateway and Isito Ingress at the same time. So let’s review our requirements:

  • We use istio
  • We need an API Gateway

Therefore, after thinking, our future scheme design is as follows:

  • Still useistio ingress gatewayAs the entrance
  • willistio ingress gatewayreceivedLB
  • willAPI GatewayInto theistio clusterIn the category of management, that is ownershipsidecar proxyThat can beistioControl surface control.API GatewayThe selection is likely to use a cloud native application gateway, such asAPI SIX
  • Application layer microservices do not encode a service gateway using a service gateway such as spring Cloud Gateway

Summary: UseAPI GatewayandSidecar ProxyTogether to provide external traffic entry to the service grid.

Any other questions?

[2] The advantages of the above solution are that the API Gateway and Sidecar are deployed independently, with clear responsibilities and clear architecture. However, just as the Service Mesh’s sidecar is questioned about the performance overhead and efficiency impact of the additional hops, the API Gateway’s Sidecar is also questioned about the additional hops…

For this jump, the extra time is almost negligible in terms of the network time and function of each segment of the entire architecture.

How about performance?

Envoy’s performance as a sidecar should not be in doubt. As for Istio Ingress Gateway, although the official data is also good, we should observe it in practice. As the Cloud Native API Gateway, such as API SIX, I have sufficient confidence in it. At least in the current business volume of our company and the 100-fold growth scale in the future, we will not worry about the performance problem.

The resources

[1]

How do I select an entry gateway for the service grid? : https://zhaohuabing.com/post/2019-03-29-how-to-choose-ingress-for-service-mesh/#k8s-ingress


[2]

Service Mesh and API Gateway relations in-depth: https://www.servicemesher.com/blog/service-mesh-and-api-gateway/

Pay attention to the technical sharing of the public number small box to get more exciting content.