Java社区的新方向

发表于 更新于 分类于

Java 作为一个不怎么年轻的语言，从 JDK9 开始加速进化，颇有老树焕新芽的风采。语言上 类型自动推动 No-Op Garbage Collector JEP 321: HTTP Client 也算是非常的务实了。但是除了语言本身更重要的是社区建设，站在 2020 的时间节点上，我们看看未来社区的几个新方向。

去JVM化

为啥要去 JVM，这事情这事情就让我给大家掰扯掰扯。Java社区 在他所诞生的时代为了解决不同操作系统之间的隔离屏障，做了一个很重的实现，其名曰为 虚拟机，在 90 年代虚拟机技术给广大的开发者解决非常多跨系统不一致的问题，但是在现在这个节点，虚拟机技术慢慢的正在变的鸡肋起来，原因有三（从国内的角度看）：

  1. 服务器技术统一化：国内的大厂和小厂都在积极的 Linux 化，指令集也是 x86 为主，Jvm跨平台的特性的基石正在消失。
  2. 云原生的冲击：CNCF社区带着Go走来，交叉编译能解决 90% 的问题，还没有臃肿的镜像问题，更云原生了。
  3. 资源消耗 & 产品规模：JVM 有一个消耗资源的基础线，包括每次 malloc 都会消耗更多的资源，以前做的都是大型应用（单体，巨石），现在随着微服务的发展，JVM 的性能诟病又重新摆到了桌子上。

因此随着行业的发展，语言也需要适应发展，现在大家需要的是 易开发 资源消耗低 云原生 的编程语言(框架)，因此一个行业新星正在冉冉升起 GraalVM，基于 Java 语言本身将 Bytcode 转化为 NativeCode。

ServiceMesh化

这个其实不能算是社区的变化，不过因为这个特性会导致整个研发体系发生剧变，就单独拿出来说说。

Mesh 也是分时代的，对于 Isito 这样的组件，我认为还是 v1.0 的时代，此时我们注重的是网络流量的走向问题，从而来解决比如灰度发布之类的问题，并且基于这些能力做一些 流控 请求安全 的功能。
但是慢慢的社区迈入 v2.0 时代，因为在之前的模式中，我们没有对应用进行任何修改。但是在 v2.0 时期，我们需要做的是真正的 ServiceMesh。

NGjejx.png

未来我们会在应用之间增加一层 Mesh 层，那好奇的朋友肯定会问，这个和以前的中间件有啥区别？这里的区别可大了，举一个例子：

比如你在企业内部提供的内部接口能力，当你第一次交付出去的时候是 v1 版本，当你需要发新版的时候你发布了 v2 版本。但是你不知道谁用了你的 v1 版本，你只能让其继续维护下去，而在 Mesh 时代，你可以在不修应用的情况下，就直接将所有v1版本请求进行一点点修正，再让其把所有的流量转移到 v2 上，这样你再也不需要维护2个不同的版本了。

伴随着 Mesh 技术的普及，慢慢的我们会发现，我们对中间件和应用都提出了新的理念，规范应用开发体系，桂发中间件提供的API规范，将所有的技术层都放置于 Mesh 中。

cool

而这一切社区也在积极的推动，比如 Macha 理论等
NGOEa4.png

框架轻量级化

因为未来的趋势是 Mesh 话，原本 Spring Cloud Spring Sercuirty 的能力都慢慢的沉淀到中间层，因为 Java 现在的臃肿，可能并不适合中间层，未来可能还是会长时间的在 Biz 层，而在 Biz 我们需要的显然是 轻量级 业务友好型 的框架，如果能高性能就更好了。

不过社区在这方面已经有了一些成果：

  • Vertx : 一个性能至上的框架系列。
  • Micronaut: 非常友好的微服务框架

包括之前的 SparkWeb 之类，都可能在未来焕发第二春，Java并不是一个啰嗦的语言，但是惯用法在 Spring 时代已经被约定，但是面对 Go 系列的冲击，也不得不进行转换。

参考