上周参加了在南京举办的IAS建筑师峰会，和很多同行进行了交流。特别是和当当网总架构师张亮做了一次结对分享——《技术架构演变全景图—从单体式到云原生》，分享的形式很特别，采用的是一问一答的方式。作为提问者，我一直“刁难”张亮，张亮一一作答。.最重要的一点是，未来Java可能不再是电子商务的首选语言。当然，在互联网的其他领域，Java早已不是首选。开发繁琐，包体积大，运行时开销大等等，似乎不太适合互联网创业。但对于互联网电商，已有阿里巴巴、京东全线改造Java技术栈的案例，饿了么等新兴电商也在慢慢从Python转向Java，具有很强的示范作用.因此，整体的Java架构成为了像我们这样的电商软件商的卖点之一。我认为Java的卖点主要是强大的JVM运行时和成熟的工具链，以Spring为首的庞大生态系统提供了完整的开发体验。尤其是满足电商的双十一高并发大容量场景，有dubbo、SpringCloud等服务治理框架。不管是Go、Python还是Php，都没有类似的框架可以比较。其他开发语言想要迎头赶上。建设这样的生态环境不是一件简单的事情。可以说，对于现在的电商企业来说，Java技术栈是最好的选择。但就像三体中的降维打击概念一样，打败你的人并不是和你同次元的，而是来自其他领域的。ServiceMesh（服务网格），这个来自底层云平台基础设施的领域正在侵入原有的开发框架。说起来，ServiceMesh并不是一个新概念。之前有运维nginx配置来充当服务之间的调用代理，但这是非常原始的状态。目前，随着k8s在运维层面一统天下，基于k8s的linkerd、envoy、Istio等一系列ServiceMesh解决方案发展非常迅速。WilliamMorgan（linkerd的CEO）给出了ServiceMesh的定义：——ServiceMesh是一个基础设施层，它处理服务间的通信。云原生应用具有复杂的服务拓扑，服务网格负责在这些拓扑中可靠地传递请求。在实践中，服务网格被实现为一组轻量级网络代理，它们与应用程序一起部署，并且对应用程序是透明的。突出“对应用程序透明”的字样，表示无需关注负载均衡、路由、熔断、限流、服务注册发现、分布式跟踪等一系列服务治理内容。未来的发展水平。这一切都是由我们运行的基础设施完成的。类似于网络七层OSI架构的定义，我们上层开发不需要去了解TCP和HTTP具体的协议，而是关注我所关心的业务逻辑本身。这种情况很快就会在微服务领域再次发生。下图预测了2018年哪些技术栈可能会因为ServiceMesh的发展而被抛弃，在这种情况下，Java引以为豪的框架就没有用了。虽然Java的开发体验还是不错的，但是未来的标准不一定是开发者主导的。运维方面可能会制定所谓的CloudNative标准，要求只有符合标准的才能在平台上运行和调度。多语言在ServiceMesh中一视同仁。我们很可能会用Go来开发网络服务，用Php来做Web，用Node来做网关API，用Java来做业务逻辑。服务之间的通信交由ServiceMesh统一处理，整个庞大的微服务体系由k8s等平台进行调度编排。多么美好的蓝图，也许我们还是觉得可能有点远——Istio现在才0.3版本，等到1.0的时候再说吧。但是，互联网技术迭代速度极快，Istio更是家喻户晓。发展势头不容小觑，有种席卷全球的感觉。这样的改变对于Go这样的新兴语言来说是大有裨益的，但是对于Java来说就不是什么好事了。尤其是像我这样2003年接触Java的老程序员，对Java有着特殊的感情。我们真的要见证一个时代的终结吗？我觉得Java还有继续发展的机会：在开发经验和工程方面，我们要继续加强。Java8+Springboot+Lombok的使用体验，常常让我觉得自己不是在写繁琐的Java。微服务的领域驱动设计尤为重要，而Java是领域驱动设计实现的主流，目前还没有很好的替代语言。加强目前JVM上的语言生态，包括Kotlin、Scala等，说不定下一个杀手级应用就会出现，像AI一样抢占先机。未来如何，让我们拭目以待。版权说明：本文采用CCBY3.0CN协议授权。
