In the Spring Cloud framework, developers use SDKs to implement microservices governance. Service Mesh (ASM) provides governance capabilities in a proxy that is completely independent of application development. This is different from the SDK-based microservices governance. From the perspective of the architectures and use scenarios, Spring Cloud is a development framework while Istio is an infrastructure. The two vary in design philosophy. This topic describes how to migrate Spring Cloud microservices applications to ASM.
Background information
Spring Cloud provides developers with tools to quickly build some common patterns in distributed systems, such as configuration management, service discovery, circuit breakers, and intelligent routing. Developers who use the Spring Cloud framework need to manage Config Server, Service Registry, Spring Cloud Gateway services, and microservices applications. This takes away valuable time from developers to deliver business outcomes and slows down the release velocity. The following section describes how to replace the capabilities of Spring Cloud modules within a microservices application by using Kubernetes and ASM services.
Service registration and discovery
When Spring Cloud microservices are deployed as containers running in Kubernetes clusters, service registration and discovery may be delayed. The root cause is that the service discovery mechanisms are different for Spring Cloud and Kubernetes. Therefore, the solution is to unify the service discovery. In other words, Kubernetes already maintains the data between Services and endpoints during pod scheduling. Therefore, it is no longer necessary to use a set of naming service mechanisms to register services. It is a best practice to converge service registration and discovery to Kubernetes.
Service gateway
After you migrate Spring Cloud microservices to Kubernetes and ASM, if the original Spring Cloud Gateway also provides other service-related capabilities, we recommend that you deploy Spring Cloud Gateway as a service in the mesh. However, in most cases, we recommend that you directly replace Spring Cloud Gateway with an ingress gateway of the ASM to provide Transport Layer Security (TLS) termination, throttling, and traffic splitting in a non-intrusive manner.
After you implement the above solutions, services developed in different languages and development frameworks can be managed by using ASM as long as the service access protocols are compatible.
Unified service management rules can be configured on the control plane. On the data plane, sidecar proxies are used to provide service discovery, load balancing, and other capabilities related to traffic management, security, and observability. At the early stage of the migration of Spring Cloud microservices, you can also reserve the service registry in the original microservices framework. This enables services in the mesh to access services registered with the original service registry.
Component comparison
Components that are often used in microservices management include those for service registration, service discovery, and load balancing. The following table lists the features that are required when you migrate Spring Cloud microservices to ASM.
Category | Feature | Description | Istio | Spring Cloud |
Basic service management | Configuration center | Manages the configurations of application services. | This feature is implemented by using Kubernetes ConfigMaps. | This feature is implemented by using Spring Cloud Config. |
Service registration and discovery | When you deploy an application service, these two features enable automatic service registration and allow a service consumer to automatically discover the registered service. | These two features are implemented based on Services and Core DNS in Kubernetes. Istio DNS proxying is supported. | Service registration and discovery are implemented by using components such as Consul and Nacos. | |
Service isolation | Isolates services based on namespaces. | Services are isolated by using Kubernetes namespaces. | Namespaces are not supported. | |
Routing management | Routing management | Manages the access routes among application services. | You can manage the access routes among services based on the routing rules configured in YAML files. Istio defines virtual services and destination rules to support corresponding routing rules and load balancing policies. | Generally, routing is enforced on the gateway. Routing capabilities provided by sidecar proxies are not available. |
Load balancing | Performs load balancing for requests sent from clients. | You can implement load balancing based on the load balancing policies configured in YAML files. Istio defines virtual services and destination rules to support corresponding routing rules and load balancing policies. | Load balancing is implemented by using Ribbon or Feigin. | |
High service availability | Fault injection | Simulates failures of application services to improve availability. | You are allowed to configure two types of fault injection in YAML files: timeout and delay. | Fault injection is not supported. |
Throttling and circuit breaking | Prevents service crashing during application service calls. | You can configure throttling and circuit breaking in YAML files. | These two features can be implemented by using Hystrix. However, you must inject some code. | |
North-south traffic management | Ingress and egress gateways | The ingress gateway works as the entry point for client requests. The egress gateway provides a way for applications in ASM to access external services. | Features of ingress and egress gateways are implemented by using Istio ingress and egress gateways. | Features of the ingress gateway are implemented by using Spring Cloud Gateway. |
Observability | Log collection | Collects logs of application services. | Generally, logs of application services are collected in the same way as those for pods. | Elasticsearch, Logstash, and Kibana (ELK Stack) is used for log collection. |
Distributed tracing | Describes the traces and topologies of application service calls. | Distributed tracing is implemented by using sidecar proxies and Zipkin. In addition, the topology of application services is displayed by using Kiali. | Distributed tracing is implemented by using Zipkin. | |
Security | Service authorization | Controls access to application services. | You can authenticate and authorize services based on the Istio authentication and authorization policies configured in YAML files. | You can authenticate and authorize services by using the Spring Security component. |
TLS/mutual TLS (mTLS) and identity authentication | Implements TLS encryption and decryption of service request traffic and identity authentication. | TLS and mTLS encryption and decryption of service requests are supported based on mTLS authentication and JSON Web Token (JWT)-based authentication configured in YAML files. | Spring Cloud does not support TLS, mTLS, or identity authentication. However, it can integrate with other components to provide such support. | |
Access control based on blacklists and whitelists | You are allowed to flexibly configure blacklist and whitelist-based access control policies for application services. | You can control access to services based on the Istio authorization policies configured in YAML files. | To control access to services, you must inject some code. | |
Use scenarios | Migration of application services | Indicates whether you need to modify the source code when you migrate application services to a distributed microservices architecture. | Automatic sidecar proxy injection can be implemented by using Kubernetes webhooks. You can use the automatically injected sidecar proxies to implement service governance for the migrated application services without the need to modify the source code. | To migrate application services, you must modify the source code. |
Canary release and blue-green deployment | Mechanisms that allow you to dynamically release application services and perform graceful release of released versions. | You can implement the canary release and blue-green deployment of application services based on the load balancing policies configured in YAML files. Istio defines virtual services and destination rules to support corresponding routing rules and load balancing policies. | To implement the canary release and blue-green deployment of application services, you must modify the code. | |
Extensibility | Functionality extension | An extension mechanism for you to use more service management capabilities. | EnvoyFilter and WebAssmebly are used to extend capabilities. | Extensibility is not available. |