微服務實踐之客觀認識微服務

關注嘉爲科技，獲取運維新知

 

01
當人們談論微服務的時候，
他們究竟在說些什麼？

 

微服務由MicroServices翻譯而來，是一種軟件架構風格，它以專一於單一責任與功能的小型功能區塊爲基礎，利用模組化的方式組合出複雜的大型應用程序，各功能區塊使用與語言無關的API集互相通信。

以上是維基百科對微服務的定義，專業詞彙不算少，接下來咱們經過對比傳統的單體架構、SOA架構來理解微服務。

 

如何理解單體架構和微服務架構？

 

打個比方，如今需求生產一輛玩具車，一種作法是設計一條工序繁多、功能強大的生產流水線，各類原材料通過該流水線的加工處理，最終直接產出一輛完整的玩具車；

 

另外一種作法是設計不少條工序簡單、功能單一的流水線，分別用於生產車門、底盤、座椅、輪胎等部件，每一個部件都預留好接口，生產完部件再將它們拼裝成玩具車。

 

單體架構相似前一種生產玩具車的作法，最終產品很完整，但內部結構可能很是複雜，各部件難以拆分和替換，非要替換部件的話只能修改整條生產流水線，代價大，影響範圍廣。

 

微服務架構相似後一種作法，將複雜的生產流水線拆分紅不少功能單一的流水線，各部件的生產流程相對簡單，只要合理設計好部件的接口，最終也能順利拼裝出玩具車，若是想要替換部件，只需修改生產該部件的流水線，其餘流水線幾乎不受影響，修改爲本低，影響小，效率高。

 

因此，當人們談論微服務的時候，其實他們談的是如何設計「樂高積木」，以及如何將這些「樂高積木」拼裝成一套軟件系統。

 

02

單體架構哪裏錯了？

 

自軟件工程面世以來，單體架構就一直存在到如今，期間曾有SOA架構出來挑戰其地位，最後以失敗了結，如今又輪到微服務來下戰書。講道理，單體架構存在了幾十年，貢獻了大量優秀軟件項目，爲何總有新架構來挑釁呢？

 

單體架構會將應用程序的全部功能都打包成一個獨立的程序包，一個剛設計完的單體應用每每都具有一些共同點：結構清晰、依賴簡單、方便開發和調試、易於部署和測試，一切完美無瑕。然而，軟件項目是一個不斷迭代和變化的過程，加模塊、擴功能、改需求簡直就是屢見不鮮，而全部的變化最終都得靠修改這個單體應用的代碼來實現。

結果可想而知，就算開始時的設計再合理再完美，也會由於頻繁的迭代和變動成長爲一個龐然大物四不像，離當初的目標愈來愈遠。

 

隨着軟件系統愈來愈龐大和複雜，潛藏的問題開始凸顯出來——

 

代碼難以維護：一個大型單體應用可能有幾十人甚至幾百人參與過代碼開發，其內部結構的複雜度已經沒有任何我的能夠徹底掌握；

 

性能難以擴展：幾乎沒有辦法對局部高頻使用的功能作針對性擴展，就算只爲了提升很小一部分功能的負載能力，也不得不完整地擴展整套應用，形成嚴重的資源浪費；

 

系統穩定性差：改一發而動全身，有時一個微不足道的小問題，卻能讓整個系統沒法正常使用；

 

開發效率低：全部人都在同一份代碼上開發，代碼衝突不斷，開發工做由於代碼版本的同步問題而停滯不前；

 

部署耗時：應用啓動消耗時間長，任何小問題均可能致使啓動失敗，一旦出錯只能所有從新來過；

 

技術過期：單體架構的技術選型，大多在開始的時候就肯定了，若是一個工程迭代了不少年，那麼幾乎用不上後來出現的新技術，除非總體重構，而重構的代價是巨大的，過期的技術又吸引不了優秀開發者，進退兩難。

 

因此說，單體架構小時候仍是很優秀，只是成長的過程當中承受不了各方面的變動壓力，最終畸形了。若是能夠不成長，單體架構依然是很好的選擇，但事實證實這不太現實。

 

03

微服務和SOA有什麼區別？

 

軟件架構歷史沿着單體架構、SOA架構、微服務架構的路徑發展，若是比較這三者的差別，會發現SOA和微服務的理念其實很像，都是分佈式架構，甚至微服務的不少概念都沿襲自SOA。

 

SOA即Service-Oriented Architecture，面向服務的體系架構，它也是以服務爲維度來設計軟件的。SOA的服務是宏觀意義上的服務，或者說是功能組件，好比從ERP中抽離出一個功能相對獨立的統一用戶管理的小型系統，可獨立部署使用，也可提供用戶信息給ERP的其餘模塊使用。

 

雖然SOA談的是面向服務，但它的核心組件實際上是應用，服務只是應用對外提供的一種能力，並不能獨立存在。因此，SOA能夠理解爲面向小型應用的架構，這些小型應用能夠對外輸出服務能力，服務接口大多數時候採用SOAP協議（即WebService），並經過ESB組件進行通訊和管理。

SOA架構原本是爲了去中心化，結果ESB卻成爲了事實上的中心和瓶頸，再加上重量級的SOAP協議性能不佳，最終慢慢走向沒落。

 

微服務的「微」字，也許當初就是相對SOA服務而言的，實踐微服務的先行者和貢獻者Netflix公司，就曾將他們的架構稱爲「細粒度的SOA」，可見微服務和SOA一脈相承。

 

相比較SOA而言，微服務拋棄了SOAP協議，改用輕量級的HTTP RESTful API，拋棄繁瑣的ESB組件，取而代之的是更加靈活輕便的API網關。微服務再也不以小型應用爲單位進行服務拆分，大多數微服務可能僅僅是一堆後端接口的集合，自身都構不成一個完整的功能模塊。

 

微服務的服務拆分粒度比SOA更小也更靈活，能夠由少數業務關聯的API組成一個服務，也能夠由不少API組成一個服務，甚至能夠將單獨一個高負載的接口封裝成微服務，這一切徹底根據業務需求、性能要求和擴展彈性來靈活設計。

 

因此，微服務是一個比SOA更輕量、更方便擴展、去中心化更完全的分佈式架構。輕量級這點很關鍵，它使得持續部署成爲了可能，微服務、DevOps、容器化幾乎是同一時間流行起來的，相信這不是簡單的偶然事件。

 

04 

微服務是軟件架構的銀彈嗎？

 

布魯克斯在30多年前的論文提出，沒有任何一種單純的技術或管理上的進步，可以保證在十年內大幅度地提升生產率、可靠性和簡潔性，是爲「沒有銀彈」。微服務的出現可否打破這魔咒呢？答案依然是「沒有銀彈」。

 

軟件架構沒有最好的，只有最合適的。支撐阿里雙十一的技術架構足夠強大了吧？然而它卻不必定適合你，一是沒有海量併發處理能力的需求，勢必形成資源浪費，二是維護這樣一套架構，額外需求的開發、運維人員可能比本來開發業務系統的人員還多。盲目跟風微服務，其結局也可能跟前面的例子同樣，得不償失。

 

首先，微服務的優點仍是明顯的——

 

◉  複雜度可控：將本來單體應用內部的複雜度分而治之，每一個微服務只負責單一的職責，複雜度顯著下降；

 

◉  獨立部署，穩定性高：每一個微服務單獨一個進程，單個微服務的宕機、從新部署，對整個系統而言只是局部功能的暫時不可用，其餘功能依然能夠正常使用，並且，微服務通常會作雙節點以上的高可用，所以系統的總體穩定性是比較高的；

 

◉  擴展方便：針對負載高的微服務，能夠快速地進行水平擴展，哪一個負載壓力大擴哪一個，跟打地鼠遊戲同樣簡單，彈指揮間實現服務的升降級；

 

◉  技術選型靈活：因爲微服務經過標準的HTTP協議通信，對開發語言沒有任何限制，所以每一個微服務均可以自由選擇技術類型，互不影響，新語言、新技術，想用就用。

 

不過，微服務的缺點也很多，特別對於小型項目來講。若是開發一個簡單的CMS系統，也搬出微服務一整套架構，那就是殺雞用牛刀，過分設計。讓程序員抓狂的事情，一是產品經理變動需求，二是架構師過分設計。

 

接下來咱們細數一下微服務的缺點——

 

◉  維護難度高：雖然單個微服務的複雜度不高，但把全部微服務組合成一個完整應用的難度卻不低，微服務的整體複雜度甚至高於單體架構。

一個微服務架構，不可或缺的組件包括API網關、服務註冊與發現、消息機制、容錯管理、負載均衡、日誌收集、應用監控等等，必須把這些組件都準備完畢後，才能真正開始業務代碼的開發。當某個功能報錯時，整條調用鏈路的任何一環均可能致使這個錯誤，排查難度高，不像單體應用直接調試代碼那麼簡單。

 

◉  分佈式事務：微服務的設計原則之一包括數據庫隔離，這就成了分佈式數據庫，本來一個簡單事務就能解決多表寫操做，如今不得不考慮CAP理論和取捨、兩段式提交、事務補償等一大堆跟業務無關的技術難題；

本來一個JOIN語句就能搞定的聯表查詢，如今不得不考慮API調用鏈、並行處理、數據緩存等等，而最終的查詢性能可能還不如JOIN來得高效。

 

◉  異步消息：爲了提升總體的吞吐能力和交互體驗，不少時候消息隊列是必須的，將接口調用的阻塞等待轉化成異步回調，一個接口瞬間變倆，若是再加上分佈式事務，編程複雜度直線上升。

 

◉  調試複雜：微服務架構的應用，幾乎很難在開發人員的電腦上運行全部的組件和服務，這將耗費很是多的CPU和內存資源，因此只能一部分服務在本地運行，一部分服務在公共服務器上運行，調試代碼的時候須要處處切換環境排錯，服務器上的接口還不方便debug，效率低下。

 

◉  技術門檻高：拿Java Web項目來講，本來開發一個單體應用，程序員只要掌握好Java開發基礎、經常使用框架技術、數據庫基礎差很少就夠了，而一旦改用微服務，什麼服務註冊發現、消息隊列、API網關、負載均衡、分佈式事務、容錯處理等一系列新技術、傳統技術通通都得掌握，並且寫代碼時還必須頭腦清晰有大局觀，不然很容易寫出一堆Bug。

 

◉  DevOps能力：除了開發技能過關外，團隊還必須具有必定的DevOps能力了，不然會花費一大部分的時間在編譯出包、部署排錯、集成測試這些重複又瑣碎的事情上面。

 

可見，微服務不是放之四海而皆準的銀彈，只有深刻理解微服務的優點和劣勢，客觀認識自身項目的業務和技術需求，才能作出最恰當的技術架構選擇，避免爲了微服務而微服務。

 

若是你已經跟微服務確認過眼神是符合實際要求的架構，那麼後面的文章，咱們將開始介紹具體的微服務落地技術。