1 傳統(tǒng)單體系統(tǒng)介紹

物理服務器的CPU、內存、存儲器、連接數等資源有限，單體系統(tǒng)能夠承受的的QPS也是有限的，某個時段大量連接同時執(zhí)行操作，會導致web服務和數據庫服務在處理上遇到性能瓶頸。

為了解決這個問題，偉大的前輩們發(fā)揚了分而治之的思想，對大數據庫、大表進行分割，可以參考我的《Mysql數據庫分庫分表全面瓦解》，以便實施更好的控制和管理。

同時創(chuàng)建多個服務實例，使用多臺服務機進行CPU、內存、存儲的分攤，提供更好的性能。

1.1 單體系統(tǒng)的問題

1、復雜性高：由于是一個單體的系統(tǒng)，所以整個系統(tǒng)的模塊是耦合在一起的，模塊的邊界比較模糊、依賴關系錯綜復雜。功能的調整，容易帶來不可知的影響和潛在的bug風險。

2、服務性能問題：單體系統(tǒng)遇到性能瓶頸問題，只能橫向擴展，增加服務實例，進行負載均衡分擔壓力。無法縱向擴展，做模塊拆分。

3、擴縮容能力受限：單體應用只能作為一個整體進行擴展，影響范圍大，無法根據業(yè)務模塊的需要進行單個模塊的伸縮。

4、無法做故障隔離：當所有的業(yè)務功能模塊都聚集在一個程序集當中，如果其中的某一個小的功能模塊出現(xiàn)問題（如某個請求堵塞），那么都有可能會造成整個系統(tǒng)的崩潰。

5、發(fā)布的影響范圍較大：每次發(fā)布都是整個系統(tǒng)進行發(fā)布，發(fā)布會導致整個系統(tǒng)的重啟，對于大型的綜合系統(tǒng)挑戰(zhàn)比較大，如果將各個模塊拆分，哪個部分做了修改，只發(fā)布哪個部分所在的模塊即可。

1.2 單體系統(tǒng)的優(yōu)點

1、系統(tǒng)的簡易性：系統(tǒng)語言風格、業(yè)務結構，接口格式均具有一致性，服務都是耦合在一起的，不存在各個業(yè)務通信問題。

2、易于測試：單體應用一旦部署，所有的服務或特性就都可以使用了，簡化了測試過程，無需額外測試服務間的依賴，測試均可在部署完成后開始。

3、易于部署與升級：相對于微服務架構中的每個服務獨立部署，單體系統(tǒng)只需將單個目錄下的服務程序統(tǒng)一部署和升級。 

4、較低的維護成本：只需維護單個系統(tǒng)即可。運維主要包括配置、部署、監(jiān)控與告警和日志收集四大方面。相對于單體系統(tǒng)，微服務架構中的每個服務都需要獨立地配置、部署、監(jiān)控和日志收集，成本呈指數級增長。

1.3 單體服務到微服務的發(fā)展過程

EUREKA的注冊中心逐漸被ZooKeeper和Nacos等替代了。

2 關于微服務

微服務是 一種架構模式，是面向服務的體系結構（SOA）軟件架構模式的一種演變，

它提倡將單一應用程序 劃分成一組松散耦合的細粒度小型服務，輔助輕量級的協(xié)議，互相協(xié)調、互相配合，為用戶提供最終價值。

所以，微服務（或微服務架構）是一種云原生架構方法，其中單個應用程序由許多松散耦合且可獨立部署的較小組件或服務組成。這些服務通常包含如下特點：  

2.1 單一職責

微服務架構中的每個節(jié)點高度服務化，都是 具有業(yè)務邏輯的，符合高內聚、低耦合原則以及單一職責原則的單元，包括數據庫和數據模型；

不同的服務通過“管道”的方式靈活組合，從而構建出龐大的系統(tǒng)。

2.2 輕量級通信

通過REST API模式或者RPC框架，實現(xiàn)服務間互相協(xié)作的輕量級通信機制。

2.3 獨立性

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

2.4 進程隔離

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

進程的隔離，還能保證服務達到動態(tài)擴縮容的能力，業(yè)務高峰期自動增加服務資源以提升并發(fā)能力，業(yè)務低谷期則可自動釋放服務資源以節(jié)省開銷。 

2.5 混合技術棧和混合部署方式

團隊可以為不同的服務組件使用不同的技術棧和不同的部署方式（公有云、私有云、混合云）。

2.6 簡化治理

組件可以彼此獨立地進行擴縮容和治理，從而減少了因必須縮放整個應用程序而產生的浪費和成本，因為單個功能可能面臨過多的負載。 

2.7 安全可靠，可維護。

從架構上對運維提供友好的支撐，在安全、可維護的基礎上規(guī)范化發(fā)布流程，支持數據存儲容災、業(yè)務模塊隔離、訪問權限控制、編碼安全檢測等。 

3 微服務演進史 

我們前面已經了解了微服務的概念，通過百度指數可以看出，從2012年之后，微服務的發(fā)展有顯著的發(fā)展趨勢。

目前業(yè)內的微服務相關開發(fā)平臺和框架還是比較多的，比如較早的Spring Cloud（使用Eureke做服務注冊與發(fā)現(xiàn)，Ribbon做服務間負載均衡，Hystrix做服務容錯保護），

阿里的Dubbo，微軟的.Net體系微服務框架 Service Fabric，再到后來進階的服務網格(Service Mesh,如 Istio、Linkerd）。

那從12年開始到現(xiàn)在，微服務到底發(fā)展到哪個階段了，在各個階段的進階過程中，又有哪些的變化。所以我們需要了解微服務技術的歷史發(fā)展脈絡。

下面的內容參考了 Phil Calçado的文章《Pattern: Service Mesh》，從開發(fā)者的視角，詳細分析了從微服務到Service Mesh技術的演進過程，這邊做了進一步的整理和總結。 

3.1 第一階：簡單服務通信模塊

這是最初的模樣，開發(fā)人員最開始的時候想象的兩個服務間簡單的通信模式，抽象表示如下，兩個服務之間直接進行通信：

3.2 第二階：原始通信時代

上面的方式非常簡單，但實際情況遠比想象的復雜很多，通信需要底層字節(jié)碼傳輸和電子信號的物理層來完成，在TCP協(xié)議出現(xiàn)之前，

服務需要自己處理網絡通信所面臨的丟包、錯誤、亂序、重試等一系列流控問題，因此服務實現(xiàn)中，除了業(yè)務邏輯外，還包含對網絡傳輸問題的處理邏輯。

3.3 第三階：TCP時代

TCP協(xié)議的出現(xiàn)，避免了每個服務自己實現(xiàn)一套相似的網絡傳輸處理邏輯，解決網絡傳輸中通用的流量控制問題。

這時候我們把處理網絡傳輸的能力下沉，從服務的實現(xiàn)中抽離出來，成為操作系統(tǒng)網絡層的一部分。

3.4 第四階：第一代微服務（Spring Cloud/RPC）

TCP出現(xiàn)之后，服務間的網絡通信已經不是一個難題了，所以 GFS/BigTable/MapReduce 為代表的分布式系統(tǒng)得到了蓬勃的發(fā)展。

這時，分布式系統(tǒng)特有的通信語義又出現(xiàn)了，如服務注冊與發(fā)現(xiàn)、負載均衡、熔斷降級策略、認證和授權、端到端trace、日志與監(jiān)控等，因此根據業(yè)務需求,完成一些通信語義的實現(xiàn)。

3.5 第五階：第二代微服務

為了避免每個服務都需要自己實現(xiàn)一套分布式系統(tǒng)通信的語義功能，隨著技術的發(fā)展，一些面向微服務架構的通用開發(fā)框架出現(xiàn)了，如Twitter的Finagle、Facebook的Proxygen以及Spring Cloud等，

這些框架實現(xiàn)了分布式系統(tǒng)通信需要的各種通用語義功能：如負載均衡和服務發(fā)現(xiàn)等，因此一定程度上屏蔽了這些通信細節(jié)，使得開發(fā)人員使用較少的框架代碼就能開發(fā)出健壯的分布式系統(tǒng)。

3.6 第六階：第一代Service Mesh

上面的第二代微服務框架目前看著挺完美了，但整套微服務框架其實是很復雜的，比如Spring Cloud，聚合了很多組件。所以在實踐過程中，會發(fā)現(xiàn)有如下諸多問題：

• 侵入性強。想要集成SDK的能力，除了需要添加相關依賴，業(yè)務層中 入侵的代碼、注解、配置，與治理層界限不清晰。

• 升級成本高。每次升級都需要業(yè)務應用修改SDK版本，重新進行功能回歸測試，并對每一臺服務進行部署上線， 與快速迭代開發(fā)相悖。

• 版本碎片化嚴重。由于升級成本高，而中間件版本更新快，導致 線上不同服務引用的SDK版本不統(tǒng)一、能力參差不齊，造成很難統(tǒng)一治理。

• 中間件演變困難。由于版本碎片化嚴重，導致中間件向前演進的過程中就需要在代碼中 兼容各種各樣的老版本邏輯，帶著"枷鎖”前行，無法實現(xiàn)快速迭代。

• 內容多、門檻高。依賴組件多，學習成本高，即使通用分布式系統(tǒng)屏蔽了很多的實現(xiàn)細節(jié)，我們引入微服務框架并熟練使用也是要花費巨大的精力的。

• 治理功能不全。不同于RPC框架，SpringCloud作為治理全家桶的典型，也不是萬能的，諸如協(xié)議轉換支持、多重授權機制、動態(tài)請求路由、故障注入、灰度發(fā)布等高級功能并沒有覆蓋到。

• 無法實現(xiàn)真正意義上的語言無關性。提供的框架一般只支持一種或幾種語言，要將框架不支持的語言研發(fā)的服務也納入微服務架構中，是比較有難度的。

所以，第一代微服務架構 Service Mesh就產生了，它作為一個基礎設施層，能夠與業(yè)務解耦，主要解決復雜網絡拓撲下微服務與微服務之間的通信，其實現(xiàn)形態(tài)一般為輕量級網絡代理，并與應用以邊車代理（SideCar）模式部署，同時對業(yè)務應用透明。

SideCar將分布式服務的通信抽象為單獨一層，需要和服務部署在一起，接管服務的流量，通過代理之間的通信間接完成服務之間的通信請求。

所以在這一層中它能夠實現(xiàn)負載均衡、服務發(fā)現(xiàn)、認證授權、監(jiān)控追蹤、流量控制等分布式系統(tǒng)所需要的功能。

如果我們從一個全局視角來看，綠色的為應用服務，藍色的為SideCar，就會得到如下部署圖：

如果我們省略去服務，只看Service Mesh的代理邊車的網格應該是這樣的：

流量經過的時候，會先被代理邊車所劫持，然后再進入服務，所以它就是一個由若干服務代理所組成的錯綜復雜的網格。  

3.7 第七階：第二代Service Mesh

第一代Service Mesh由一系列獨立運行的單機代理服務構成，為了提供統(tǒng)一的上層運維入口，演化出了集中式的控制面板，我們稱之為控制面（control plane）。

控制面和所有的數據面（data plane，即代理邊車）進行交互，比如策略下發(fā)、數據采集等。這就是以Istio為代表的第二代Service Mesh。

只包含控制面和數據面的 Service Mesh 服務網格全局結構圖 如下：

從上面的結構圖可以看出，Service Mesh 的基礎設施層主要分為兩部分：控制平面與數據平面。當前流行的開源服務網格 Istio 和 Linkerd 都是這種構造。

控制平面的特點：

• 不直接解析數據包。
• 與控制平面中的代理通信，下發(fā)策略和配置。
• 負責網絡行為的可視化。
• 通常提供 API 或者命令行工具可用于配置版本化管理，便于持續(xù)集成和部署。

數據平面的特點：

• 通常是按照無狀態(tài)目標設計的，但實際上為了提高流量轉發(fā)性能，需要緩存一些數據，因此無狀態(tài)也是有爭議的。
• 直接處理入站和出站數據包，轉發(fā)、路由、健康檢查、負載均衡、認證、鑒權、產生監(jiān)控數據等。
• 對應用來說透明，即可以做到無感知部署。

到這一步我們大概了解了微服務架構的演進過程，也初步了解Service Mesh技術比較于傳統(tǒng)的微服務架構有哪些優(yōu)勢。

以上就是詳解微服務架構及其演進史的詳細內容，更多關于微服務演進史的資料請關注腳本之家其它相關文章！

最新評論