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

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

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

 

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

 

前幾年咱們經常使用的三層應用架構，常常會將系統落地成單塊應用，全部的功能都運行在一個進程中，各個模塊之間的功能是強依賴的，修改一個模塊的功能很容易致使其餘模塊出現問題，並且一旦須要將系統發佈必須作一次全量發佈，發佈週期長。若是團隊中加入新人，對系統的學習成本也很高，須要瞭解完整個系統才能進行開發。在這種狀況下，如何將系統進行拆分，使得各個模塊獨立衍化成爲關鍵。

 

近幾年隨着容器技術的發展，其中以docker容器技術爲表明，一時間席捲了整個IT行業，受到大量開發者和企業熱烈追棒。docker容器技術以一種輕量級的方式能夠很是方便的將應用及其依賴打包到一塊兒，而後能夠發佈到任意裝有docker的Linux機器上面。docker的出現，有效的解決了大量服務因數量衆多而致使的開發環境搭建、部署複雜及運維成本高的難題。

 

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

 

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

 

2、微服務框架落地的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中其餘的一些關注點。

 

 

3、根據企業自身的業務特色，

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

 

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