kubernetes和springcloud的发展历程( 四 ) SpringCloud技术体系简介我们通过

有了多运行时架构，会发现一个很大的变化：一旦业务单元变得足够小，我们只需要去写业务本身，进行数据的读取和存储就可以了。这时如果想获得额外的服务发现、熔断、配置管理等服务，只需要在外围添加这些能力即可。
大家可能会问，多运行时跟FaaS有什么关系？可以看一下这张图：
单体架构的复杂度和规模化正相关，规模越大复杂度越高，中间件越复杂。FaaS在复杂度提升的过程中，提高了拓展度但是复杂度却背道而驰， Mecha的设计是希望随着规模化，可以将复杂度控制在一个较低的水平之内。
最后展望得有点长远，其实现在Istio还在开发的过程中。Istiov1.9之后一直在提速，要一切为了生产。整个社区在积极推动sidecar模式，要将很多非业务单元的东西移出来，比如负载均衡、服务发现、弹性伸缩。至于未来我们是否能走到多运行时路线上来，也是我们的展望，希望大家能够跟我们一起来探讨整个云原生架构的未来。
Q&A
Q1：Istio有好用的控制器吗？目前还没有看到成熟的控制器，使用Istio的难度比较大。A：Istio确实没有好用的控制器，因为现在看起来还是一个比较前沿的方向。已知的像solo.io ，他们做了一些产品，是直接基于Envoy ，没有基于Istio 。但是我觉得社区是不断发展的，产品也会不断推陈出新，可能要交给后面的人来解决这个问题。当前的确是没有好用的控制器。
Q2：新的云原生平台和微服务能力是否是语言无关？有关的话选的是哪些？A：整个CNCF社区比SpringCloud社区能打的原因就是因为语言无关。如果将语言绑定，很多平台可以自己自洽，就比较简单。但是我们要接受现实：现在的互联网体系，或者整个软件体系，异构已经成为了必然的趋势。我们不可能要求所有人只会一门语言，这个时候可以用不同的语言去实现不同的事情，不同生态会有不同的构成。Kubernetes以及CNCF社区就在做这件事情。
Q3：kube-proxy能否完全替代SpringCloudZuul或Gateway？A：这个问题其实还蛮有意思。kube-proxy现在还是基于iptables和IPVS做转发的工作，当然像Cilium基于kube-proxy的eBPF做了很多的工作。至于未来会不会完全取代，从我的经验上来看， ServiceMesh融入了很多业务属性，可能并不是kube-proxy想要去支撑的。
Q4：Kubernetes环境下，开发人员如何比较方便地调试本地代码？A：现在还有一些单机版的Kubernetes ，比如minikube或者一些云厂商，都会提供比较合理的本地直接访问云端服务的特性。个人更建议开发者尝试一下minikube/K3s ，就在本地运行，进行一些调试是非常方便的。