引入服務網格

時間 2019-11-18

標籤引入服務網格简体版

原文原文鏈接

背景程序員

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

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

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

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

什麼是服務網格框架

服務網格定義分佈式

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

雲原生定義微服務

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

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

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

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

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

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

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

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

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

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

Sidecar（挎鬥）模式

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

舉個栗子🌰：