引入服務網格

背景程序員

去年年末的時候,靜兒在團隊會議中提出了本身的對整個服務未來的規劃。靜兒內心明白本身的架構設想是可實現的,可是遠超目前的架構。被質疑沒法落地。因而靜兒將一些概念的東西全都拋去,直接針對具體的項目作領域拆分。項目也在一點點像靜兒原來規劃的演進。安全

靜兒認爲這個不作管理的一個好處:「對技術的挑戰要大的多。」常常不少東西后來被證實是對的,可是當時由於沒有辦法說服別人走了不少彎路。在一個好的團隊,不少人都有本身的想法,想說服別人很難。一個很開放的管理者也很難去在本身有一個想法,別人有一個想法的時候從本身的思路從脫離出來按照別人的方法去思考和實施。架構

其實團隊中看似不一樣的想法其實仔細去想會有不少共性。須要去發掘這些共性,發現不一樣的想法實際上並非徹底的背離的。仔細去梳理,可能會發現最終的目的地是同樣的,過程也能夠是你們都滿意的。併發

在新版架構中,靜兒提出了具體模塊的領域劃分,獲得你們的承認:這樣劃分確實是更合理的。靜兒本身設計開發了其中幾個模塊以後,又提出了更大的概念:整個調度平臺能夠劃分爲調度(動態的)和資源(靜態的)兩個大模塊。再在底層劃分領域,造成4層的樹形領域結構。這個思想慢慢也在獲得你們的認同。最終,從設計標準上,架構是在向服務網格方向發展的。負載均衡

 

什麼是服務網格框架

服務網格定義分佈式

服務網格(service mesh)是面向基礎設施層的,做用是讓服務間(尤爲是雲原生應用這樣複雜的服務)的通訊安全、快速和可靠。ide

雲原生定義微服務

雲原生(cloud native)是一種構建和運行應用程序的方法,意味着應用程序位於雲中,而不是傳統數據中心。2015年Linux基金會推出了雲原生應用基金會(CNCF),CNCF將雲原生定義爲使用軟件堆棧進行容器化,其中應用程序的每一個部分都打包在本身的容器中,動態編排,以便每一個部分都被主動調度和管理,已優化資源利用率和麪向微服務的應用程序,以提升應用程序的總體靈活性和可維護性。高併發

服務網格和雲原生是什麼關係

結合起來是一個比較好的事件,特別是CNCF推薦的實踐。可是也能夠不結合獨立實現。

服務網格和微服務架構是什麼關係

微服務架構是一個理念,到底本身的項目是否是微服務風格的,本身只要能自圓其說就能夠。服務網格是有一些基礎設施組成的,更具體。

微服務更偏向於領域的拆分,而服務網格側重於解決的模塊之間的通訊。

 

本身項目中有沒有必要使用服務網格

首先服務網格起源於Linkerd,如今比較火的是Istio。它們是但願提供一個自上而上的服務網格解決方案。裏面提的理念都很好,可是現實中老是會遇到各類問題。不建議對穩定性要求很高的項目接入嘗試。穩定性的要務之一:「不當小白鼠。」

而對於不少大公司,事實上作着與服務網格殊途同歸的事情,舉個你們相對比較熟悉的東西:服務治理。靜兒在《美團分佈式服務通訊框架及服務治理系統OCTO》裏也提到OCTO正在和靜兒所在的HULK團隊作更深度的合做,靜兒本身的觀點:事實上在自下而上的打造着「服務網格」。

 

標準服務網格中的幾個基礎設施

Sidecar(挎鬥)模式

Sidecar模式是一種將應用功能從應用自己剝離出來做爲單獨進程的方式。該模式容許咱們嚮應用無侵入添加多種功能,避免了爲知足第三方組件需求而嚮應用添加額外的配置代碼。

舉個栗子🌰:

靜兒在《美團分佈式服務通訊框架及服務治理系統OCTO》裏提到sg_agent做爲獨立本地進程放到客戶端爲客戶端提供路由策略等服務,這本質上能夠做爲一種Sidecar模式的實現。

Data Plane(數據平面)

Data Plane原始的意思是:用來將路由器的數據包從input送到output(forwarding)。在服務網格中的做用是處理網格內服務間的通訊,並完成服務發現、負載均衡、流量管理、健康檢查等功能。

Control Plane(控制平面)

Control Plane原始的意思是:用於將數據包從一個路由器發到另外一個路由器(Routing)。在服務網格中的做用是管理和配置Sidecar、執行側率並收集監控等數據。

Data Plane和Control Plane均可以在服務治理當中找到對標。

 

總結

不要在盒子外面思考,要找到盒子  --《程序員修煉之道》

相關閱讀     

《程序經常使用的設計技巧》

《到底多大才算高併發?》

《美團分佈式服務通訊框架及服務治理系統OCTO》

《學會用數聽說話-分佈式鎖究竟能夠多少併發?》

《大話高可用》

《業務開發轉基礎開發,這三種「高可用」架構你會麼?》

 

相關文章
相關標籤/搜索