背景
去年年底的時候，靜兒在團隊會議中提出了自己的對整個服務將來的規划。靜兒心里明白自己的架構設想是可實現的，但是遠超目前的架構。被質疑無法落地。於是靜兒將一些概念的東西全都拋去，直接針對具體的項目做領域拆分。項目也在一點點像靜兒原來規划的演進。
靜兒認為這個不做管理的一個好處：「對技術的挑戰要大的多。」經常很多東西后來被證明是對的，但是當時因為沒有辦法說服別人走了很多彎路。在一個好的團隊，很多人都有自己的想法，想說服別人很難。一個很開放的管理者也很難去在自己有一個想法，別人有一個想法的時候從自己的思路從脫離出來按照別人的方法去思考和實施。
其實團隊中看似不同的想法其實仔細去想會有很多共性。需要去發掘這些共性，發現不同的想法實際上並不是完全的背離的。仔細去梳理，可能會發現最終的目的地是一樣的，過程也可以是大家都滿意的。
在新版架構中，靜兒提出了具體模塊的領域划分，得到大家的認可：這樣划分確實是更合理的。靜兒自己設計開發了其中幾個模塊之后，又提出了更大的概念：整個調度平台可以划分為調度(動態的)和資源(靜態的)兩個大模塊。再在底層划分領域，形成4層的樹形領域結構。這個思想慢慢也在得到大家的認同。最終，從設計標准上，架構是在向服務網格方向發展的。
什么是服務網格
服務網格定義
服務網格(service mesh)是面向基礎設施層的，作用是讓服務間（尤其是雲原生應用這樣復雜的服務）的通信安全、快速和可靠。
雲原生定義
雲原生(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都可以在服務治理當中找到對標。
總結
不要在盒子外面思考，要找到盒子 --《程序員修煉之道》
相關閱讀
