目錄
一、單機服務到微服務的演變
微服務，顧名思義就是“微小的服務”。主要就是從兩個方面進行理解，什麼是“微”？什麼是“服務”？當然，服務的意思很好理解，就是實際工作中的一個完整的生產項目，例如淘寶網站，微信軟件等等。然後再讓我們通過下文來理解爲什麼要細化到“微”這個量級。
在認識微服務之前，我們先來看一下在微服務未出現時的傳統單體架構服務（即單機服務）。
如上圖所示，在單機服務中，一個項目所有的功能服務全部集中在一起，所有的開發人員都在這個項目中開發各自的模塊，除了容器以外基本沒有其他的依賴。在發佈到生產環境時，將所有文件集中打在一個war包裏，整個部署在tomcat或其他容器裏。在這個裏面，包含了頁面展示、業務處理，數據交互等所有的模塊。
單機服務是早期主流的架構系統，適用於開發週期短，規模不大的項目。在傳統互聯網環境中，這種單機架構工作情況良好，且由於代碼的高度集中，還有以下幾個優點 ：
- 集中管理，開發簡單
- 功能業務耦合在一起，不會有重複作業
- 部署簡單方便，一次構建啓動所有模塊
在傳統的IT行業，大多數都是各種獨立系統的堆砌，所以單機服務適用於這樣的場景。但隨着互聯網的發展，項目的規模越來越大，各個模塊更新迭代的速度越來越快，以及對系統擴展性穩定性的追求越來越高，單機服務就很難應付了，出現了各種各樣的問題。
- 開發效率緩慢；當項目代碼多達幾十萬行或者開發人員達到一定量級時，所有的編碼作業都在一個項目中完成。就導致代碼的提交相互等待，而且代碼衝突頻發
- 代碼維護困難；業務邏輯過度耦合，更新迭代無從入手
- 部署不靈活；任何小的變更，都需要重新構建整個應用，相應時長增加。並且重啓時需要停機，對高流量網站又是極大的犧牲
- 缺乏足夠的健壯性；項目中的任意模塊的一個問題（死循環、內存泄露等），就會影響到項目整體，導致應用直接癱瘓
- 擴展性欠佳；無法滿足高併發場景中，對單一模塊進行水平擴展。以電商平臺爲例，瀏覽商品信息的流量肯定是遠遠大於下單的流量的，如果相對商品模塊進行單獨擴展，則單機服務施行起來就非常困難
通俗的來講，單機服務就是把所有雞蛋放在一個籃子中，便利與風險共存。當籃子摔了或者籃子裏的任意一個“雞蛋”出現問題時，其他“雞蛋”都會受到殃及。
在以上問題越來越影響整體項目的時候，就迫切地需要新的技術新的架構來提供解決方案。在微服務興起之前，項目架構又逐漸演進爲mvc前後端分離架構，rpc分佈式架構，soa流動計算架構等等，這幾個架構的目的就是將原本多餘集中的“雞蛋”分散開來，降低整體帶來的風險，直到現在發展爲當下最新的微服務架構。
二、微服務的定義
微服務，最早是有Martin Fowler與James Lewis於2014年共同提出的一個概念。是當前比較主流的一種軟件設計架構。
簡而言之，就是將一個大型的單機應用系統拆分成若干個小的服務，這些小的服務獨立部署，服務與服務之間採用rpc/http輕量協議傳輸數據，服務間不具有強耦合性，從而實現了單個服務的高內聚，服務與服務之間低耦合的效果。這些一個一個細分的小服務就稱之爲微服務。
微服務的架構圖如下 ：
如圖所示，除了視圖層的拆分外，主要是服務層和數據層的細緯度劃分，每個服務都可以看作一個微小版的單機服務，每個微服務都可以單獨對上游請求發起響應，同時他們之間又是相互隔離的，不會因爲某一個的服務故障導致事故傳播。
相比於單機服務與其他架構，微服務架構的主要特徵是組件化、鬆耦合、獨立、去中心化。主要表現在如下幾個方面：
- 細粒度的服務分解；將項目中每個模塊/每個職責拆分出來，專注做好一件事情。
- 獨立部署運行和擴展；每個微服務又是一個單獨的項目，獨立運行在自己的進程裏。它可以不依賴於其他服務進行單獨使用和靈活擴展。這種運行和部署方式能夠賦予系統靈活的代碼組織和發佈節奏，使得快速交互和應對變化成爲可能。
- 服務間輕量通訊；各個服務之間相互獨立又通過協議進行通訊，協作完成更復雜的業務。
- 去中心化，獨立開發與自治；技術選型靈活，服務之間可以用不同的技術甚至不同的語言。
三、微服務爲我們解決了哪些問題
相對於傳統單機服務，微服務不僅解決了之前存在的問題，還擁有一些單機服務所不具備的優點：
- 便於開發，降低複雜度；各個團隊中分別維護各自服務，不會出現等待的無用功的間隙
並且更新迭代的時候，不必再學習整個項目的業務代碼，僅關注所在的服務模塊即可
- 業務解耦；各個服務間通過協議互相通訊，代碼沒有強耦合性，互不干擾
- 獨立部署；每個模塊都可以單獨部署，所以在上線新功能的時候只需發佈相應的模塊即可，既降低測試的工作量也降低了服務發佈的風險（單服務情況下，新增需求可能就得把整個的流程測試再回歸一下，並且上線失敗的話整個項目都要回滾，而微服務則只需要回滾相應的模塊即可）
- 穩定性強；單個服務出現問題，其他服務仍可繼續工作，這在技術潮流中是非常重要的一個進步，結合集羣部署，我們完美的實現不停機更新
例如訂單服務故障，用戶仍然通過商品服務可以瀏覽商品信息，查看評價等
- 擴展性強；可以根據不同服務的流量和壓力，進行自主擴展
即商品服務流量高，而訂單服務流量低，則可以部署兩個商品服務，一個訂單服務，更加靈活
四、當前微服務面臨的挑戰
在當前的場景中，微服務也不是萬能的一種方案。至少在現階段，它還存在着如下幾個問題：
- 運維成本增加；需要部署N個項目，對於單機服務來講，只需要維護一個項目就行了。但是對於微服務來講，由於項目是多個微服務構成的，每個模塊都需要進行維護
- 問題追蹤難度增加；需要分析整個請求的調用鏈，逐步查看各個服務的狀況，依此來定位和解決問題
- 內容重複；對部分業務，流程大致相同時，如果不能很方便的將代碼封裝，就可能導致在多個服務中有些重複性的代碼
除此外還有日誌重複，一個調用鏈可能要調用N個服務，在追蹤問題時，每個服務都要對參數和響應進行記錄。這樣就導致同樣一份內容在多個地方重複出現
-
增加開支成本 , 標準的的微服務部署方案，應該是每一個服務部署到一個服務器上，各個服務器之間互不干擾，但這樣的話無疑就需要更高的服務器成本
當前的主流方案是利用docker採用單服務器多鏡像隔離，但docker鏡像並沒有傳統虛擬機的高度資源隔離水平，它仍然需要很多共享的東西。這就導致瞭如果其中一個docker內核崩潰或佔用共享資源，其他容器也會受到影響
五、結語
相對於傳統單機服務，微服務的靈活獨立可用性高等特性，更適合當前主流互聯網的發展需求，也是現下技術領域中更可靠的一種技術方案，已經有很多的大型項目及技術團隊採用微服務的架構。
隨着微服務生態及社區的發展，越來越豐富的組件方案爲微服務提供了更方便的運維和監控，同時隨着docker技術的趨於成熟，也降低了微服務自身的負面問題影響，可以預見未來微服務仍有很大的發展空間，它已逐漸成爲當前最流行的一種設計架構。