| August 11, 2019
Kubernetes发行版
最近一条新闻出现在IT云计算软件圈中：Mesosphere更名为D2iQ，业务转型为提供企业级的云原生服务，即Kubernetes(K8S)发行版软件和服务。 不禁感叹Mesos/Mesosphere终于坚持不住了，K8S容器技术完胜。
结合前段时间Hadoop生态圈的几件大新闻，Cloudera和Hortonworks合并，MapR裁员。大家有没有看到技术变化带来的商业此消彼长的？
必须承认，Hadoop是个非常先进而且完备的生态，其核心思想是分而治之，即把数据和计算分拆到多个节点并行执行：数据分片或者分段处；计算用函数式编程方式进行批量或流式处理。 在多节点处理方面，Hadoop使用 Java 开发了完整的通信和调度方案，版本一为 MapReduce，版本二为 Yarn资源管理器。 仔细思考这个技术点，相信做多年软件的朋友都会敏锐的感觉到，从业务运行下沉到系统资源管理层级，Java运行平台不是最合适的。现在我们都知道处理数据最合适的方案是容器化管理，而Mesos就是当时这个先进的技术提出者。
处理大数据运算的多个组件，不使用依赖Java写成的Yarn等管理器，而使用系统原生级别的计算调度平台，这个思路无疑是对的。
那么，为什么Mesos在和K8S竞争中败北了呢？ 原因是Mesos重点聚焦在大数据计算，而K8S面对是整个软件世界！
K8S凭借Docker容器技术的成熟，抓住微服务技术迁移的浪潮，被所有的公有云接纳，提供了强劲的扩展支持。这几年抓住了天时，地利，人和几乎全部的有利条件。 K8S几乎已经达到操作系统的软件业地位。正在出现的一个技术趋势是，所有新发布的软件都带着“云原生”的帽子，适配并运行在容器之中。几乎所有操作系统，各种公有私有云，都逐渐得提供K8S运行环境。 当然，现在面对一个问题是，K8S还没有正式的LTS版，不过几个月前社区已经进行了开发者投票，预计很快就会出现。
所以说，K8S发行版，会成为下一个IT基础软件主战场。
IT基础软件主战场
目前除了官方的社区版，最成熟的就数红帽的Openshift了。红帽公司坐拥为数众多的K8S贡献者，庞大的Linux内核级别的开发者，从事多年的中间件，虚拟机技术专家。红帽在Openshift上投入巨大，也收获颇丰，目前用户数目和规模都是遥遥领先，也是IBM收购行动时看上重点资产。 不过Openshift社区版启用了新名字OKD，版本跳跃到4，而不再具有和上游的版本关联，以及Router，Project等私有概念的存在，会给使用者带来困扰，似乎埋下了一些隐患。 当年Linux商业化起步时，红帽公司就是不循迹当时Linux各社区的玩法，而用商业公司的节奏快速发展，我还记得当时各个Linux讨论组对RedHat Linux“邪恶性”的一致讨伐。 当然后来红帽证明开源操作系统江湖上需要一个带头大哥，技术和商业都不能少。不过换在今天，比红帽（甚至IBM）在互联网有影响力大公司的也有接近十位数之多。 我觉得K8S发行版发展道路上，还是会出现技术委员会这类的组织，CNCF已经做了一些工作。尽管委员会机制也有很多问题，但对K8S当前来说还是好处多多的。
此外，K8S发行版还有CoreOS(被红帽收购)的Tectonic，Rancher的K8S发行版，Docker公司称为K8S服务的DKS，Pivotal公司的PKS，以及Ubuntu背后公司的Canoncial K8S发行版等。软件巨头，如提供云服务的IBM，Oracle等都有K8S软件。当然，最需要关注的还是公有云提供的K8S服务了，国外的AWS，Azure，GKE，国内的阿里云，腾讯云，华为云已经在各个程度的支持。
其实可以憧憬一下容器技术普及后的美好。一条命令可以激活成千上万台机器节点，所有成熟的软件都有容器化镜像，每个用户使用自己的权限，通过修改配置项来激活软件实例。软件使用者无论是使用命令行还是网页界面来控制，都会面对各种计算能力模型。想要玩转的话，对容器技术的深入理解还是必要的。一个好用易用的界面，在行业内通过培训，应该是可以达到的。
除了容器化和微服务技术，无服务器应用Serverless也得到了的广泛关注和迅速普及，背后的原理就是快速启停的容器，用户可以不用预留的大量付费计算资源。 最容易想象的场景就是过年抢红包，秒杀等，瞬间的海量互联网流量涌入，使得平时购置的机器资源不能够撑住短时间的并发要求，那么很快的通过在新的节点启动实例来完成暂时性处理就成为最好的解决方案。另外像流式计算，日志分析图像处理等等也是典型无服务器应用适合的场景。
K8S生态之上，扩展出类似istio, knative等优秀项目，融合了网络代理，消息存储和转发，事件处理，版本管理，流量分发等常见软件模型，在系统“原生”的层面给出了软件开发和部署的方案。原有企业级软件也逐步向cloud native过渡，如软件构建，工作流，规则处理等各个方向。上述每个技术点都可以外延出一篇技术文章，有机会我再撰文论述。
Java作为具有完整生态的语言，在容器时代，面临最大的问题就是开发出的软件启动较慢，占用内存庞大，这些不是弱点而是设计原则导致的。 常驻内存即时响应的服务，和即时启动用完即扔的无服务程序的对比，Java在容器时代短板明显。 GraalVM项目可以帮助 Java进行系统原生改进，依赖定制的加载流程和编译成本地代码，大大提升了启动响应时间和内存使用指标。然而，Java应用如此处理，一是需要程序员知道如何改造应用，二是对Java语言来说是扬短避长，因为Java的最佳能力在于动态类加载和长时间提供服务啊。
那么我们再返回去设想，在一个典型的企业中，是否有必要完全使用微服务？是否有必要全面容器化？答案是：并不一定需要。 软件是为业务服务的，抛开业务来为了技术而选型，即所谓的“面向架构”编程，无疑是错误的。我听说有些行业用户号召全面上云，用公有云提供的技术框架和服务重写应用软件，只能遗憾的说这必然是一条充满坑洼和荆棘的道路。
容器化和K8S生态是非常好的方案，也是未来重点发展的方向。但如果业务规模有限，或者本企业技术人员资源不足，是否一定要把自家业务系统构建在一个庞大的技术架构之上？ Java和其他生态级的语言(比如.NET的C#)，完全可以构建出一个规模相对较小，但足够支撑起绝大多数业务软件的软件系统，比如经典的应用服务器，OSGi分布式应用框架，Hadoop大数据计算系统等等都是如此，它们目前一直是企业业务系统的主力。对于人数较少的开发和架构团队，对以上系统的掌控和精通相对要容易的多。
如果一个企业的主力开发者，还没有足够精力去弄懂如 JVM并发机制，Spring框架处理Web请求和事务原理，消息转发/存储技术原理等软件开发基础知识，而是投入大量时间去追逐云原生等所谓最新技术，我想是有些舍本逐末的，对软件开发知识体系的建立和经验积累会有负面影响的。
大胆预测一下： 基于容器技术的K8S会成为云计算的基础技术，随着K8S发行版广泛采用而无处不在。 而从局部来看，使用Java等语言开发的企业级分布系统，也会适应容器化部署，继续成为业务应用的主要运算平台。