一悯许、微服務（microservices）

近幾年,微服這個詞闖入了我們的實線范圍迷郑。在百度與谷歌中隨便搜一搜也有幾千萬條的結果。那么每币，什么是微服務 呢携丁？微服務的概念是怎么產(chǎn)生的呢？ 我們就來了解一下Go語言與微服務的千絲萬縷與來龍去脈兰怠。

什么是微服務梦鉴？

在介紹微服務時，首先得先理解什么是微服務揭保，顧名思義肥橙，微服務得從兩個方面去理解，什么是"微"秸侣、什么是"服 務"存筏？

微（micro） 狹義來講就是體積小，著名的"2 pizza 團隊"很好的詮釋了這一解釋（2 pizza 團隊早是亞馬遜 CEO Bezos提出來的味榛，意思是說單個服務的設計椭坚，所有參與人從設計、開發(fā)搏色、測試善茎、運維所有人加起來 只需要2個披薩 就夠了 ）。

服務（service） 一定要區(qū)別于系統(tǒng)继榆，服務一個或者一組相對較小且獨立的功能單元巾表，是用戶可以感知小功能 集汁掠。

那么廣義上來講略吨，微服務是一種分布式系統(tǒng)解決方案集币，推動細粒度服務的使用，這些服務協(xié)同工作翠忠。

微服務這個概念的由來鞠苟？

據(jù)說，早在2011年5月秽之，在威尼斯附近的軟件架構師討論會上当娱，就有人提出了微服務架構設計的概念，用它來描述 與會者所見的一種通用的架構設計風格考榨。時隔一年之后跨细，在同一個討論會上，大家決定將這種架構設計風格用微服 務架構來表示河质。

起初冀惭，對微服務的概念，沒有一個明確的定義掀鹅，大家只能從各自的角度說出了微服務的理解和看法散休。 有人把微服務 理解為一種細粒度SOA（service-oriented Architecture，面向服務架構）乐尊，一種輕量級的組件化的小型SOA戚丸。

在2014年3月，詹姆斯·劉易斯（James Lewis）與馬丁·福勒（Martin Fowler）所發(fā)表的一篇博客中扔嵌，總結了微服 務架構設計的一些共同特點限府，這應該是一個對微服務比較全面的描述。

：“簡而言之痢缎，微服務架構風格是將單個應用程序作為一組小型服務開發(fā)的方法胁勺，每個服務程序都 在自己的進程中運行，并與輕量級機制（通常是HTTP資源API）進行通信牺弄。這些服務是圍繞業(yè)務功能構建的姻几。可以 通過全自動部署機器獨立部署势告。這些服務器可以用不同的編程語言編寫蛇捌，使用不同的數(shù)據(jù)存儲技術，并盡量不用集 中式方式進行管理”

微服務與微服務框架

在這里我們可能混淆了一個點咱台，那就是微服務和微服務架構络拌，這應該是兩個不同的概念，而我們平時說道的微服務 可能就已經(jīng)包含了這兩個概念了回溺，所以我們要把它們說清楚以免我們很糾結春贸。微服務架構是一種設計方法混萝，而微服 務這是應該指使用這種方法而設計的一個應用。所以我們必要對微服務的概念做出一個比較明確的定義萍恕。

微服務框架是將復雜的系統(tǒng)使用組件化的方式進行拆分逸嘀，并使用輕量級通訊方式進行整合的一種設計方法。

微服務是通過這種架構設計方法拆分出來的一個獨立的組件化的小應用允粤。

微服務架構定義的精髓崭倘，可以用一句話來描述，那就是“分而治之类垫，合而用之”司光。

將復雜的系統(tǒng)進行拆分的方法，就是“分而治之”悉患。分而治之残家，可以讓復雜的事情變的簡單，這很符合我們平時處理 問題的方法售躁。

使用輕量級通訊等方式進行整合的設計坞淮，就是“合而用之”的方法，合而用之可以讓微小的力量變動強大迂求。

微服務架構和整體式架構的區(qū)別碾盐？

開發(fā)單體式（整體式）應用的不足之處
三層架構（MVC）的具體內(nèi)容如下：
表示層（view）： 用戶使用應用程序時，看到的揩局、聽見的毫玖、輸入的或者交互的部分。
業(yè)務邏輯層（controller）： 根據(jù)用戶輸入的信息凌盯，進行邏輯計算或者業(yè)務處理的部分付枫。
數(shù)據(jù)訪問層（model）： 關注有效地操作原始數(shù)據(jù)的部分，如將數(shù)據(jù)存儲到存儲介質(zhì)（如數(shù)據(jù)庫驰怎、文件系統(tǒng)）及 從存儲介質(zhì)中讀取數(shù)據(jù)等阐滩。

雖然現(xiàn)在程序被分成了三層，但只是邏輯上的分層县忌，并不是物理上的分層掂榔。也就是說，對不同層的代碼而言症杏，經(jīng)過 編譯装获、打包和部署后，所有的代碼終還是運行在同一個進程中厉颤。而這穴豫，就是所謂的單塊架構。

單體架構在規(guī)模比較小的情況下工作情況良好逼友，但是隨著系統(tǒng)規(guī)模的擴大精肃，它暴露出來的問題也越來越多秤涩，主要有 以下幾點：

復雜性逐漸變高

比如有的項目有幾十萬行代碼，各個模塊之間區(qū)別比較模糊司抱，邏輯比較混亂筐眷，代碼越多復雜性越高，越難解決遇到 的問題状植。

技術債務逐漸上升

公司的人員流動是再正常不過的事情浊竟，有的員工在離職之前怨喘，疏于代碼質(zhì)量的自我管束津畸，導致留下來很多坑，由于 單體項目代碼量龐大的驚人必怜，留下的坑很難被發(fā)覺肉拓，這就給新來的員工帶來很大的煩惱，人員流動越大所留下的坑 越多梳庆，也就是所謂的技術債務越來越多暖途。

維護成本大

當應用程序的功能越來越多、團隊越來越大時膏执，溝通成本驻售、管理成本顯著增加。當出現(xiàn) bug 時更米，可能引起 bug 的 原因組合越來越多欺栗，導致分析、定位和修復的成本增加征峦；并且在對全局功能缺乏深度理解的情況下迟几，容易在修復 bug 時引入新的 bug。

持續(xù)交付周期長

構建和部署時間會隨著功能的增多而增加栏笆，任何細微的修改都會觸發(fā)部署流水線类腮。新人培養(yǎng)周期長：新成員了解背 景、熟悉業(yè)務和配置環(huán)境的時間越來越長蛉加。

技術選型成本高

單塊架構傾向于采用統(tǒng)一的技術平臺或方案來解決所有問題蚜枢，如果后續(xù)想引入新的技術或框架，成本和風險都很 大针饥。

可擴展性差

隨著功能的增加厂抽，垂直擴展的成本將會越來越大；而對于水平擴展而言打厘，因為所有代碼都運行在同一個進程修肠，沒辦 法做到針對應用程序的部分功能做獨立的擴展。

微服務架構的特性

單一職責

微服務架構中的每個服務户盯，都是具有業(yè)務邏輯的嵌施，符合高內(nèi)聚饲化、低耦合原則以及單一職責原則的單元，不同的服務 通過“管道”的方式靈活組合吗伤，從而構建出龐大的系統(tǒng)吃靠。

輕量級通信

服務之間通過輕量級的通信機制實現(xiàn)互通互聯(lián)，而所謂的輕量級足淆，通常指語言無關巢块、平臺無關的交互方式。

對于輕量級通信的格式而言巧号，我們熟悉的 XML 和 JSON族奢，它們是語言無關、平臺無關的丹鸿；對于通信的協(xié)議而言越走，通 常基于 HTTP靠欢，能讓服務間的通信變得標準化廊敌、無狀態(tài)化。目前大家熟悉的 REST（Representational State Transfer）是實現(xiàn)服務間互相協(xié)作的輕量級通信機制之一门怪。使用輕量級通信機制骡澈，可以讓團隊選擇更適合的語言、 工具或者平臺來開發(fā)服務本身掷空。

問：REST是什么和restful一樣嗎肋殴？
答：REST 指的是一組架構約束條件和原則。滿足這些約束條件和原則的應用程序或設計就是 RESTful拣帽。

獨立性

每個服務在應用交付過程中疼电，獨立地開發(fā)、測試和部署减拭。

在單塊架構中所有功能都在同一個代碼庫蔽豺，功能的開發(fā)不具有獨立性；當不同小組完成多個功能后拧粪，需要經(jīng)過集成 和回歸測試修陡，測試過程也不具有獨立性；當測試完成后可霎，應用被構建成一個包魄鸦，如果某個功能存在 bug，將導致整 個部署失敗或者回滾癣朗。

image.png

在微服務架構中拾因，每個服務都是獨立的業(yè)務單元，與其他服務高度解耦，只需要改變當前服務本身绢记，就可以完成獨 立的開發(fā)扁达、測試和部署。

image.png

進程隔離

單塊架構中蠢熄，整個系統(tǒng)運行在同一個進程中跪解，當應用進行部署時，必須停掉當前正在運行的應用签孔，部署完成后再重 啟進程叉讥，無法做到獨立部署

有時候我們會將重復的代碼抽取出來封裝成組件，在單塊架構中饥追，組件通常的形態(tài)叫做共享庫（如 jar 包或者 DLL）图仓，但是當程序運行時，所有組件終也會被加載到同一進程中運行判耕。

image.png

在微服務架構中透绩，應用程序由多個服務組成，每個服務都是高度自治的獨立業(yè)務實體壁熄，可以運行在獨立的進程中， 不同的服務能非常容易地部署到不同的主機上碳竟。

image.png

微服務架構的缺點

運維要求較高

對于單體架構來講草丧，我們只需要維護好這一個項目就可以了，但是對于微服務架構來講莹桅，由于項目是由多個微服務 構成的昌执，每個模塊出現(xiàn)問題都會造成整個項目運行出現(xiàn)異常，想要知道是哪個模塊造成的問題往往是不容易的诈泼，因 為我們無法一步一步通過debug的方式來跟蹤懂拾，這就對運維人員提出了很高的要求。

分布式的復雜性

對于單體架構來講铐达，我們可以不使用分布式岖赋，但是對于微服務架構來說，分布式幾乎是必會用的技術瓮孙，由于分布式 本身的復雜性唐断，導致微服務架構也變得復雜起來。

接口調(diào)整成本高

比如杭抠，用戶微服務是要被訂單微服務和電影微服務所調(diào)用的脸甘，一旦用戶微服務的接口發(fā)生大的變動，那么所有依賴 它的微服務都要做相應的調(diào)整偏灿，由于微服務可能非常多丹诀，那么調(diào)整接口所造成的成本將會明顯提高。

重復勞動

對于單體架構來講，如果某段業(yè)務被多個模塊所共同使用铆遭，我們便可以抽象成一個工具類扁藕，被所有模塊直接調(diào)用， 但是微服務卻無法這樣做疚脐，因為這個微服務的工具類是不能被其它微服務所直接調(diào)用的亿柑，從而我們便不得不在每個 微服務上都建這么一個工具類，從而導致代碼的重復棍弄。

image.png

為什么使用微服務架構

開發(fā)簡單

微服務架構將復雜系統(tǒng)進行拆分之后望薄，讓每個微服務應用都開放變得非常簡單，沒有太多的累贅呼畸。對于每一個開發(fā) 者來說痕支，這無疑是一種解脫，因為再也不用進行繁重的勞動了蛮原，每天都在一種輕松愉快的氛圍中工作卧须，其效率也會 整備地提高

快速響應需求變化

一般的需求變化都來自于局部功能的改變，這種變化將落實到每個微服務上儒陨，二每個微服務的功能相對來說都非常 簡單花嘶，更改起來非常容易，所以微服務非常是和敏捷開發(fā)方法蹦漠，能夠快速的影響業(yè)務的需求變化椭员。

隨時隨地更新

一方面，微服務的部署和更新并不會影響全局系統(tǒng)的正常運行笛园；另一方面隘击，使用多實例的部署方法，可以做到一個 服務的重啟和更新在不易察覺的情況下進行研铆。所以每個服務任何時候都可以進行更新部署埋同。

系統(tǒng)更加穩(wěn)定可靠

微服務運行在一個高可用的分布式環(huán)境之中，有配套的監(jiān)控和調(diào)度管理機制棵红，并且還可以提供自由伸縮的管理凶赁，充 分保障了系統(tǒng)的穩(wěn)定可靠性