Java卷比们又从SpringCloud转向k8s+Istio了？

免责声明~

任何文章不要过度深思（万事万物都经不起审视，因为世上没有同样的成长环境，也没有同样的认知水平，更「没有适用于所有人的解决方案」；不要急着评判文章列出的观点，只需代入其中，适度审视一番自己即可，能「跳脱出来从外人的角度看看现在的自己处在什么样的阶段」才不为俗人。怎么想、怎么做，全在乎自己「不断实践中寻找适合自己的大道」）

• k8s+istio显然更具优势成体系，但Java系自成体系的微服务治理框架且应用在生产上的基数庞大，最终会转向k8s，istio吗？

• hystrix等也停更转维护了，微服务框架相关社区和Netflix这样的领头企业又是怎么走向呢？

• istio真的有公司大规模上生产吗？

1 前言

18年学习Spring Cloud时，我就意识到这个问题，果断从docker转向k8s，但依然保留spring cloud作为过渡。

2 入坑Service Mesh

调研Service Mesh落地方案等相关案例时，发现即便Google背书的ServiceMesh的Istio，落地仍有不少阻碍，最要命是lstio分布式架构太复杂了，极大限制落地条件，对中小企业和国企，本身就不复杂的业务，还去落地lstio简直就是本末倒置！

3 转向Linkerd

反观Istio劲敌Linkerd，很早意识到分布式架构弊端，Linkerd2.0回归单体架构，并使用无GC编程语言Rust重构，很好遏制SideCar容器的喧宾夺主：资源消耗比业业务容器还多！

而且Google出尔反尔，没把Istio捐给CNCF，反而交给新成立完全控股子公司，目前也只是 CNCF 的孵化项目！

而Linkerd2.0已成CNCF的毕业项目！

推荐中小企业使用Linkerd：

• 节约成本
• 加速Service Mesh落地
• 避免Google背刺

4 Service Mesh的局限性

从我大四那会接触Service Mesh，直到今年完全转向云原生领域。

目前主流Service Mesh方案都离不开SideCar，而随业务需求变化，SideCar容器变得越来越复杂，甚至到了资源占用消耗超过业务容器，喧宾夺主！

这是Service Mesh解决方案商不愿告诉你Service Mesh落地可能会带来的不良后果之一！

也可以说是微服务架构不可避免的缺陷之一！

要解决问题，必须逐步过渡到Serverless架构！

5 Serverless

Serverless = FaaS + BaaS

BaaS即"Backend as a Service"，把后端服务当作可提供服务的资源。

后端服务既可是单体，也可微服务架构。

要解决微服务治理问题，可继续使用SideCar模式的lstio和Linkerd，但要解决SideCar容器膨胀问题，不得不引入FaaS！

6 FaaS

FaaS，Function as a Service，把函数当作是一种可提供服务的资源。

即把sideCar容器的功能拆分一个个功能独立函数，如日志收集、流量管控、身份鉴权等，再接入FaaS引擎后，SideCar容器占用资源就能大幅降低。

目前已经有很多云服务厂推出FaaS产品，如AWS lambda，但使用这些产品易被厂商绑架，而且使用场景也不是针对SideCar场景，所以我推荐WebAssembly作为Faas落地方案。

7 WebAssembly

简称wasm，面向Web的汇编字节码标准。

在性能表现/资源消耗等方面，远优于JS，更有C/C++/Rust/Go/Swift/Kotlin/Ruby等主流编程语言支持。wasm是开放标准，已演进到2.0草案阶段，未来还有更多特性支持及更多编程语言加入wasm阵营。

业界普遍认为WASM未来成为公认FaaS标准！

私以为，SideCar最佳解决方案，就是通过DaemonSet在每个节点上部署一个WASM调度器，开发人员将日志收集、流量管控或身份鉴权等功能编译为wasm格式，再由WASM调度器统一调度！

目前开源的wasm调度框架就有fermyonq推出的spin。wasm实例的创建与销毁overhead和footprint，都远低于docker容器的创建和销毁，是sidecar容器Q的优秀替代品！

至于因为公司业务体量小等原因，还没有上了Istio或者linkerd船的企业，可以考虑一下cilium。

8 cilium

cilium原本只是k8s的容器网络CNI解决方案之一，但由于cilium采用Linux最热门的新特性eBPFcilium在性能效率和功能丰富层面上击败其他CNI解决方案，成为最受欢迎的CNI解决方案。

9 eBPF

目前Linux内核最受追捧的子系统，本质是Linux内核中的一个虚拟机。它使得在inux内核只中动态执行任意的代码变成可能。进一步降低linux内核开发难度，以驱动开发为例，由于linux是宏内核，驱动须与内核一起加载，一旦新开发的驱动存在bug，极可能导致内核崩溃。现有eBPF，调试驱动程序就容易多，由于eBPF本身是个虚拟机，在加上eBPF程序都必须经过一系列检测，确保程序不会出现问题后才能执行。

eBPF也推动SDN/NFV的发展，最近cilium宣布进军Service Mesh，与lstio/Linkerd不同，cilium针对Service Mesh解决方案并没有出现SideCar，而是通过eBPF钩子实现流量管控、服务发现、负载均衡、链路追踪、灰度发布等常见的Service Mesh特性！

eBPF目前不满足图灵完备只的要求，如不支持循环，过深递归调用，程序大小限制等！

再者有些功能需求，例如日志收集、应用配置等，采用常规的技术栈完全可以满足需求，没必要采用eBPF来增加开发的难度，完全可以用wasm的方案来解决SideCar容器膨胀的问题。

10 总结

综上，eBPF based cilium + wasm based Spin才是最理想Service Mesh解决方案。

写在最后

​​公众号​​​：​​JavaEdge​​​ 专注分享软件开发全生态相关​​技术文章​​​、​​视频教程​​​资源、热点资讯等，如果喜欢我的分享，给 🐟🐟 点一个​​赞​​​ 👍 或者 ➕​​关注​​ 都是对我最大的支持。

文章转载自公众号： JavaEdge