1.3.2 多語言生態

微服務獨立之后，給了對應的團隊和組織快速迭代和交付的能力，同時，也給團隊和組織帶來了更多的靈活性，實際上，對應交付不同微服務的團隊或者組織來說，現在可以基于不同的計算機語言生態構建這些微服務，如圖1-2所示。

微服務的提供者既可以使用Java或者Go等靜態語言完成微服務的開發和交付，也可以使用Python或者Ruby等動態語言完成微服務的開發和交付，對于團隊內部擁有繁榮且有差異的語言文化來說，多語言生態下的微服務開發和交付將可以最大化的發揮團隊和組織內部各成員的優勢。當然，對于多語言生態下的微服務研發來說，有一點需要注意：為了讓服務的訪問者可以用統一的接口訪問所有這些用不同語言開發和交互的微服務，應該盡量統一微服務的服務接口和協議。

在微服務的生態下，互通性應該是需要重點關注的因素，沒有互通，不但服務的訪問者和用戶無法很好地使用這些微服務，微服務和微服務之間也無法相互信賴和互助，這將大大損耗微服務研發體系帶來的諸多好處，而多語言生態也會變成一種障礙和負累，而不是益處。

記得時任黑貓宅急便社長的小倉昌男在其所著的《黑貓宅急便的經營學》中提到一個故事，日本國鐵曾經采用不同于國際標準的集裝箱和鐵路規格，然后發現貨物的運輸效率很低，經過考察發現，原來是貨物從國際標準集裝箱卸載之后，在通過日本國鐵運輸之前，需要先拆箱，重新裝入日本國鐵規格的集裝箱，然后裝載到日本國鐵上進行運輸。但是，如果日本國鐵采用國際標準的集裝箱規格，那么貨物集裝箱從遠洋輪船上卸載之后就可以直接裝上國鐵，這將大大加快運輸效率（日本，國鐵改革后也證明確實如此）。日本國鐵在前期采用私有方案時，只關注了自己的利益和效率，舍棄了互通，也帶來了效率的低下。所以，在開發和交付微服務的時候，尤其是在多語言生態下開發和交付微服務，我們從一開始就要將互通性作為首要考慮因素，從而不會因為執迷于某些服務或者系統的單點效率而失去了整個微服務體系的整體效率。

圖1-2 多語言的微服務生態