是什麼讓你這麼嚮往微服務？5分鐘瞭解微服務的本質

有不少人經常問我，“最近想換個工作，不會微服務怎麼辦？”，“我們公司新立的那個專案不是微服務架構，好失望！”，“我希望下家公司使用微服務”……

這樣的話聽到的太多了，但我每次問為什麼你這麼嚮往使用微服務呢，對方給出的回答總是含糊不清，都是諸如“反正其他人都在用，覺得高大上”這類的回答，所以我覺得有必要來寫一篇文章來澄清下微服務的本質了。

單體架構

說微服務之前，我們先來說說沒有微服務的時候，我們用的是什麼。我想你一定會說，那就做一個專案，既包含前端程式碼，也包含後端程式碼唄！如果我再問你，那使用的客戶多了，一臺伺服器的負載過大怎麼辦呢？我相信你一定會想到把這個專案多部署幾臺伺服器，然後再使用軟/硬服務均衡進行轉發即可。

沒錯，這就是最傳統的單體架構，我這裡說傳統，並不是指的他已經被淘汰或將被淘汰，而是說這種架構誕生早、受眾多，而且也永遠不會過時。這種架構的優勢是簡單、易部署，對於小公司和小專案來說使用起來極為舒適，研發成本也低。

使用單體架構的系統

SOA架構

你們公司的業務大好，客戶急劇增多，公司規模也逐步擴張了。你們老闆的野心開始擴大。不行，我要打造一個產品體系！於是乎，又多出來了十幾個產品，這些產品需要多專案協作和配合，透過RESTful/Socket等進行介面呼叫。那總不能各自呼叫各自的呀，總得有個中心，得有個老大。以便於出現問題後，也可以從這裡看到呼叫資訊，此外還可以從這裡配置許可權等。

於是，Service Bus（服務匯流排）誕生了，所謂服務匯流排，就是所有服務的交通樞紐，即專案之間的互動核心地帶。在大多數情況下，服務匯流排經常由ESB（Enterprise Service Bus）中介軟體來勝任。有了服務匯流排，系統也變得易於管理和監控了，例如哪些介面可以相互呼叫，呼叫時需要做哪些處理，在這裡配置下就好了。如果遇到系統問題，可以從這裡檢視監控資訊，瞭解專案之間的所有呼叫鏈路情況。

這就是SOA架構，超越單體架構，也比單體架構更復雜，部署難度更大，但帶來的好處是對大型專案比較友好，可以透過專案拆分獨立部署，或者讓每個部門獨立負責，這樣的技術設計就可以撐起你老闆的野心了！

ESB系統示例

微服務

你很高興的跑來告訴我說你們公司融資了幾億美元，投資人讓你的老闆繼續擴大自己的野心！是的，沒錯，你老闆也這麼認為，他說要打造一個全國統一的大型生態平臺！看看，這就是成功公司的發展歷程，從單個專案，到產品體系，再到生態平臺。

可一個平臺不容易做呀，公司已經擴張到了二千多人，涉及部門達到幾十個，新立專案多達80多個。你們公司的架構師找到老闆，“老闆不行，我們構建的是全國統一平臺，對高可用、高效能、高擴充套件的要求很高，之前的SOA架構已經無法滿足要求了，架構必須大動手腳了！”。架構師滿懷信心的看著老闆。

“為什麼要改呢？”，老闆問道。“因為SOA架構是有中心點的，也就是瓶頸，這個瓶頸垮了，整個平臺就垮了，所以我們的新架構必須去掉這個中心點！”。老闆低頭沉思了下，“有道理，就按你的做！”。

一個使用微服務架構的系統

這就是SOA架構到微服務架構的演變歷程，SaaS化產品，由於受眾多，對高可用、高效能、高擴充套件的要求高，所以需要改造為微服務模式。那SOA與微服務的具體區別有哪些呢？如下：

①SOA拆分粒度較大，基本是按專案為單位進行拆分的，而SOA粒度更小，以元件為粒度進行拆分，一個元件可以只包含數個介面。

②SOA有服務匯流排，微服務則沒有，微服務使用諸如Zookeeper等進行服務發現和治理，而Zookeeper本身則也是分散式的，很顯然平臺沒有太明顯的瓶頸了。

③元件化拆分後，每個元件在遵循公共協議的基礎上，可以採用不同的技術棧實現其功能。例如元件A更適合用Python，元件B更適合用Java等。

但是請記住，這種去中心化的設計，雖然更利於系統解耦和技術分工。但同時帶來的弊端就是部署成本高、監控成本高等。例如平臺需要部署多達幾十上百臺伺服器，一個請求是十幾個元件協同配合的結果。當出現問題後，就會導致排查困難，所以微服務往往會配合Docker、K8S等容器部署解決方案，且使用全鏈路監控的方式來降低問題排查成本。

使用場景

以上就是架構的三種狀態及其演變歷程。當你明白這些道理後，你就不會覺得以後所有專案都應該是微服務的天下了。

小專案依然很多，創業公司也更適合使用單體架構，便於降低開發成本，提高產品迭代速度。

B端中型專案，更適合使用SOA架構，例如醫院內部系統、政府內部系統等。

C端專案更適合使用微服務架構，這也就是為什麼網際網路型公司使用微服務架構的最多，因為其平臺是面向全國使用者的。