雲原生從字面意思上來看能夠分紅雲和原生兩個部分。 雲是和本地相對的，傳統的應用必須跑在本地服務器上，如今流行的應用都跑在雲端，包含IaaS、PaaS和SaaS。 原生就是土生土長的意思，咱們在開始設計應用的時候就考慮到應用未來是運行雲環境裏面的，要充分利用雲資源的優勢，好比️雲服務的彈性和分佈式優點。點擊這裏瞭解更多前端
那具體要怎麼利用呢，請參考下圖： 
因此，能夠簡單的將雲原生理解爲：雲原生 = 微服務 + DevOps + 持續交付 + 容器化web
#1、什麼是南北流量和東西流量算法
南北流量（NORTH-SOUTH traffic）和東西流量（EAST-WEST traffic）是數據中心環境中的網絡流量模式。 假設咱們嘗試經過瀏覽器訪問某些Web應用。Web應用部署在位於某個數據中心的應用服務器中。在多層體系結構中，典型的數據中心不只包含應用服務器，還包含其餘服務器，如負載均衡器、數據庫等，以及路由器和交換機等網絡組件。假設應用服務器是負載均衡器的前端。點擊這裏瞭解更多數據庫
當咱們訪問web應用時，會發生如下類型的網絡流量： ——客戶端（位於數據中心一側的瀏覽器）與負載均衡器（位於數據中心）之間的網絡流量 ——負載均衡器、應用服務器、數據庫等之間的網絡流量，它們都位於數據中心。 在這個例子中，前者即客戶端和服務器之間的流量被稱爲南北流量。簡而言之，南北流量是server-client流量。不一樣服務器之間的流量與數據中心或不一樣數據中心之間的網絡流被稱爲東西流量。簡而言之，東西流量是server-server流量。後端
當下，東西流量遠超南北流量，尤爲是在當今的大數據生態系統中，好比Hadoop生態系統（大量server駐留在數據中心中，用map reduce處理），server-server流量遠大於server-client流量。點擊這裏瞭解更多瀏覽器
#2、什麼是Service mesh 一言以蔽之：Service Mesh是微服務時代的TCP協議。 時代0：開發人員想象中，不一樣服務間通訊的方式，抽象表示以下： 緩存
時代1：原始通訊時代 然而現實遠比想象的複雜，在實際狀況中，通訊須要底層可以傳輸字節碼和電子信號的物理層來完成，在TCP協議出現以前，服務須要本身處理網絡通訊所面臨的丟包、亂序、重試等一系列流控問題，所以服務實現中，除了業務邏輯外，還夾雜着對網絡傳輸問題的處理邏輯。 安全
時代2：TCP時代 爲了不每一個服務都須要本身實現一套類似的網絡傳輸處理邏輯，TCP協議出現了，它解決了網絡傳輸中通用的流量控制問題，將技術棧下移，從服務的實現中抽離出來，成爲操做系統網絡層的一部分。 服務器
時代3：第一代微服務 在TCP出現以後，機器之間的網絡通訊再也不是一個難題，以GFS/BigTable/MapReduce爲表明的分佈式系統得以蓬勃發展。這時，分佈式系統特有的通訊語義又出現了，如熔斷策略、負載均衡、服務發現、認證和受權、quota限制、trace和監控等等，因而服務根據業務需求來實現一部分所需的通訊語義。 網絡
時代4：第二代微服務 爲了不每一個服務都須要本身實現一套分佈式系統通訊的語義功能，隨着技術的發展，一些面向微服務架構的開發框架出現了，如Twitter的Finagle、Facebook的Proxygen以及Spring Cloud等等，這些框架實現了分佈式系統通訊須要的各類通用語義功能：如負載均衡和服務發現等，所以必定程度上屏蔽了這些通訊細節，使得開發人員使用較少的框架代碼就能開發出健壯的分佈式系統。點擊這裏瞭解更多
時代5：第一代Service Mesh 第二代微服務模式看似完美，但開發人員很快又發現，它也存在一些本質問題： 其一，雖然框架自己屏蔽了分佈式系統通訊的一些通用功能實現細節，但開發者卻要花更多精力去掌握和管理複雜的框架自己，在實際應用中，去追蹤和解決框架出現的問題也絕非易事； 其二，開發框架一般只支持一種或幾種特定的語言，回過頭來看文章最開始對微服務的定義，一個重要的特性就是語言無關，但那些沒有框架支持的語言編寫的服務，很難融入面向微服務的架構體系，想因地制宜的用多種語言實現架構體系中的不一樣模塊也很難作到； 其三，框架以lib庫的形式和服務聯編，複雜項目依賴時的庫版本兼容問題很是棘手，同時，框架庫的升級也沒法對服務透明，服務會由於和業務無關的lib庫升級而被迫升級； 所以以Linkerd，Envoy，Ngixmesh爲表明的代理模式（邊車模式）應運而生，這就是第一代Service Mesh，它將分佈式服務的通訊抽象爲單獨一層，在這一層中實現負載均衡、服務發現、認證受權、監控追蹤、流量控制等分佈式系統所須要的功能，做爲一個和服務對等的代理服務，和服務部署在一塊兒，接管服務的流量，經過代理之間的通訊間接完成服務之間的通訊請求，這樣上邊所說的三個問題也迎刃而解。點擊這裏瞭解更多 若是咱們從一個全局視角來看，就會獲得以下部署圖： 若是咱們暫時略去服務，只看Service Mesh的單機組件組成的網絡： 相信如今，你們已經理解何所謂Service Mesh，也就是服務網格了。它看起來確實就像是一個由若干服務代理所組成的錯綜複雜的網格。
時代6：第二代Service Mesh 第一代Service Mesh由一系列獨立運行的單機代理服務構成，爲了提供統一的上層運維入口，演化出了集中式的控制面板，全部的單機代理組件經過和控制面板交互進行網絡拓撲策略的更新和單機數據的彙報。這就是以Istio爲表明的第二代Service Mesh。 只看單機代理組件(數據面板)和控制面板的Service Mesh全局部署視圖以下： 至此，見證了6個時代的變遷，你們必定清楚了Service Mesh技術究竟是什麼，以及是如何一步步演化到今天這樣一個形態。
如今，咱們再回過頭來看Buoyant的CEO William Morgan，也就是Service Mesh這個詞的發明人，對Service Mesh的定義：
服務網格是一個基礎設施層，用於處理服務間通訊。雲原生應用有着複雜的服務拓撲，服務網格保證請求在這些拓撲中可靠地穿梭。在實際應用當中，服務網格一般是由一系列輕量級的網絡代理組成的，它們與應用程序部署在一塊兒，但對應用程序透明。點擊這裏瞭解更多
這個定義中，有四個關鍵詞： ——基礎設施層+請求在這些拓撲中可靠穿梭：這兩個詞加起來描述了Service Mesh的定位和功能，是否是似曾相識？沒錯，你必定想到了TCP； ——網絡代理：這描述了Service Mesh的實現形態； ——對應用透明：這描述了Service Mesh的關鍵特色，正是因爲這個特色，Service Mesh可以解決以Spring Cloud爲表明的第二代微服務框架所面臨的三個本質問題；
總結一下，Service Mesh具備以下優勢： ——屏蔽分佈式系統通訊的複雜性(負載均衡、服務發現、認證受權、監控追蹤、流量控制等等)，服務只用關注業務邏輯； ——真正的語言無關，服務能夠用任何語言編寫，只需和Service Mesh通訊便可； ——對應用透明，Service Mesh組件能夠單獨升級；
固然，Service Mesh目前也面臨一些挑戰： ——Service Mesh組件以代理模式計算並轉發請求，必定程度上會下降通訊系統性能，並增長系統資源開銷； ——Service Mesh組件接管了網絡流量，所以服務的總體穩定性依賴於Service Mesh，同時額外引入的大量Service Mesh服務實例的運維和管理也是一個挑戰； 歷史老是驚人的類似。爲了解決端到端的字節碼通訊問題，TCP協議誕生，讓多機通訊變得簡單可靠；微服務時代，Service Mesh應運而生，屏蔽了分佈式系統的諸多複雜性，讓開發者能夠迴歸業務，聚焦真正的價值。點擊這裏瞭解更多
#3、要想業務中臺建得快，最好用Service Mesh來帶 如圖是一個簡化的Service Mesh架構，服務A和服務B相互調用，再也不是之前經過微服務框架直接指向的方式，而是在中間加了兩個叫作Sidecar（邊車）的東西，各類服務都在這裏處理數據上的邏輯。Sidecar的做用是數據面的代理，它是更貼近於數據的；而Sidecar不能徹底不受控，上面控制它的就叫作控制面。 實際業務中，尤爲是中臺架構下，企業每每須要不少的微服務，也就是上述服務A、服務B相互調用的狀況會不斷擴展，就會逐漸造成更多的服務加Sidecar的組合，就變成了一個真正意義的Service Mesh。 Service Mesh具備三個明顯的優點：第一它是一個獨立的進程，和業務是解耦的，對業務代碼無侵入；第二，是具有跨語言特性，上文說的Dubbo和Spring Cloud其實都是Java技術棧，而Service Mesh具有整合一些C++、Golang之類的異構語言應用的能力，由於它沒有進入到進程內；第三是它提供了熔斷、限流等豐富的微服務服務治理功能。 這些優點，使得Service Mesh能夠比較容易地解決中臺架構下微服務化存在的問題。對於使用採購或外包模式的傳統企業尤爲如此。傳統企業每每須要將後臺的應用進行封裝或者重構爲中颱，來支撐前臺靈活的業務變化，自研系統還能夠採用Spring Cloud來重構，但採購的系統只能使用封裝的模式，而採購的不一樣系統通常採用.Net、Spring MVC、PHP、Python等不一樣的技術棧，若是沒有Service Mesh，接入微服務體系就會是一場噩夢。點擊這裏瞭解更多
#4、實施Service Mesh的技術方案 主流雲原生Service Mesh框架是Istio，Istio提供了完整的Service Mesh的解決方案，數據面是一個叫Envoy的組件，控制面的組件包括Pilot、Mixer、Citadel和Galley等。在下圖服務A調用服務B的流程中，支持這種調用的Sidecar就是用Envoy組件來實現的，下半部分是控制面的組件，最主要的是Pilot，其餘是配合功能完整性的一些組件。 先看數據面核心組件Envoy。數據面跟微服務自己相關性很是大的，由於全部的流量以及大部分治理都須要通過它。 七大優點：第一，它是基於現代C++開發的網絡L4/L7的代理，這意味着它可以提供很高的性能。 第二是流量管理，Envoy能夠對服務流量作路由、分流等動態的管理。 第三是服務治理方面的特性，包括熔斷、限流，以及在裏面注入一些故障。 第四是多協議支持，Envoy除了支持比較經典的HTTP 1.x版本，還支持2.x版本，也支持gRPC、TCP、Web Socket等。它不只能夠對服務之間調用的流量進行管理，一些DB、緩存其實也能夠作到，由於它是網絡4-7層的。 第五是負載均衡，Envoy支持的算法很是多。 第六是動態配置API，做爲一個數據面應該有接口能夠動態去控制，讓控制面來調用配置。 第七是可觀察性設計，做爲一個數據面應該把通過它的流量和數據上報，讓後端更龐大的監控系統看到整個微服務體系究竟是一個怎樣的狀態。最後是支持自定義插件擴展能力的，企業對Envoy自己的功能若是不知足，還能夠經過插件進行擴展。點擊這裏瞭解更多
Istio的控制面核心組件是Pilot，它最主要的功能是和Sidecar創建雙向的gRPC鏈接，能夠經過控制面實時下發配置或是服務發現的信息，包括服務發現和抽象，以及配置的轉化和分發。 另外三個組件，Mixer主要是作策略檢查跟遙測，包括檢查一些權限，或者經過它上報監控數據。Citadel負責安全性方面，能夠作證書與祕鑰管理相關的分發。Galley是1.1版本正式引入的，主要作配置校驗。這些組件中，業界詬病最多的是Mixer作策略檢查操做的時候會有性能問題。點擊這裏瞭解更多
※更多文章和資料|點擊後方文字直達 ↓↓↓ 100GPython自學資料包 阿里雲K8s實戰手冊 [阿里雲CDN排坑指南]CDN ECS運維指南 DevOps實踐手冊 Hadoop大數據實戰手冊 Knative雲原生應用開發指南 OSS 運維實戰手冊 雲原生架構白皮書