Anypoint Service Mesh 1.2
Anypoint Service Mesh enables you to extend your microservices network by including your non-MuleSoft applications into the Anypoint Platform sphere. You can then manage and secure your application network, including your non-Mule applications, seamlessly from a single pane.
Your non-MuleSoft microservices might be written using different languages and platforms, or might be deployed in different environments. To alleviate issues arising from differences in these microservices, Anypoint Service Mesh ensures the following application management advantages:
-
Provides resilient service-to-service communication using zero-trust policies to handle traffic control, fault tolerance and load balancing
-
Extends MuleSoft API Management capabilities to any non-Mule service, with policies, security and analytics all applied directly from Anypoint Platform
-
Amplifies reuse of services with discovery of non-Mule services within Exchange, available for use in future projects
Anypoint Service Mesh Architecture
Anypoint Service Mesh is an independent architecture layer encapsulated in a Kubernetes or a Red Hat OpenShift cluster. In the Anypoint Service Mesh architecture, instead of the services directly communicating with one another, a sidecar proxy is used to perform the same job.
The sidecar proxy enables you to bring your existing non-Mule microservices from the Kubernetes Cluster as APIs into Anypoint Platform. You can then manage these APIs within API Designer, API Manager, and Exchange. Additionally, you can monitor the health of your APIs using API analytics.
Because the mixer component is deprecated in Istio v1.5 and later, the authorization mechanism aspect of the mixer is now implemented by leveraging Anypoint Service Mesh Envoy filters. With the Envoy filter, requests are sent directly to the adapter, thereby minimizing additional processing.
As illustrated in the diagram, at the top of the architecture is Anypoint Platform, which brings complete lifecycle API management capabilities to the microservices built with Mule runtime engine (Mule). These Mule instances might be deployed within CloudHub, or Runtime Fabric at your location.
Istio, which is installed on a Kubernetes cluster, uses Envoy to manage services by using a sidecar proxy. The sidecar is responsible for any communication with your service, and resides within the same container as that service. With Anypoint Service Mesh enabled, you can continue to use Istio’s native policies for traffic control and security.
The MuleSoft adapter connects components to Anypoint Platform. Along with a broker, the adapter enables all services that are managed by the mesh to share metadata, which in turn enables your existing microservices in the Kubernetes cluster to be recognized as APIs by Anypoint Platform.
After the services are discovered, Anypoint Exchange uses the metadata to automatically discover and create APIs (HTTP, REST, or SOAP) for each service. These APIs can then be managed within API Manager. Similarly, Anypoint Monitoring uses the metadata to get information from the sidecar proxy and makes it available for API Analytics.
Service Request Flow
When a service is called, Anypoint Service Mesh ensures a smooth request flow and security checks as shown in the following diagram:
-
The client, which might be another microservice or any Kubernetes Ingress component, sends a request to the service.
-
Envoy captures the request and redirects it to the MuleSoft adapter using the Envoy filter.
The adapter then performs policy checks and verifications.
-
When no policy violations are encountered, the request is routed to the microservice.
-
The microservice runs the service logic and sends the response back to the client.
-
Periodically, the adapter communicates with Anypoint Platform asynchronously to get the latest policies and contracts.
-
Periodically, the adapter returns the API analytics information to Anypoint Platform.