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