Kubernetes 可能是分布式架构的大结局了

前两年在爬虫里折腾的太久了，最近快马加鞭追赶分布式架构潮流。

SpringCloud、Dubbo、ServiceComb 刷完，以为分布式架构就是这样了。这批架构可能也就 Java 栈的人会感觉它们特别方便特别强大，其实就那么回事而已。我以为下一代架构应该是 FaaS。相比 d2js，FaaS 的缺陷是不支持函数束，看起来就像一个一个的 Servlet，和 Servlet 相比 FaaS 在容器方面进步挺大，而编程模型却倒退了。 消息驱动的设计也谈不上多出人意料，结合流程编排倒是可以实现点实用的东西。

另外一个思路就是设计一种新的分布式编程语言，将流程拆解到各个容器上执行。这种语言之前构思过，思路还是很有价值。我看到有一个叫 Rockscript 貌似有点眉目。

然后，这两天读 Kubernetes ———— 当时就惊呆了！

这TM才是程序员该干的活！

怎么说呢，

Kubernetes 是一种典型的软件驾驭硬件的设计，它把一种声明式的编排规格自动展开到容器上。真正的程序员都明白，程序不能驾驭硬件只能框在硬件上跑那是没追求。我爬虫框架都有自动起 GCP 实例的设计。

Kubernetes 也是一种透彻的思维方式，Kubernetes 将所有高大上的冠冕堂皇的服务和 hello world 一样，看成是一个个可以容纳在 Docker 里的需要资源的 Service，并为此构造了一个个 Pod 概念。上次遇到这样的颠覆还是在 erlang 里，erlang 构造出名为 Process 的语言实体，透过 Process + Message 的眼光，我能感受到，spawn Process 就是开机！Process 结束就是关机！而参数，就是开机的上下文！！遗憾的是这种透彻的思维方式在 Java 的世界里很少看到，Javaer 津津乐道的 Annotation 在我看来就是一种投机取巧————因为程序语言有这玩意儿我就要把它发挥到极致。

Kubernetes 将软件下沉到以往看来像磐石一样沉默有力的 TcpIP 栈，巧妙的把 DNS 这种互联网世界的事物当做一种内部服务命名策略，让人感到那种真正的程序员所爱玩的把大象卷吧卷吧放冰箱里的快乐。

记得上家公司老板希望推动上 K8S，我当时沉迷于爬虫没有花时间深入。 当时做的爬虫架构里有和 K8s 非常相似的监测 CPU 负载飙到多少自动开机降到多少自动关机的方案，但是只作用于爬虫系统。K8S 的 Label + Selector 也有恰好类似的设计，这也是通透点的思维都会摸到的门吧。当时的业务场景确实不太需要 K8s，毕竟是CPU密集型， 但老板能看到这个技术的价值而我无动于衷也是个固步自封的教训了。

和 Java 的所谓分布式架构不同，Kubernetes 把 Process 和操作系统割开，在二者之间塞入了一个新的调度层或者说容器层，这个设计是对任何操作系统、任何语言的应用都通用。所以，Kubernetes 实际上判了 Java 那些分布式框架死刑。我不知道这些框架还腆着脸凑热闹有什么意义。记得有一次交流时我说过，这些所谓的分布式架构，未来就会像基础设施一样，没人关心它们的存在，到那时也不会有系统架构师这样的岗位————到那时人们会发现，不就是部几台机器吗，是个人就会。

通常，更究极更通透的设计往往也更为灵活开放，Kubernetes 这种在操作系统和进程间插一杠子的做法让 Java、PHP、C、Python、JavaScript 都获得了相同的能力，它们都可以变成自动伸缩的分布式服务而不需要进行任何改造。只有真正的程序员才会做这样的设计：大家都要活的好好的，一齐进入分布式时代。而 Javaer 总喜欢大一统，高大上，充满了包举宇内的雄心壮志，却很少讨人喜欢，Java 真是官僚主义的编程语言啊————或者说 Java 是官僚主义者的大本营。

伴随 Kubernetes 出现一个概念叫 DevOps，这个概念也许有它的价值，但是，计算机不就是跑程序的吗，程序员看着计算机有什么奇怪的。。。。

前段时间感觉 d2js 需要大调整的想法也没有了， d2js 看来还很棒，除了要支持异步（换 vertx）没什么大毛病。分布式不用 d2js 来解决，d2js 不需要傍哪个框架让自己分布式起来。

当然，世界上没有完美的方案，Kubernetes 是否有别的搞法也值得深思。比如 Process + 协议栈 context 是否就足够了？毕竟 docker 之类的技术难免会拉低点性能。这些在后面会有人做，即使以后 Kubernetes 被取代了也无法掩盖 Kubernetes 开创性的光芒。

有了这么多美好的技术，我觉得再造轮子意义没有那么大了，把 d2js 略加改进好好做点自己想做的东西，这才是我的使命。