话说Java被淘汰是否太早

2017-12-12 21:49:42 济南网站建设 0

上周我参加了在南京举办的IAS的架构师峰会,和很多同行沟通,特别是和当当网的首席架构师张亮做了一个结对的分享 —《技术架构演变全景图—从单体式到云原生》,分享的形式很特殊,采用了一问一答的方式,我作为提问题的,不断“刁难”张亮,张亮一一解答问题,一番“交锋”后,听众有反馈效果不错,我自己也收获了不少。

最重要的一点体会是Java未来也许不再是一个电商首选语言了。当然在互联网其他领域,Java早就不是首选了,开发繁琐,包体积大、运行时开销大等等,似乎不适合互联网创业。但对于互联网电商来说,前有阿里、京东全线转型Java技术栈的案例,后有饿了么这样的新兴电商也慢慢的从Python转向Java,示范作用很强。于是,整体是Java架构成了我们这样的电商软件提供商的产品卖点之一。

Java未来也许不再是电商的首选开发语言!

我认为Java的卖点主要是JVM运行时强大、工具链成熟,以Spring为首的庞大的生态提供了完善的开发体验。特别是在满足电商的双十一高并发、大容量场景下,有dubbo、Spring Cloud这样的服务治理框架,不管是Go、Python、Php,都没有类似的框架可以对比,其他开发语言想追上这样的生态环境不是一件简单的事情, 可以说对于目前电商公司来看,Java技术栈是不二的选择。但是正像三体中的降维打击概念,打败你的人不是你同维度的,而是来自其他的领域。Service Mesh(服务网格),这个来自底层云平台基础设施正在向上入侵原有的开发框架的领域。

说起来Service Mesh不是新概念了,在之前就有运维维护nginx的配置,做服务之间的调用代理,但是这个是很原始的状态。目前随着k8s在运维层面一统江山,基于k8s的linkerd、envoy、Istio一系列Service Mesh解决方案发展非常迅速,Willian Morgan(linkerd的CEO)给出Service Mesh定义:

— 服务网格是一个基础设施层,用于处理服务间通讯。云原生应用有着复杂的服务拓扑,服务网格负责在这些拓扑中实现请求的可靠传递。在实践中,服务网格同程实现为一组轻量级的网络代理,它们于应用程序部署在一起,而对应用程序透明。

对应用程序透明这几个字要画重点,说明以后再也不需要在开发层面关注负载均衡、路由、熔断、限流、服务注册发现、分布式跟踪等等一系列的服务治理内容了,这些都由我们的运行底层设施来完成了。类似网络七层OSI架构定义,我们做上层开发的不需要了解TCP、HTTP具体的协议,而聚焦到我关注的业务逻辑本身,这种情况很快会在微服务领域再次发生。下图预测了在2018年,哪些技术栈可能由于Service Mesh的发展而被抛弃掉。

Java未来也许不再是电商的首选开发语言!

在这种情况下Java引以为傲的框架都无用武之地了,虽然Java的开发体验依然不错,但是未来的标准不一定是开发者引导的,运维可能会制定所谓的Cloud Native标准,要求满足标准的,才能上平台进行运行和调度。多语言在Service Mesh中一视同仁,我们很可能用Go来开发网络服务,用Php来做Web,用Node来做网关API,用Java做业务逻辑,服务之间的通讯就交给Service Mesh来统一处理,而整个庞大的微服务体系交由k8s这样的平台来调度和编排。

好一幅蓝图,也许我们还觉得可能有点遥远--Istio才0.3版本,等它到了1.0再说,不过互联网技术迭代极快,而且Istio系出名门,发展势头不可小视,大有席卷天下的感觉。这样的变革对新兴的语言Go之类的是极大的利好,但是对Java并不是好事。特别对于我这样2003年接触Java的老程序员说,对Java是有特殊感情的,难道我们真的要见证一个时代的结束了么?

我觉得Java要发展下去,还是有机会的:

  • 在开发体验、工程化方面要继续强化。Java8+Spring boot+Lombok使用体验经常让我感觉不到在写繁琐的Java。

  • 微服务的领域驱动设计特别重要,而在领域驱动设计实现中Java是主流,目前还没有太好的替代语言。

  • 强化目前的JVM上的语言生态,包括Kotlin、Scala等,也许会有下一个杀手应用出现,抓住类似AI这样的风口机会。

未来怎么样,让我们拭目以待。