先把平臺做扎實，再來微服務吧

微服務已經成為當下最熱門的話題之一。它是一種新的架構風格，涉及組織架構、設計、交付、運維等方面的變革，核心目標是為了解決系統的交付周期，并降低維護成本和研發成本。相比傳統的SOA架構或者單塊架構，微服務有很多的優勢，比如技術的多樣性、模塊化、獨立部署等，但也帶來了相應的成本，比如運維成本、服務管理成本等。

網上有很多討論微服務優缺點的文章，而在這個新的東西面前，很多企業不知道如何抉擇。那傳統的架構有什么挑戰？微服務可以為企業帶來什么？切換到微服務架構之前，需要做出哪些準備？10月16日，在 QCon上海全球軟件架構師大會 上，InfoQ組織了一場閉門會議，深入討論和交流了微服務相關的問題。阿里巴巴、大眾點評、唯品會、華為、普元、中國移動、點融等公司的代表參與了此次討論，本文根據會議中的精彩觀點整理而成。

傳統架構面臨的挑戰

1. 穩定性。很多公司都是從零開始構建自己的系統的，一開始，為了盡快的實現業務，所以系統的架構也相對比較簡單。但當業務和用戶量開始大規模增長之后，反過來又對系統的性能和穩定性有較高的要求。而傳統的單體式（本文均指 monolithic）應用把所有的服務都堆到一起，可能會由于一些不重要的服務出問題而影響系統的核心服務。另外，系統對服務的要求也不一樣，分開部署可以減小它們之間的相互影響。

2. 可維護性。移動的系統是從2001年開始做的，到現在已經十多年了，這么多年，核心的系統一直是在完善、堆疊。而經過這么多年的維護，系統代碼的可維護性非常差，開發人員和技術都已經迭代過幾波，系統中代碼之間的調用也很多，不是很了解系統的人也不敢輕易動。而由于系統的代碼非常多，所以了解系統也不是一件容易的事情。

3. API的版本迭代。單體應用中，一個系統會對應出很多的API，而根據業務的不斷迭代，肯定會衍生出很多版本的API，特別是現在很多系統都有不同的端（手機、網站）。API的升級和維護都需要有相應版本的管理，而單體式的應用在這一塊，有明顯的短板。另外，API的發布周期也會很慢，因為版本的發布涉及到整體的協調和測試。

4. 持續集成。單體式的應用由于比較大，應用內部的依賴非常多，涉及的業務邏輯也比較復雜。在CI流程中，如果沒有很好的約定的話，失敗的次數也會比較多。另外，由于代碼基比較大，所以構建的時間也會非常長，如果構建錯誤，排查問題也會比較困難。

對微服務的理解

1. 微服務的概念里，有兩個重點，快速發布和解耦。這兩點都可以和OO中的架構設計原則相對應，一個是單一職責（single responsibility），也就是把一件事情做好，一個是關注分離（Separation of concerns）。康威定律說：設計系統的組織，最終產生的設計等同于組織之內、之間的溝通結構。對應到這里，也就是說微服務和公司的組織架構有非常緊密的關系。另外，很多公司都已經是微服務了，只是他們沒有提，比如亞馬遜、阿里巴巴。像他們這么大的公司，沒有微服務根本玩不轉。

2. 微服務革新了軟件的生產過程，包括開發、測試和部署各個階段。但服務的切分并不是要遵守單一原則，因為未來的服務不可能完全垂直切分。從另外一個角度看，微服務的過程其實也是工業化的工程，每個微服務都是生產線上的一個零件，但要注意，零件的組裝和拼接難度更大，所以在談論微服務時一定要注意，它是需要一個大平臺支撐的。

3. 首先微服務并不是指代碼本身，它包括從代碼開發到部署到運維這一系列的工作流程。其次，談到服務拆分，需要注意的是服務的SLA（Service-Level Agreement）是不一樣的，拆分時需要考慮到哪些是一級服務，哪些是二級服務。最底層的服務直接決定了上層服務的穩定性。

4. 服務化說白了是組件化的一種形式，所有的組件都來源于重構。流程是從上往下寫的，寫到一定程度時，就會遇到分離、解耦的問題，然后就是組件化，這時才會出現重構。不要上來就追時髦，服務化沒有價值。

5. 如康威定律所說，系統架構和團隊的組織架構有直接的關系。但并不是說為了微服務而調整組織架構，一般是考慮到業務的需求才調整團隊組織架構。微服務的團隊推薦是7個人左右，這也是Netflix的最佳實踐。另外，團隊與團隊之間不要有太多依賴。中小型的創業公司不推薦使用微服務，因為開銷成本很高，對平臺的要求也很高。微服務涉及到你是否能有快速提供環境的能力、文化的改變、快速部署、監控等多方面的能力，當這些條件都具備之后，再考慮是否要微服務。

服務治理

1. 服務治理這塊，根據經驗，有三個需要注意的。一是接口的統一性，當公司發展到幾百人的時候，如果沒有接口規范，那效率馬上就會下降。之前可以像游擊隊一樣打，但人多了之后，還是像正規軍一樣戰斗力會比較強。二是容錯一定要做好，這塊可以參考Netflix開源的幾個組件。容錯如果沒有做好，在服務化這樣的系統里，很可能會造成雪崩效應。容錯的方案也有很多，比如限流、回退、隔離、熔斷。三是監控，在微服務出錯之后，團隊需要快速定位出錯的位置和原因。

2. 服務治理這塊，阿里巴巴有個不錯的框架 Dubbo ，已經開源。拋開服務治理不說，我來舉個服務化的反例，非死book內部是反服務化的。非死book所有的代碼只有兩個庫，并且所有的發布都是同時進行的，每個機器都一模一樣。所以非死book可以做到零運維，并且服務根本沒有版本的概念。阿里巴巴現在的服務也準備往回收，在沒有服務和過多的服務之間找到一個平衡點。

3. 服務方需要知道服務會被多少人調用，被哪些業務調用，每個時間點上的狀態是怎么樣的。一個經驗是為每個服務都起一個名字，當出現問題時，可以快速定位到。另外，阿里的eagleye和點評的CAT監控系統，支持對服務調用鏈和依賴關系進行可視化監控，可以參考學習。

4. 微服務中，服務的測試是一個非常大的挑戰。服務和服務之間會存在依賴，所以環境的搭建可能就會涉及到多個團隊，這個時候就需要能快速部署環境，當然現在比較推薦的方案是容器。

5. 微服務，其實對應的應該是微業務，是為了適應業務的多變／面向最終用戶的個性化需求。而微服務的力度，很大程度上是取決于完成一項業務所要設計的數據存儲所在的區域。微服務的監控，和原來的服務監控力度應該是類似的，包括業務、應用、系統多個層次，日志、Metrics、調用鏈、告警等多個維度。

6. 提到監控，大家一般都是從系統、應用等層面去考慮。我這里拋一個思路給大家：輿情監控。很多時候，當系統出問題的時候，我們并不是在監控那里得到消息，二是從微博、微信等渠道中收到用戶反饋（XX系統真垃圾，又掛了之類…..）。我們努力了幾年了，就是想讓我們的監控系統能在輿論之前監測到系統的異常狀態，但很難，所以現在我們也在重點考慮輿情監控。