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

http://newtech.club/2017/12/06/Java%E6%9C%AA%E6%9D%A5%E4%B9%9F%E8%AE%B8%E4%B8%8D%E5%86%8D%E6%98%AF%E7%94%B5%E5%95%86%E7%9A%84%E9%A6%96%E9%80%89%E5%BC%80%E5%8F%91%E8%AF%AD%E8%A8%80/#more