上周我參加了在南京舉辦的IAS的架構師峰會，和很多同行溝通，特別是和當當網的首席架構師張亮做了一個結對的分享 —《技術架構演變全景圖—從單體式到云原生》，分享的形式很特殊，采用了一問一答的方式，我作為提問題的，不斷“刁難”張亮，張亮一一解答問題，一番“交鋒”后，聽眾有反饋效果不錯，我自己也收獲了不少。

最重要的一點體會是Java未來也許不再是一個電商首選語言了。當然在互聯網其他領域，Java早就不是首選了，開發繁瑣，包體積大、運行時開銷大等等，似乎不適合互聯網創業。但對于互聯網電商來說，前有阿里、京東全線轉型Java技術棧的案例，后有餓了么這樣的新興電商也慢慢的從Python轉向Java，示范作用很強。于是，整體是Java架構成了我們這樣的電商軟件提供商的產品賣點之一。

[[213057]]

我認為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這樣的風口機會。

未來怎么樣，讓我們拭目以待。

版權說明：本文采用CC BY 3.0 CN協議進行許可。