替换 Spring Cloud，操作基于 Cloud Native 的服务治理

 

　　Service Mesh

 

　　Service Mesh 是另外一个更激动人心的话题，也是现在大家都在研究的前沿方向。传统应用之间的通讯一直是很复杂的问题。比如 Spring Cloud Ribbon 做了很多安全、分流的工作，而这些工作其实跟业务本身相关度非常低。那么这些能力可以提取出来吗？社区给出了一个全新的答卷：Service Mesh。

 

　　Service Mesh 所做的事情是在节点之间通过一个 Proxy 代理层截获所有流量，节点之间通过特定的网关进行转发。因为所有流量都被劫持了，可以做很多工作，包括 load balance、根据 label 做灰度发布等。

 

　　Spring Cloud 原生的默认设置无法实现全链路灰度，需要改 load balance 策略，这样会导致同源数据里的开发工作量增加。但是在云原生体系里，Istio 直接配一个 virtualservice 就能完成。虽然 Istio 有一些功能还在开发过程中，但使用 Istio 会更加容易，因为它把跟业务不相关的属性全部剥离出去，不再跟应用绑得那么紧密了。

 

　　双向 TLS

 

　　举例来说，如果要提供双向 TLS，传统做法如果是应用自己来解决这个问题，就要先发个邮件通知要升级双向 TLS 了，然后每个人都得配一下自己的证书，这个过程非常痛苦。现在有了 Service Mesh，只要通过一行声明式就可以在不同的 Proxy 之间强制打开双向验证，保证整个网络安全，至于服务跟 Proxy 之间的安全则由隔离性来保证。

 

　　熔断

 

　　对于 Spring 社区主打的熔断器功能，也可以直接使用 Istio 提供的 destinationRule 的能力，只需要简单配置一些参数即可，比如访问的最大可连接数、错误多少次之后会被拒绝、进行 Half-Open 重试的间隔等。

 

　　Centralized Metrics

 

　　Metrics 可以通过 sidecar 获取，无需像传统架构由应用获取。如果应用本身还暴露出来一些业务的 Metrics，通过 Prometheus 的定制抓取可获得这些数据。但如果只是想知道一些网络吞吐 Metrics，现在应用本身也不需要直接提供，这样又减少了应用业务的负担。

 

　　总结与展望

 

　　Service Mesh 的出现提出了一个全新的思考方向：我们真的要将那么多中间件功能放在应用本身吗？恰好社区也在思考这个问题。CNCF 社区最近有一些新的博文，提出了一个叫做多运行时的架构体系（Multi-Runtime Microservices Architecture)，这是一种全新的理念，认为围绕业务我们需要提供四种能力：

 

　　生命周期管理：管理应用什么时候启动，什么时候关闭等。包含打包、健康检查、部署、扩展、配置等功能。

 

　　网络管理：包括服务发现、A/B test、灰度发布、熔断、点对点通讯、pub-sub 等。

 

　　状态管理：包括 workflow 管理、缓存、应用状态等。

 

　　绑定：包含数据传输，协议转换等。

 

　　有了这些能力，开发人员只需关注业务逻辑，研发效率将会极大提高。

 

　　这些能力基于云原生体系也可以做到。比如生命周期可以基于 Kubernetes 去做，网络可以基于 Istio 去做，状态管理可以基于 Cloud State 去做，绑定可以基于 Camel 去做。将这些东西组合在一起，业务单元就无需再关注这些事情。而 Spring Cloud 为了解决复杂的依赖问题，需要 maven 依赖，要依赖很多组件。当然这些事情慢慢都可以去掉，我们只要关心业务单元最核心的部分——业务逻辑，因为只有这个部分才是真正动态的逻辑。

 

　　有了多运行时架构，会发现一个很大的变化：一旦业务单元变得足够小，我们只需要去写业务本身，进行数据的读取和存储就可以了。这时如果想获得额外的服务发现、熔断、配置管理等服务，只需要在外围添加这些能力即可。

 

　　大家可能会问，多运行时跟 FaaS 有什么关系？可以看一下这张图：

 

　　单体架构的复杂度和规模化正相关，规模越大复杂度越高，中间件越复杂。FaaS 在复杂度提升的过程中，提高了拓展度但是复杂度却背道而驰，Mecha 的设计是希望随着规模化，可以将复杂度控制在一个较低的水平之内。

 

　　最后展望得有点长远，其实现在 Istio 还在开发的过程中。Istio v1.9 之后一直在提速，要一切为了生产。整个社区在积极推动 sidecar 模式，要将很多非业务单元的东西移出来，比如负载均衡、服务发现、弹性伸缩。至于未来我们是否能走到多运行时路线上来，也是我们的展望，希望大家能够跟我们一起来探讨整个云原生架构的未来。

 

　　Q&A

 

　　Q1：Istio 有好用的控制器吗？目前还没有看到成熟的控制器，使用 Istio 的难度比较大。A：Istio 确实没有好用的控制器，因为现在看起来还是一个比较前沿的方向。已知的像 solo.io，他们做了一些产品，是直接基于 Envoy，没有基于 Istio。但是我觉得社区是不断发展的，产品也会不断推陈出新，可能要交给后面的人来解决这个问题。当前的确是没有好用的控制器。

 

　　Q2：新的云原生平台和微服务能力是否是语言无关？有关的话选的是哪些？A：整个 CNCF 社区比 Spring Cloud 社区能打的原因就是因为语言无关。如果将语言绑定，很多平台可以自己自洽，就比较简单。但是我们要接受现实：现在的互联网体系，或者整个软件体系，异构已经成为了必然的趋势。我们不可能要求所有人只会一门语言，这个时候可以用不同的语言去实现不同的事情，不同生态会有不同的构成。Kubernetes 以及 CNCF 社区就在做这件事情。

 

　　Q3：kube-proxy 能否完全替代 Spring Cloud Zuul 或 Gateway？A：这个问题其实还蛮有意思。kube-proxy 现在还是基于 iptables 和 IPVS 做转发的工作，当然像 Cilium 基于 kube-proxy 的 eBPF 做了很多的工作。至于未来会不会完全取代，从我的经验上来看，Service Mesh 融入了很多业务属性，可能并不是 kube-proxy 想要去支撑的。

 

　　Q4：Kubernetes 环境下，开发人员如何比较方便地调试本地代码？A：现在还有一些单机版的 Kubernetes，比如 minikube 或者一些云厂商，都会提供比较合理的本地直接访问云端服务的特性。个人更建议开发者尝试一下 minikube/K3s， 就在本地运行，进行一些调试是非常方便的。