微服務1：微服務及其演進史
微服務2：微服務全景架構
在很多項目的業務初期階段，高速疊代上線是首要考慮的事情，對後期的容量預估、可擴充性和系統健壯性、高可用一般沒有那麼重視。但随着業務的發展，使用者量、請求量的暴增，
發現原來的單體系統已經遠遠不滿足需求了，特别是随着網際網路整體的高速發展，對系統的要求越來越高。
但是實體伺服器的CPU、記憶體、存儲器、連接配接數等資源有限，單體系統能夠承受的的QPS也是有限的，某個時段大量連接配接同時執行操作，會導緻web服務和資料庫服務在處理上遇到性能瓶頸。
為了解決這個問題，偉大的前輩們發揚了分而治之的思想，對大資料庫、大表進行分割，可以參考我的《分庫分表》，以便實施更好的控制和管理。
同時建立多個服務執行個體，使用多台服務機進行CPU、記憶體、存儲的分攤，提供更好的性能。
1、複雜性高：由于是一個單體的系統，是以整個系統的子產品是耦合在一起的，子產品的邊界比較模糊、依賴關系錯綜複雜。功能的調整，容易帶來不可知的影響和潛在的bug風險。
2、服務性能問題：單體系統遇到性能瓶頸問題，隻能橫向擴充，增加服務執行個體，進行負載均衡分擔壓力。無法縱向擴充，做子產品拆分。
3、擴縮容能力受限：單體應用隻能作為一個整體進行擴充，影響範圍大，無法根據業務子產品的需要進行單個子產品的伸縮。
4、無法做故障隔離：當所有的業務功能子產品都聚集在一個程式集當中，如果其中的某一個小的功能子產品出現問題（如某個請求堵塞），那麼都有可能會造成整個系統的崩潰。
5、釋出的影響範圍較大：每次釋出都是整個系統進行釋出，釋出會導緻整個系統的重新開機，對于大型的綜合系統挑戰比較大，如果将各個子產品拆分，哪個部分做了修改，隻釋出哪個部分所在的子產品即可。
1、系統的簡易性：系統語言風格、業務結構，接口格式均具有一緻性，服務都是耦合在一起的，不存在各個業務通信問題。
2、易于測試：單體應用一旦部署，所有的服務或特性就都可以使用了，簡化了測試過程，無需額外測試服務間的依賴，測試均可在部署完成後開始。
3、易于部署與更新：相對于微服務架構中的每個服務獨立部署，單體系統隻需将單個目錄下的服務程式統一部署和更新。
4、較低的維護成本：隻需維護單個系統即可。運維主要包括配置、部署、監控與告警和日志收集四大方面。相對于單體系統，微服務架構中的每個服務都需要獨立地配置、部署、監控和日志收集，成本呈指數級增長。
EUREKA的注冊中心逐漸被ZooKeeper和Nacos等替代了。
微服務是一種架構模式，是面向服務的體系結構（SOA）軟體架構模式的一種演變，
它提倡将單一應用程式劃分成一組松散耦合的細粒度小型服務，輔助輕量級的協定，互相協調、互相配合，為使用者提供最終價值。
是以，微服務（或微服務架構）是一種雲原生架構方法，其中單個應用程式由許多松散耦合且可獨立部署的較小元件或服務組成。這些服務通常包含如下特點：
微服務架構中的每個節點高度服務化，都是具有業務邏輯的，符合高内聚、低耦合原則以及單一職責原則的單元，包括資料庫和資料模型；
不同的服務通過“管道”的方式靈活組合，進而建構出龐大的系統。
通過REST API模式或者RPC架構，實作服務間互相協作的輕量級通信機制。
在微服務架構中，每個服務都是獨立的業務單元，與其他服務高度解耦，隻需要改變目前服務本身，就可以完成獨立的開發、測試、部署、運維。
在微服務架構中，應用程式由多個服務組成，每個服務都是高度自治的獨立業務實體，可以運作在獨立的程序中，不同的服務能非常容易地部署到不同的主機上，實作高度自治和高度隔離。
程序的隔離，還能保證服務達到動态擴縮容的能力，業務高峰期自動增加服務資源以提升并發能力，業務低谷期則可自動釋放服務資源以節省開銷。
團隊可以為不同的服務元件使用不同的技術棧和不同的部署方式（公有雲、私有雲、混合雲）。
元件可以彼此獨立地進行擴縮容和治理，進而減少了因必須縮放整個應用程式而産生的浪費和成本，因為單個功能可能面臨過多的負載。
從架構上對運維提供友好的支撐，在安全、可維護的基礎上規範化釋出流程，支援資料存儲容災、業務子產品隔離、通路權限控制、編碼安全檢測等。
我們前面已經了解了微服務的概念，通過百度指數可以看出，從2012年之後，微服務的發展有顯著的發展趨勢。
目前業内的微服務相關開發平台和架構還是比較多的，比如較早的Spring Cloud（使用Eureke做服務注冊與發現，Ribbon做服務間負載均衡，Hystrix做服務容錯保護），
阿裡的Dubbo，微軟的.Net體系微服務架構 Service Fabric，再到後來進階的服務網格(Service Mesh,如 Istio、Linkerd）。
那從12年開始到現在，微服務到底發展到哪個階段了，在各個階段的進階過程中，又有哪些的變化。是以我們需要了解微服務技術的曆史發展脈絡。
下面的内容參考了 Phil Calçado的文章《Pattern: Service Mesh》，從開發者的視角，詳細分析了從微服務到Service Mesh技術的演進過程，這邊做了進一步的整理和總結。
這是最初的模樣，開發人員最開始的時候想象的兩個服務間簡單的通信模式，抽象表示如下，兩個服務之間直接進行通信：
上面的方式非常簡單，但實際情況遠比想象的複雜很多，通信需要底層位元組碼傳輸和電子信号的實體層來完成，在TCP協定出現之前，
服務需要自己處理網絡通信所面臨的丢包、錯誤、亂序、重試等一系列流控問題，是以服務實作中，除了業務邏輯外，還包含對網絡傳輸問題的處理邏輯。
TCP協定的出現，避免了每個服務自己實作一套相似的網絡傳輸處理邏輯，解決網絡傳輸中通用的流量控制問題。
這時候我們把處理網絡傳輸的能力下沉，從服務的實作中抽離出來，成為作業系統網絡層的一部分。
TCP出現之後，服務間的網絡通信已經不是一個難題了，是以 GFS/BigTable/MapReduce 為代表的分布式系統得到了蓬勃的發展。
這時，分布式系統特有的通信語義又出現了，如服務注冊與發現、負載均衡、熔斷降級政策、認證和授權、端到端trace、日志與監控等，是以根據業務需求,完成一些通信語義的實作。
為了避免每個服務都需要自己實作一套分布式系統通信的語義功能，随着技術的發展，一些面向微服務架構的通用開發架構出現了，如Twitter的Finagle、Facebook的Proxygen以及Spring Cloud等，
這些架構實作了分布式系統通信需要的各種通用語義功能：如負載均衡和服務發現等，是以一定程度上屏蔽了這些通信細節，使得開發人員使用較少的架構代碼就能開發出健壯的分布式系統。
上面的第二代微服務架構目前看着挺完美了，但整套微服務架構其實是很複雜的，比如Spring Cloud，聚合了很多元件。是以在實踐過程中，會發現有如下諸多問題：
侵入性強。想要內建SDK的能力，除了需要添加相關依賴，業務層中入侵的代碼、注解、配置，與治理層界限不清晰。
更新成本高。每次更新都需要業務應用修改SDK版本，重新進行功能回歸測試，并對每一台服務進行部署上線，與快速疊代開發相悖。
版本碎片化嚴重。由于更新成本高，而中間件版本更新快，導緻線上不同服務引用的SDK版本不統一、能力參差不齊，造成很難統一治理。
中間件演變困難。由于版本碎片化嚴重，導緻中間件向前演進的過程中就需要在代碼中相容各種各樣的老版本邏輯，帶着"枷鎖”前行，無法實作快速疊代。
内容多、門檻高。依賴元件多，學習成本高，即使通用分布式系統屏蔽了很多的實作細節，我們引入微服務架構并熟練使用也是要花費巨大的精力的。
治理功能不全。不同于RPC架構，SpringCloud作為治理全家桶的典型，也不是萬能的，諸如協定轉換支援、多重授權機制、動态請求路由、故障注入、灰階釋出等進階功能并沒有覆寫到。
無法實作真正意義上的語言無關性。提供的架構一般隻支援一種或幾種語言，要将架構不支援的語言研發的服務也納入微服務架構中，是比較有難度的。
是以，第一代微服務架構 Service Mesh就産生了，它作為一個基礎設施層，能夠與業務解耦，主要解決複雜網絡拓撲下微服務與微服務之間的通信，其實作形态一般為輕量級網絡代理，并與應用以邊車代理（SideCar）模式部署，同時對業務應用透明。
SideCar将分布式服務的通信抽象為單獨一層，需要和服務部署在一起，接管服務的流量，通過代理之間的通信間接完成服務之間的通信請求。
是以在這一層中它能夠實作負載均衡、服務發現、認證授權、監控追蹤、流量控制等分布式系統所需要的功能。
如果我們從一個全局視角來看，綠色的為應用服務，藍色的為SideCar，就會得到如下部署圖：
如果我們省略去服務，隻看Service Mesh的代理邊車的網格應該是這樣的：
流量經過的時候，會先被代理邊車所劫持，然後再進入服務，是以它就是一個由若幹服務代理所組成的錯綜複雜的網格。
第一代Service Mesh由一系列獨立運作的單機代理服務構成，為了提供統一的上層運維入口，演化出了集中式的控制台，我們稱之為控制面（control plane）。
控制面和所有的資料面（data plane，即代理邊車）進行互動，比如政策下發、資料采集等。這就是以Istio為代表的第二代Service Mesh。
隻包含控制面和資料面的 Service Mesh 服務網格全局結構圖 如下：
從上面的結構圖可以看出，Service Mesh 的基礎設施層主要分為兩部分：控制平面與資料平面。目前流行的開源服務網格 Istio 和 Linkerd 都是這種構造。
控制平面的特點：
不直接解析資料包。
與控制平面中的代理通信，下發政策和配置。
負責網絡行為的可視化。
通常提供 API 或者指令行工具可用于配置版本化管理，便于持續內建和部署。
資料平面的特點：
通常是按照無狀态目标設計的，但實際上為了提高流量轉發性能，需要緩存一些資料，是以無狀态也是有争議的。
直接處理入站和出站資料包，轉發、路由、健康檢查、負載均衡、認證、鑒權、産生監控資料等。
對應用來說透明，即可以做到無感覺部署。
到這一步我們大概了解了微服務架構的演進過程，也初步了解Service Mesh技術比較于傳統的微服務架構有哪些優勢。
架構與思維·公衆号：撰稿者為bat、位元組的幾位高階研發/架構。不做廣告、不賣課、不要打賞，隻分享優質技術
碼字不易，歡迎關注，歡迎轉載
作者：翁智華
出處：https://www.cnblogs.com/wzh2010/
本文采用「CC BY 4.0」知識共享協定進行許可，轉載請注明作者及出處。