普元雲計算-你適合微服務麼：實施微服務的4個先決條件和重點工做

轉載本文需註明出處：EAII企業架構創新研究院，違者必究。如需加入微信羣參與微課堂、架構設計與討論直播請直接回復公衆號：「EAII企業架構創新研究院」。（微信號：eaworld）

 

「Mesh App and Service Architecture」做爲Gartner2016 十大戰略技術趨勢中之一，裏面大量提到微服務的概念。微服務（Microservices）這個概念不是新概念，不少公司已經在實踐了，例如Google、Netflix、Facebook、Twiter、Alibaba。微服務架構模式（Microservices Architecture Pattern）的目的是將大型的、複雜的、長期運行的應用程序構建爲一組相互配合的服務，每一個服務均可以很容易得局部改良。

 

微服務從去年以來一直受到衆多開發者的熱捧，已經看到有許多項目嘗試使用微服務架構，結果很鼓舞人心。然而，在微服務架構帶來可獨立部署、高擴展與伸縮、自由選擇開發語言、高效利用資源、故障隔離等優勢，同時也由於服務多帶來分佈式事務、服務之間通訊、監控、部署等新的問題。

 

除了上述問題，我相信你們也會存在一些疑問：咱們公司或者系統適不適合選擇微服務架構？選擇微服務架構前，我須要準備哪些預備知識或者先決條件？碰到上述哪些問題，咱們該如何解決？須要哪些基礎框架或組件來支持微服務架構？接觸微服務大概一年多的時間，而且咱們團隊已經在去年使用微服務架構搭建咱們數字化企業雲平臺，同時在這塊也投入了不少時間去學習和研究，有一些經驗和學習心得，能夠和你們一塊兒分享與學習，下面我將會從如下幾點進行分享：

 

（1） 爲何要選擇微服務架構以及什麼時候選擇微服務架構；

（2） 講述實施微服務架構的一些先決條件；

（3） 實施微服務架構中重點知識與實踐的介紹。

 

一．爲何要選擇微服務架構

以及什麼時候選擇微服務架構

提到微服務架構時，咱們經常會作的一件事情，就是會拿來與單體架構進行比較，單體架構存在以下缺點：代碼維護難度大，臃腫的部署，侷限的彈性與擴展能力，阻礙團隊與技術革新等等；微服務架構存在以下優勢：代碼維護簡化，可獨立部署，高擴展與伸縮，自由選擇開發語言等優勢。那麼單體架構真的如此不堪一擊嗎？答案顯然不是這樣，下面咱們來看Martin Fowler在其一篇文章裏面給出關係圖：

 

 

上面的圖來自 Martin Fowler 的文章，揭示了生產率和複雜度的一個關係。在複雜度較小時採用單體應用（Monolith）的生產率更高，複雜度到了必定規模時，單體應用的生產率開始急劇降低，這時對其進行微服務化的拆分纔是合算的。因此說脫離業務場景，空談架構絕對是耍流氓。異常牛逼的架構設計，若是沒法在業務場景中落地實施，也只是空談。所以架構須要服務於業務，針對不一樣的業務場景架構設計也會不一樣，架構設計沒必要追求高大上，簡而美的架構，若能知足業務發展需求，即是好架構。此外，好的架構不徹底是設計出來的，隨着業務量、請求量的增加，好的架構是演化而來的。微服務架構之因此獲得普遍承認，源於對於業務多變性的不可預測，微服務架構可以不斷的自演化，進而快速適應業務變化。但相對於單體架構且通過嚴格定義的大規模開發項目，微服務架構要求你們面對由衆多小型服務所構成的複雜生態系統。

 

鑑於此，若是長期業務規劃不須要微服務架構或者團隊不具有實施微服務一些基本的條件，不建議各位盲目邁向微服務這一新興架構領域，或者從試點入手，逐步在團隊中推行微服務架構。

2、實施微服務架構的一些先決條件

如上所述，實施微服務架構須要一些先決條件，那麼到底有哪些基準條件呢？Martin Fowler在其的一篇文章給出他的理解，以下所示：

 

（1）快速配置:你們應該可以在幾個小時以內配置並啓用一臺全新服務器設備。通常來講採用雲計算方案可以大大縮短這一處理流程，不過咱們一樣能夠在無需依賴完整雲服務的前提下實現這一目標，容器技術不斷成熟使其變得可行；

 

（2）基礎運維與監控:因爲微服務架構要求咱們將大量鬆散耦合的服務統一在同一套生產流程中並實現其協做，所以你們每每很難單純依靠測試環境來檢測出將來可能發生的意外故障。這樣一來，運維和監控體系就成了快速檢測並定位嚴重問題的不二選擇；

 

（3）應用程序快速部署:因爲存在大量須要管理的微服務，你們必須有能力快速將其部署到開發、測試、預發，生產環境當中。一般狀況下，咱們只能利用部署流水線（Deployment Pipeline）來保證整個過程在數小時以內完全完成。在早期階段，你們還能夠經過人工方式加以干預，但在後續運做當中全部相關工做都要由自動化機制負責完成；

 

（4）持續改進的團隊組織:著名的康威定律說過「設計系統的組織，最終產生的設計等價於組織的溝通結構「，因爲微服務「按業務能力組織服務「和「服務即產品「的特徵，咱們會把一個大應用拆分紅不一樣的微服務，更傾向於讓每一個團隊本身負責整個產品的所有生命週期，因此每一個微服務背後的小團隊的組織是跨功能的，包含實現業務所需的全面的技能，微服務負責制對我的能力要求更高，自驅動和自學習能力更強的人會獲得更多的成長機會。

3、實施微服務架構中重點知識的介紹

3.1運行期配置管理

首先，咱們認爲配置分紅兩部分：運行前靜態配置和運行期動態配置，靜態配置部分能夠閱讀我同事的文章《DevOps之軟件配置協做化管理》，我這裏主要講解運行期動態配置管理。

服務通常有不少依賴配置，例如訪問數據庫有鏈接字符串配置，鏈接池大小和鏈接超時配置，這些配置在不一樣環境(開發/測試/預發/生產)通常不一樣，好比生產環境須要配鏈接池，而開發測試環境可能不配，另外有些參數配置在運行期可能還要動態調整，例如，運行時根據流量情況動態調整限流和熔斷閥值。目前比較常見的作法是搭建一個運行時配置中心支持微服務的動態配置，簡化架構以下圖所示:

 

動態配置存放在集中的配置服務器上，用戶經過管理界面配置和調整服務配置，具體服務經過按期拉(Scheduled Pull)的方式或者服務器推(Server-side Push)的方式更新動態配置，拉方式比較可靠，但會有延遲同時有無效網絡開銷(假設配置不常更新)，服務器推方式能及時更新配置，可是實現較複雜，通常在服務和配置服務器之間要創建長鏈接。配置中心還要解決配置的版本控制和審計問題，對於大規模服務化環境，配置中心還要考慮分佈式和高可用問題。

 

相似配置中心比較成熟的開源方案有百度的Disconf，360的QConf，Spring的Cloud Config和阿里的Diamond等。

3.2 基礎運維與監控

因爲微服務架構一個大應用拆分紅不一樣的微服務，每一個服務都是運行在不一樣進程上。所以，須要爲服務創建獨立的監控、告警、快速分析與定位的機制。

監控是整個運維環節中很是重要的一環。監控一般分爲兩類：系統監控與應用監控。

系統監控關注服務運行所在節點的健康情況，譬如CPU、內存、磁盤、網絡等。應用監控則關注應用自己及其相關依賴的健康情況，譬如服務自己是否可用、其依賴的服務是否能正常訪問等。

咱們知道，當系統出現異常時，經過監控能發現異常，這時候咱們經過合適的告警機制，則能及時、有效地通知相關責任人，作到早發現問題，早分析問題，早修復問題。然而當咱們面對不少微服務，每一個服務因爲負載均衡又會部署多個實例，再使用單體架構那邊查看日誌方式顯然不合適(成本會呈幾何倍增長)，經過日誌聚合的方式，能有效將不一樣節點的日誌聚合到集中的地方，便於分析和可視化，可以快速發現和解決問題，基本流程以下圖所示：

 

在咱們的數字化企業雲平臺中，因爲是基於容器技術的，使用的CoreOS系統，最終咱們採用了Journald+Fluentd+ElasticSearch的技術，更多詳情見咱們另一個同事的《微服務來了，監控怎麼辦？》。

3.3應用程序快速部署

因爲存在大量須要管理的微服務，你們必須有能力快速將其部署到開發、測試、預發，生產環境當中。一般狀況下，咱們只能利用部署流水線（Deployment Pipeline）來保證整個過程在數小時以內完全完成。在早期階段，你們還能夠經過人工方式加以干預，但在後續運做當中全部相關工做都要由自動化機制負責完成。

部署大概經歷了三個發展階段：手動部署，腳本部署，以及自動化部署（應用和基礎設施）。在咱們數字化企業雲平臺中，因爲使用容器的技術，最終都會打包成鏡像部署到相應的容器裏面，咱們抽象出一個微服務叫作SRM（軟件發佈管理），同時爲了不環境的差別性（物理機、虛擬機、容器），又抽象出另一個微服務叫作SEM（軟件環境管理），有他們倆共同完成應用程序的快速部署。其與其餘領域微服務的關係圖以下：

 

那麼，他的部署流程到底又是咋樣呢？SRM收到部署請求後，會加載產品與組件部署拓撲數據；而後根據組件的依賴逆序向「軟件環境管理系統SEM」發起部署請求，對於單個組件部署，SRM將用戶指定的部署規格傳遞到SEM系統中，SEM系統根據部署規格進行組件的部署，部署規格目前採用yaml文件格式描述，主要包含的內容包括鏡像地址、部署類型、部署參數等數據。實際上SRM中的部署規格主要是對SEM系統內容器的服務部署能力的體現。以下圖所示：

 

上述只是應用自動化部署的過程，若是還想了解其中的詳情，能夠閱讀個人同事另外一篇文章《DevOps之應用自動化發佈與資源管理》。

3.4持續改進的團隊組織

 

因爲微服務「按業務能力組織服務「和「服務即產品「的特徵，咱們會把一個大應用拆分紅不一樣的領域系統，更傾向於讓每一個團隊本身負責整個產品的所有生命週期，造成團隊組織去中心化。著名的康威定律說過「設計系統的組織，最終產生的設計等價於組織的溝通結構「，常見的微服務組織結構圖以下：

 

這原本是一個很好的想法，每一個團隊有自主的權利，選擇合適開發語言與數據庫，相互之間經過RestFul API 進行通訊，維護更加簡化，責任明確等優勢，可是也帶來一些問題：代碼風格不統一，全局系統化考慮不周到，日誌格式不統一，依賴關係變變複雜，服務之間團隊協做比較差等。爲了解決以上問題，咱們對於上述組織結構進行改動（我這裏說主要是研發團隊），以下圖所示：

 

整體架構組負責對於每一個領域系統技術選型進行評定與約束，以及共有的標準制定、底層架構的支持，領域系統關係的梳理等，這樣就不會致使技術選型過分碎片化，給後期管控以及實現自動自助化運營帶來方便。無自動化不微服務，自動化包括編譯、打包、測試和部署，單一進程的傳統應用被拆分爲一系列的多進程服務後，意味着開發、調試、測試、監控和部署的複雜度都會相應增大，必需要有合適的自動化基礎設施來支持微服務架構模式，不然開發、運維成本將大大增長，正是因爲DevOps的存在使得微服務可以獲得大規模化的使用。試想一下，把 1 個應用進程部署到 1 臺主機，部署複雜度是 1 x 1 = 1，若應用規模須要部署 20 臺主機，那麼部署複雜度是 1 x 20= 20。 把 1 個應用進程拆分紅了 50 個微服務進程，則部署複雜度變成了 50 x 20 = 1000，缺少自動化設施，光部署就會把人搞死。

總結

本文從微服務的定義出發，得出微服務的優勢與問題，而後分紅幾大模塊：第一部分，爲何選擇微服務架構，以及什麼時候開始實施微服務架構；第二部分，講述實施微服務架構的一些先決條件；第三部分，咱們在實施微服務架構中一些重點知識的介紹,比較全面的梳理總結微服務架構的各方面。微服務是一個近年的新概念，但卻真不是一個原創性的新東西。它幫助大型應用打散和轉移了複雜性，使其能夠被更高效的並行解決，但並無減小任何複雜性，甚至還引入了額外的分佈式計算固有的複雜性。咱們需有一個清晰的認識，才能更好的認識和實踐微服務架構。

 

關於做者：

王召

現任普元信息資深開發工程師，爲普元新一代數字化企業雲平臺開發團隊一員，負責新一代SPM（軟件產品管理）與MKT（軟件市場）領域系統的開發。曾在百度西北營銷自主研發中心、格林談談科技等互聯網公司從事開發經理工做，曾主導開發過多款電商和社交項目，並得到風險基金的投資。平時喜歡旅遊，騎行，登山等活動。

 

 

關於EAII

EAII（Enterprise Architecture Innovation Institute）企業架構創新研究院，致力於軟件架構創新與實踐，加速企業數字化轉型。

 

eaworld項目（微信號：eaworld，長按二維碼關注）

eaworld是EAII的官方微信帳號。