基于Java的Spring Cloud是由Java最大开源生态Spring社区推出的Out-of-Box分布式微服务解决方案,自2016年发布起就被众多开发者看好。Java作为广为流行的服务端编程语言,Spring Cloud也就越来越多的被用于微服务开发。

Spring Cloud集成了Netflix OSS开源项目实现了很多功能(或作为实现之一),包括服务治理、网关路由、客户端负载均衡、服务间调用、断路器等。Spring Cloud Netflix将很多生产级别微服务能力开箱即用的带到了Spring Cloud架构下的微服务中,帮助开发者快速的构建满足12要素的应用。

在去年底发布的Spring Cloud Greenwich版本中宣布Spring Cloud Netflix中重要的组件HystrixRibbonZuul 1等由于上游开源项目进入维护状态,对应的Spring Cloud Netflix项目也进入到维护状态。这些项目将不再适合用于长期维护的产品中!

同时随着近年云计算的发展,特别是Kubernetes成为容器编排平台的事实标准,加上Service Mesh(服务网格)对微服务的服务治理和流量控制,为云原生应用提供了更为现代、平台无关的解决方案。

让我们逐一看看在Kubernetes加上Serivce Mesh(例如Istio)如何实现微服务的服务发现、路由、链路追踪、断路器等功能。

配置中心 

Spring Cloud Config默认提供了多种配置管理后端,例如GitVaultJDBC Backend等。同时也有很多开源方案可以作为替换方案,比如Alibaba Nacos

作为部署在Kubernetes中的应用,最佳实践是平衡ConfigmapSpring Cloud Config。将涉及程序功能的配置放置在Configmap和Secret,随同微服务的发布一起做版本管理,可以做到随着应用回退的时候同时回退到历史对应的配置版本,而不会因为历史版本的代码被最新版本的配置所中断。Spring Cloud Kuberentes项目很好的支持了Spring Cloud应用从ConfigmapSecret中读取配置项。而涉及业务的配置选项,将可以考虑放到Spring Cloud Config后端实现统一管理。如果应用是部署在阿里云,使用阿里云托管的配置服务和Spring Cloud Config – Nacos将是很好的选择。

服务发现 

Kubernetes Services提供了集群内原生的服务发现能力,是EurekaSpring Cloud Zookeeper等服务发现服务的很好替代品。基于K8S Services的服务发现,很容易通过Service Mesh能力实现限流、A/B测试、金丝雀发布、断路器、chaos注入等服务治理能力。同时对微服务应用来说,不用在应用端添加对应三方库来实现服务注册及发现,减少了应用端开发需求。

各种流量治理场景 

应用被服务化后,一定会面临流量治理的问题。对于各种服务间如何实现限流、A/B测试、金丝雀发布、断路器、chaos注入测试、链接追踪等,这其实是一类通用的问题。

Spring Cloud提供的是一种客户端解决思路,需要每个应用引入对应功能的libraries的支持。即使通过spring boot starter提供了近似开箱即用的能力,但是每个应用仍然需要自行添加对应的能力,版本更新、安全漏洞fix等场景都需要手动升级、测试、打包、部署。在异构编程语言实现的微服务架构下,未必每种编程框架都能提供很好的对应能力支持。除非有特别的服务治理策略,不推荐在微服务自身来实现服务流量的控制。

Service Mesh(例如IstioLinkerd)从整个服务治理层面对上述需求提供了统一的解决方案,而不需要微服务做自身的升级或改动。在基于Kuberentes部署运行的微服务应用,Service Mesh提供了统一的服务治理方案,将用户从不同的微服务中自身维护服务治理功能中解放出来,从平台层面提供更加统一一致的解决方案。

在去年的SpringOne Platform 2018上也有一个Topic A Tale of Two Frameworks: Spring Cloud and Istio 探讨什么场景应该使用Service Mesh,什么时候使用Spring Cloud服务治理组件,有兴趣的朋友可以看一看。