Java未来也许不再是电商的首选开发语言 - 转载
好久没更新博客了，很多人催促我更新，最近因为公司的事情一直是忙（其实是懒病发作），特别是被推广了一波后，再不更对不起读者了。
上周我参加了在南京举办的IAS的架构师峰会，和很多同行沟通，特别是和当当网的首席架构师张亮做了一个结对的分享 —《技术架构演变全景图—从单体式到云原生》，分享的形式很特殊，采用了一问一答的方式，我作为提问题的，不断“***难”张亮，张亮一一解答问题，一番“交锋”后，听众有反馈效果不错，我自己也收获了不少。
最重要的一点体会是Java未来也许不再是一个电商首选语言了。当然在互联网其他领域，Java早就不是首选了，开发繁琐，包体积大、运行时开销大等等，都不适合互联网创业。但是对于互联网电商来说，前面有阿里、京东全线转型Java技术栈的案例，后面像饿了么这样的新兴电商也慢慢的从Python转向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的开发体验依然不错，但是未来的标准不一定是开发者引导的，运维可能会制定所谓的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这样的风口机会。
未来怎么样，我们拭目以待。
ref
