http://www.primeton.com/read.php?id=2276&his=1

一、微服務架構產生的背景

近十年中，互聯網給我們生活帶來了翻天覆地的變化，消費者的生活方式日益數字化，人們可以在任何時間、任何地點利用網絡進行購物體驗，運用社交媒體進行自我表達，企業也在運用多種技術手段，發揮數字化潛力，改善客戶聯系，促進企業業務模式的轉型。在這種背景下，互聯網也好，傳統企業也罷，都面臨一個共同的需求：面對快速變化的需求，面對業務模式的升級，如何構建出靈活的，可擴展，可重用的系統？

前幾年我們常用的三層應用架構，經常會將系統落地成單塊應用，所有的功能都運行在一個進程中，各個模塊之間的功能是強依賴的，修改一個模塊的功能很容易導致其他模塊出現問題，而且一旦需要將系統發布必須做一次全量發布，發布周期長。如果團隊中加入新人，對系統的學習成本也很高，需要了解完整個系統才能進行開發。在這種情況下，如何將系統進行拆分，使得各個模塊獨立衍化成為關鍵。

近幾年隨著容器技術的發展，其中以docker容器技術為代表，一時間席卷了整個IT行業，受到大量開發者和企業熱烈追棒。docker容器技術以一種輕量級的方式可以非常方便的將應用及其依賴打包到一起，然後可以發布到任意裝有docker的Linux機器上面。docker的出現，有效的解決了大量服務因數量眾多而導致的開發環境搭建、部署復雜及運維成本高的難題。

在這種背景下，如果說隨著敏捷、精益方法論深入人心，持續交付以及Devops逐漸火熱促進了微服務架構出現，那麽Docker容器技術的出現，解決了部署，運維困難的問題後，則直接為微服務架構的大規模應用起到了推波助瀾的關鍵作用。

雖然微服務架構能讓每個單一的服務進行獨立的衍化，能獲得諸多好處，但是微服務並不是銀彈，實施微服務架構同時也會帶來其他問題，如集成復雜，運維困難，服務間依賴測試，服務間依賴管理等一系列新問題。如在在微服務架構中，每個服務間彼此獨立，一個服務可能需要依賴另一個服務，而此時另一個服務也正處在開發中，則無法進行依賴，此時就需要對服務進行mock，方便服務間依賴測試；又比如在運行期，某個微服務A運行較慢，則所有依賴服務A的其他服務都會受到影響等等；像這樣的問題，在微服務架構中還有很多，這裏不一一舉例。

二、微服務框架落地的7個關鍵點

在微服務架構中，針對微服務架構需要解決的一系列問題，我們將一些基本的問題進行抽象，統一解決，獨立出一套基礎的框架，方便快速實施微服務架構，以下是我們微服務框架的一些基本能力：

在上圖中，我們將微服務框架的基本能力分為2部分，第一部分是基礎能力，這部分能力並不是微服務特有的，是很多系統都需要的一些基礎能力，這裏主要是日誌，異常，文檔等；第二部分是微服務框架的核心能力，主要解決微服務架構中的一些基本問題：如負載均衡、RPC、服務註冊與發現等。在微服務框架基礎之上，就是業務邏輯，即真正對外提供的業務服務，目前所有的業務邏輯對外暴露的服務統一都是restful服務。下面我們主要講述微服務框架落地的7個關鍵點，供大家在落地微服務架構的時候進行參考：

RPC：服務通訊的基礎。無論是SOA還是微服務，核心都是RPC框架。如果沒有統一的RPC框架，各個團隊就需要實現自己的一套序列化、反序列化、網絡框架、連接池，線程池、超時處理等“業務之外”的重復勞動，所以統一RPC框架，是服務化首先要解決的問題。現階段，外界RPC框架眾多，如果沒有特殊需求，並不需要自研一套。

目前可選的RPC框架有：dubbo/dubbox，motan，thrift，grpc，Karyon/Ribbon, 在RPC框架的選擇上，我們選擇了比較輕量級的motan開源框架，理由是“麻雀雖小，五臟俱全“，足夠輕量級，卻解決了RPC需要解決的大部分問題，如負載均衡、容錯、服務註冊與發現、限流、降級等。

motan相比於dubbo更簡單，也更輕量級，學習成本更低，卻包含了dubbo大部分能力；thrift和grpc則註重於解決跨語言調用問題，並沒有解決負載均衡、服務註冊與發現等基本問題。

karyon/ribbon則無法直接單獨使用，需要配合Eureka才能一起使用，過於復雜。RPC框架都有一個通用的問題，很難直接對服務端進行測試，由於RPC傳輸二進制數據，這個數據難以手動構造，直接造成測試復雜，集成復雜。

於是，我們在開源框架的基礎之上進行了擴展和重構，為了使RPC框架支持restful，我們將序列化層和Transport層進行了改造，將序列化層的序列化方式改成了json(rest)，Transport層將netty換成了http client+tomcat，之所以需要將netty換成tomcat的原因是因為我們需要一個servlet容器，netty不是一個servlet容器。

當然，將二進制數據改成json後，性能會有損耗，但是性能並不是我們追求的唯一目標，我們系統並不直接面向用戶，更多的是企業用戶，所以開發效率，研發成本等問題考慮多一些。以下是我們改造前後motan架構對比：

RESTFul：輕量級通訊的首選方式。在微服務架構下，推崇采用輕量級的方式進行通訊，我們選擇RESTFul進行通訊，每個微服務都統一對外暴露RESTFul服務，無論是前端調用後端服務，還是後端服務間的調用，都統一走RESTFul，這樣統一了協議棧；同時還可以非常方便的進行服務的mock，只需要模擬RESTFul請求就可以了，服務間依賴測試難度大大降低，極大的提高了開發人員開發微服務、測試人員測試微服務、集成微服務的效率。依賴於輕量級的RESTFul，在微服務架構中，引入非java語言也是可行的。以下是我們微服務架構中RESTFul通訊的示意圖：

服務註冊與發現：微服務架構由一組獨立的微服務組成，這些微服務之間如何才能發現彼此？這就要求微服務之間存在一種發現機制，目前我們通過服務註冊與發現來讓微服務可以感知彼此，微服務框架在啟動的時候，將自己的信息註冊到註冊中心，同時從註冊中心訂閱自己需要引用的服務。更多服務註冊與發現內容，請移步至《微服務架構實踐：服務註冊與發現中負載方案選型》（點擊標題即可閱讀）。以下是我們基於etcd+motan實現服務註冊與發現的架構示意圖：

負載均衡和容錯：服務高可用的重要手段。為了保證微服務的高可用，每個微服務一般會有多個實例服務提供服務，此時需要客戶端在進行服務的負載均衡；目前微服務框架中，現支持常見的負載均衡策略，如隨機，輪訓，hash，權重，連接數，缺省是根據連接數，連接數越少，優先級越高。在調用服務集群的時候，如果一個微服務調用異常，如超時，或者發生連接異常，網絡異常，則根據容錯策略進行服務容錯，目前我們采用簡單的Failover，即選擇下一個可用的服務進行調用，目前支持的容錯策略有快速失敗、失效切換。如果連續失敗多次，則需要直接熔斷，不再發起調用，這樣可以防止一個服務異常拖垮所有依賴它的服務；在熔斷這個地方，目前我們做的比較簡單，采用簡單的策略避免服務不可用，後續會考慮將Netflix 的Hystrix引入到我們的微服務框架中。

限流和降級：保證核心服務的穩定性。為了保證核心系統穩定性，隨著訪問量的增加，我們設置了一個系統能夠處理的極限閥值，超過這個閥值的請求則直接拒絕。同時，為了保證某些核心服務可用，需要對某些非核心業務進行降級。目前我們通過限制每個服務的最大訪問量進行限流控制，降級則通過管理控制臺對單個服務進行人工降級。以下是服務容錯、熔斷、限流的示意圖：

權限驗證：保障系統的安全。微服務架構推薦以輕量級的通訊機制，我們選擇了http+json進行通訊，這種通訊方式很容易被偽造，因此需要某種機制保證微服務的安全，目前我們通過token機制保證微服務的安全。用戶在登錄的時候會頒發給用戶一個token，用戶每次訪問平臺的時候，需要傳遞此token，後臺校驗此token的合法性，如果合法則可以訪問，如果沒有token或者token不合法，則禁止訪問。

日誌是分析問題，定位問題的關鍵。在微服務架構中，一個客戶端請求的接入，往往涉及到後端一系列服務的調用，如何將這些請求串聯起來？業界常用的方案是采用全局流水號串聯起來。我們也不例外。通過全局流水號，從日誌裏面可以拉出整條調用鏈路。目前我們對不同的日誌進行不同的分類，每種不同的日誌分類都有固定的格式，方便進行統一監控。目前我們分了系統日誌：記錄系統運行的整體情況，系統調用邊界情況；審計日誌：用於安全審計；跟蹤日誌：開發人員進行調試，定位問題的日誌。在微服務框架中，所有的系統調用邊界、請求接入接出邊界，都存在統一的日誌埋點，這些日誌埋點和監控系統對接，可以方便的查看系統的運行各項指標，同時也可以根據日誌跟蹤到一個服務從前到後的整個調用鏈路。

在實施微服務架構中，以上7個關鍵點是我們微服務框架主要解決的問題：RPC做為微服務架構中通訊的基礎，選擇RESTFul做為微服務架構中的輕量級通訊機制、統一協議棧，微服務之間的服務發現與註冊，容錯和負載均衡保證服務的高可用，限流和降級保證核心服務的穩定性，系統的安全及全鏈路日誌跟蹤；當然還有其他的一些問題需要關註，不在這一一展開，大家在微服務架構落地的過程中也可以參考圖1中其他的一些關註點。

三、根據企業自身的業務特點，

能落地的微服務架構就是最佳實踐

在微服務的浪潮下，大量的新概念不斷湧出，新的開源框架不斷增多，如何根據企業自身的業務特點，合理的運用開源技術落地微服務架構成為關鍵。微服務概念提出已久，但卻一直缺乏最佳實踐，筆者認為，在實施微服務架構的過程中，結合企業自身業務特點落地的微服務架構即是最佳實踐。我們在落地的微服務架構中，也選擇了一系列的開源框架，我們根據自己的業務特點，將開源框架進行重構、擴展，形成一套我們自己內部的微服務框架。我們實現的微服務框架的技術棧是spring boot+motan+resteasy，註冊中心采用了etcd。開源框架的整合、重構與落地過程其實就是一個不斷踩坑填坑的過程，至於選擇什麽開源框架並不重要，重要的是能根據自身業務的需求，實現一套符合企業自身業務特點的微服務架構，並形成最終企業自己的微服務架構最佳實踐。

（轉）微服務框架落地實踐之路