引入服務網格
背景
去年年底的時候，靜兒在團隊會議中提出了自己的對整個服務將來的規劃。靜兒心裡明白自己的架構設想是可實現的，但是遠超目前的架構。被質疑無法落地。於是靜兒將一些概念的東西全都拋去，直接針對具體的專案做領域拆分。專案也在一點點像靜兒原來規劃的演進。
靜兒認為這個不做管理的一個好處：「對技術的挑戰要大的多。」經常很多東西后來被證明是對的，但是當時因為沒有辦法說服別人走了很多彎路。在一個好的團隊，很多人都有自己的想法，想說服別人很難。一個很開放的管理者也很難去在自己有一個想法，別人有一個想法的時候從自己的思路從脫離出來按照別人的方法去思考和實施。
其實團隊中看似不同的想法其實仔細去想會有很多共性。需要去發掘這些共性，發現不同的想法實際上並不是完全的背離的。仔細去梳理，可能會發現最終的目的地是一樣的，過程也可以是大家都滿意的。
在新版架構中，靜兒提出了具體模組的領域劃分，得到大家的認可：這樣劃分確實是更合理的。靜兒自己設計開發了其中幾個模組之後，又提出了更大的概念：整個排程平臺可以劃分為排程(動態的)和資源(靜態的)兩個大模組。再在底層劃分領域，形成4層的樹形領域結構。這個思想慢慢也在得到大家的認同。最終，從設計標準上，架構是在向服務網格方向發展的。
什麼是服務網格
服務網格定義
服務網格(service mesh)是面向基礎設施層的，作用是讓服務間（尤其是雲原生應用這樣複雜的服務）的通訊安全、快速和可靠。
雲原生定義
雲原生(cloud native)是一種構建和執行應用程式的方法，意味著應用程式位於雲中，而不是傳統資料中心。2015年Linux基金會推出了雲原生應用基金會(CNCF)，CNCF將雲原生定義為使用軟體堆疊進行容器化，其中應用程式的每個部分都打包在自己的容器中，動態編排，以便每個部分都被主動排程和管理，已優化資源利用率和麵向微服務的應用程式，以提高應用程式的整體靈活性和可維護性。
服務網格和雲原生是什麼關係
結合起來是一個比較好的事件，特別是CNCF推薦的實踐。但是也可以不結合獨立實現。
服務網格和微服務架構是什麼關係
微服務架構是一個理念，到底自己的專案是不是微服務風格的，自己只要能自圓其說就可以。服務網格是有一些基礎設施組成的，更具體。
微服務更偏向於領域的拆分，而服務網格側重於解決的模組之間的通訊。
自己專案中有沒有必要使用服務網格
首先服務網格起源於Linkerd，現在比較火的是Istio。它們是希望提供一個自上而上的服務網格解決方案。裡面提的理念都很好，但是現實中總是會遇到各種問題。不建議對穩定性要求很高的專案接入嘗試。穩定性的要務之一：「不當小白鼠。」
而對於很多大公司，事實上做著與服務網格異曲同工的事情，舉個大家相對比較熟悉的東西：服務治理。靜兒在 《美團分散式服務通訊框架及服務治理系統OCTO 》 裡也提到OCTO正在和靜兒所在的HULK團隊做更深度的合作，靜兒自己的觀點：事實上在自下而上的打造著「服務網格」。
標準服務網格中的幾個基礎設施
Sidecar（挎鬥）模式
Sidecar模式是一種將應用功能從應用本身剝離出來作為單獨程序的方式。該模式允許我們嚮應用無侵入新增多種功能，避免了為滿足第三方元件需求而嚮應用新增額外的配置程式碼。
舉個栗子:chestnut:：
靜兒在 《美團分散式服務通訊框架及服務治理系統OCTO》 裡提到sg_agent作為獨立本地程序放到客戶端為客戶端提供路由策略等服務，這本質上可以作為一種Sidecar模式的實現。
Data Plane（資料平面）
Data Plane原始的意思是：用來將路由器的資料包從input送到output（forwarding）。在服務網格中的作用是處理網格內服務間的通訊，並完成服務發現、負載均衡、流量管理、健康檢查等功能。
Control Plane（控制平面）
Control Plane原始的意思是：用於將資料包從一個路由器發到另一個路由器（Routing）。在服務網格中 的作用是管理和配置Sidecar、執行側率並收集監控等資料。
Data Plane和Control Plane都可以在服務治理當中找到對標。
總結
不要在盒子外面思考，要找到盒子 --《程式設計師修煉之道》
相關閱讀