目錄

關於Servicemesh是什麼，能做什麼，此處不再進行贅述，相關文章已經非常之多。讀者可以自行上網查閱。Servicemesh是一個比較新的名詞，在2017年才逐步傳播開來。之前主要集中於各種雲服務的解決方案中使用。我們在開始闡述Servicemesh之前，先來系統地回顧下微服務的發展歷程，其更有助於我們對Servicemesh的瞭解。以下會根據我實際的經驗，以及一些方法論，來穿插推進論證整個發展歷程。

1.1 MVP階段

在初始階段，為了追求最高效率的快速試錯和產品迭代，幾乎所有的公司的技術架構最開始都是這麼演進過來的。從自身經歷來，舉幾個例子。

1. 百度鳳巢。百度廣告系統。主系統mercury，裡面集成了報表、廣告優化推薦、物料管理、歷史操作記錄、平臺產品等等一系列的鳳巢廣告庫核心業務功能，基於當時時下最流行的OSGI架構進行bundle化部署運維。這在一開始給我們帶來了很大的便利，包括快捷的開發速度，無需複雜的RPC服務治理，技術棧一致性的保障，但隨著業務規模的快速擴張，帶來的衝突同時也避無可避，如如何進行專案管理、程式碼分支管理、程式碼衝突解決、測試環境衝突、上線競爭、生產環境相互之間的影響，都嚴重影響了開發和生產效率。MVP於此也將結束他的歷史使命。
2. 丁丁租房。長期盤踞北京房租整租垂類Top1（後面被鏈家收回關停），2015年春節推出一炮而響，但是隨之而來的是各種源源不斷的技術負面新聞如APP莫名其妙崩潰，卡頓等等。2015年5月份時，主系統GMS裡面集成了經紀人管理、各角色帶看、交易、訂單、支付主邏輯。其帶來的便利，以及隨著業務增長帶來的問題和上面所述如出一轍，此處不復贅述。
3. 貓眼娛樂。貓眼電影作為電影線上票務Top1，在2013年至今，保持著快速的增長。但是同時其也經歷了同樣的過程。其也保持了剛開始All In One的快速迭代思想，主系統MovieSRV，集成了基本電影選座的所有功能，隨著業務發展，在2014年變形金剛4上映期間，由於流量過大，耦合業務之間相互影響，導致服務jetty資源耗盡，整體不可用數個小時。其帶來了巨大的損失。

以上例子，綜上所述來看，MVP在業務快速試錯迭代的初期，確實是需要以MVP方式來進行快速試錯，但業務快速增長和團隊規模的持續增大，必然會直接帶來MVP模式所產生的所有惡果，歷史總是驚人的相似，而我們能夠做的事情有哪些呢？

1.2 微服務

當All In One的模式進行不下去的時候，暴力美學告訴我們，那就拆。於是，我們水平拆分、垂直拆分、領域驅動、單一職責服務，越來越細，而我認為所謂微服務，即越拆越細的服務化架構，及與此匹配的基礎設施能力的構建。

百度鳳巢也不例外，拋棄了沉重的OSGI框架，由ClassLoader級別的隔離轉向了物理隔離，自研類Dubbo的服務治理框架Stargate，全面擁抱微服務，拆分出了廣告核心、賬戶優化、報表、平臺、歷史操作記錄。

丁丁租房進行了“藍蓮花”專案的全面重構，進行了經紀人、聯絡、人、房、交易、支付等模組的全面服務化，並進行了基礎設施的全面自建如Smart-Codis、API Gateway、私有云等。

貓眼娛樂則在變4事故之後，展開了“帝國餘暉”專案，進行了訂單、支付、券、活動、交易、價格、會員卡等系統的全面拆分服務化。

微服務伴隨著越拆越細的程序，且與之帶來的運維和整體系統上把控的難度也指數級上升，我們能否handle住以及如何handle住這樣的變化呢？

1.3 後微服務時代

隨著服務化不斷深入，服務拆分不斷細化，我們面臨著非常複雜的服務拓撲的場景下，如何進行服務治理，即進行分散式服務呼叫、鏈路追蹤、流控、鑑權、熔斷、隔離、降級、監控報警，以及完善與之配套的運維能力呢？服務治理是一個環，其正向治理和逆向反饋的能力隨著服務規模的不斷膨脹，其帶來的心智成本和運維成本將會在某個臨界點呈爆發式地增長，而我們不得不為其付出昂貴地代價。

那，我們應該怎麼辦呢？微服務的方法論有很多，此處我先丟擲三個方法論，其側面印證了微服務後續的演進路線，而實際上，微服務確實是在這麼演進的。

1.3.1 虛擬化，標準化，產品化

只有進行虛擬化，才能將複雜異構層出不窮的問題標準化，只有進行了標準化，我們才能將功能產品化，只有產品化，我們才能確保我們功能的可持續健康發展。

虛擬化，標準化和產品化，其實一直是貫穿整個現代網際網路體系架構的全過程。DNS虛擬化了IP和負載策略的細節，四層七層負載虛擬化了服務端的細節，訪問快取常用的一致性雜湊環虛擬節點也用了虛擬化來規避雪崩等複雜場景，我們的分散式服務呼叫虛擬化了Provider叢集的細節，我們訪問資料庫利用中介軟體虛擬化了讀寫分離和分庫分表邏輯，甚至你可以認為你的幾十種設計模式，說到底都是在進行虛擬化你的各種異構實現。虛擬化是一切之基石，它其實在我們的潛意識中如此根深蒂固以至於我們都以為理所應當。

1.3.2 程式包含環境，而非剝離環境

我們一點點來分析，微服務基礎設施的一個非常重要的癥結其實在環境與程式的剝離。怎麼說？環境與程式剝離，會帶來大量的問題，比如

1. dev、test、stage、product環境和程式不一致可能會引發測試沒問題，上線就出問題的各種詭異場景，追查到最後可能就是一個環境變數、目錄許可權、機器配置檔案地址差異等原因所導致的。
2. 一些基礎設施不可避免的需要在機器上部署一些指令碼、agent，比如zabbix，比如sidecar，如果將這些指令碼、agent在機器初始化階段通過pxe、ansible、puppet等工具進行安裝，而等到服務真正要使用的時候，這個時間差的週期裡面可能會由於升級等原因導致不一致的情況發生，在兩個非常大的時間跨度（機器上架初始化與服務上線）裡去完成兩件緊密耦合的事情，其也客觀上增大了微服務基礎設施運維和研發協作的成本。
3. 你這個程式需要JDK1.7的支援才能啟起來，怎麼傳達這個資訊給運維，口頭，文件？釋出系統勾選一下選項？如果是其他的依賴呢比如ImageMagic？以後如何始終確保繼任者清晰認識這個前置條件？

所以，我們可以明顯地看出來，無論是業務程式還是基礎設施程式，我們都需要讓程式囊括環境去結合考慮，而不是如傳統的做法一樣，剝離環境與程式。我們應該意識到，環境和程式是一體的，缺少任意一方，功能將不再完整。

1.3.3 少慣“寵物”，多養“奶牛”，權衡而非對抗

你有一隻寵物，也有一隻奶牛，寵物生病了，你很著急地想要治好它，而奶牛生病了，你就殺了它賣掉。pets-vs-cattle理論其實在於一個權衡，也側面提醒我們，越少不可代替的服務，你的服務就越可控。最理想情況下，我們希望一切都快速失敗重頭再來，沒有什麼是不可替代的。對於服務，我們可以採用一些更直接的災備方案，比如快速切換，比如分流限流等手段，來保障我們可以快速重啟，並儘可能做少流量損失，而不是寄希望於其永遠不掛，因為這是不可能的。

pets-vs-cattle理論的提出是希望我們不要對服務分三六九等來增加服務運維管理的複雜度，其本身也無可厚非，但這麼做有點“大躍進”之嫌，我們還是應該秉持更加客觀可落地的方案去推進，適當進行權衡，而不是一味否定或激進地肯定。大方向是沒有問題的，少慣些“寵物”，多養些“奶牛”

基於以上方法論，下一代的微服務也便呼之欲出了。（未完待續）