Rethink：爲什麼微服務沒有sidecar不行？

{"type":"doc","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#333333","name":"user"}}],"text":"作者 | 蔡芳芳"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#333333","name":"user"}}],"text":"採訪嘉賓 | 蔡書"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":" "}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":"幾乎是隨着Service Mesh概念的普及，“sidecar”這個詞被容器從業者提到的頻率也越來越高。甚至可以說，sidecar proxy已經是Service Mesh的第一技術特徵。今天我們就和"},{"type":"link","attrs":{"href":"https:\/\/flomesh.cn","title":null,"type":null},"content":[{"type":"text","text":"Flomesh"}],"marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}]},{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":"團隊負責人蔡書一起來聊聊爲什麼會出現sidecar proxy，以及除了proxy還有哪些sidecar，最後展望一下“理想化”的sidecar應該是什麼樣子。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":" "}]},{"type":"blockquote","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#a5a5a5","name":"user"}}],"text":"Rethink系列回顧："},{"type":"link","attrs":{"href":"https:\/\/www.infoq.cn\/article\/WAEV0NbRUVHqLhTPtcKI","title":null,"type":null},"content":[{"type":"text","text":"《Istio 之外，我們需要什麼樣的服務網格？》"}]}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":" "}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#333333","name":"user"}},{"type":"strong"}],"text":"InfoQ：能否先簡單解釋下什麼叫sidecar？"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":" "}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#333333","name":"user"}},{"type":"strong"}],"text":"蔡書："},{"type":"text","marks":[{"type":"color","attrs":{"color":"#333333","name":"user"}}],"text":"Sidecar本意是指三輪摩托旁邊的那個挎鬥。Kubernetes在形成初期，就把“容器”這個模型演化成了“pod”模型。Pod就是多個容器“編組使用”，或者簡單地說，如果把一個“pod”類比成一個“虛擬機”，那麼多個容器就是這個虛擬機裏邊的多個進程。這些進程裏邊，那些配合業務進程的其他進程我們一般就稱爲sidecar。比如pod運行的是一個Spring Boot的進程，在這個pod裏邊我們部署了採集日誌的Filebeat進程，部署了代理流量的proxy進程，那麼這個採集日誌和代理進程都叫做“sidecar”。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":" "}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#333333","name":"user"}}],"text":"在sidecar這個說法被廣泛使用之前，其實sidecar這種用法就已經被普遍使用了，比如上邊例子說的有些容器玩家會在容器內部署採集日誌的進程。但是sidecar這個叫法是隨着Service Mesh出現而流行起來的。在幾乎所有討論Serivce Mesh的材料和文章中都會出現sidecar這個詞，如果從自然語言分析角度看，“Service Mesh”和“sidecar”是關聯度極高的兩個詞彙。事實上，和Service Mesh一起說的sidecar，是“sidecar proxy”的一個簡化說法。所以當討論的上下文是“Service Mesh”的時候，說到“sidecar”，一般就是指“sidecar proxy”。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":" "}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#333333","name":"user"}},{"type":"strong"}],"text":"InfoQ：這麼說sidecar其實不算是個新事物了～"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":" "}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#333333","name":"user"}},{"type":"strong"}],"text":"蔡書："},{"type":"text","marks":[{"type":"color","attrs":{"color":"#333333","name":"user"}}],"text":"雖然這個詞彙是最近幾年隨着服務網格開始在容器圈流行，但是sidecar模式其實早就存在，甚至可以說從操作系統進入了“多任務”以後就出現了。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":" "}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#333333","name":"user"}},{"type":"strong"}],"text":"InfoQ：能詳細說說sidecar的歷史淵源嗎？"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":" "}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#333333","name":"user"}},{"type":"strong"}],"text":"蔡書："},{"type":"text","marks":[{"type":"color","attrs":{"color":"#333333","name":"user"}}],"text":"這個話題非常有趣，我試着從三個方面聊下，一個是操作系統，一個是應用服務器，一個是容器時代的pod，他們之間內在有時間上的先後順序，邏輯上他們的模型也有共性之處。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":" "}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#333333","name":"user"}}],"text":"這裏先做一個假設，就是我的目標是運行一個“業務程序”，比如一個SpringBoot的Java程序，當啓動這個SpringBoot程序的時候，我需要用Java springboot.jar之類的命令來啓動這個進程。在典型的Linux上，通常我們會把這個命令包裝到一個腳本里邊，用類似start-springboot.sh之類的腳本來啓動。事實上，在我們啓動這個Java進程之前，就有很多進程在運行了，典型的比如說監控進程，比如zabbix agent；還有比如日誌收集的進程，比如filebeat，等等。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":" "}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#333333","name":"user"}}],"text":"其實除了這些大家常見的進程，還有一些大家可能未必留意的進程，也在運行了。典型的比如crond，大家都用crontab做一些定時任務，crond進程就是管理這個的。記得以前常常有用戶問我們“能不能給我一個最小最乾淨的操作系統”，其實他指的就是在運行業務進程的時候，只有最少的其他進程在運行。這些“其他進程”，從邏輯模型看，都可以認爲是業務進程的sidecar。從功能的角度來說，我們會發現，這些sidecar進程可以分爲幾類，一類是輔助業務的，比如定時任務；一類是管理員需要的，比如日誌採集、監控；一類是系統本身需要的，操作系統在啓動內核後，會啓動一個“超級進程”，稱爲initd進程，後來的systemd進程是initd的替代品，這個超級進程會啓動一些進程用來輔助操作系統的功能，最典型的比如kdump，用來在程序崩潰時候收集信息。概括地說，早期使用單機操作系統運行業務進程的時候，我們有三類“sidecar”，#1是業務自身需要的，#2是管理員需要的，#3是操作系統需要的。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":" "}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#333333","name":"user"}}],"text":"說完操作系統，我們再說應用服務器。千禧年之後，隨着Java進入企業領域，也就是當時的J2EE，應用服務器開始普及。以Java應用服務器來說（事實上幾乎各種語言都有自己的“應用服務器”），應用服務器有自己的啓動過程，在這個過程中，應用服務器會啓動很多“線程”，這些線程也是輔助完成業務邏輯或者實現管理功能的，他們的本質也是sidecar。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":" "}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#333333","name":"user"}}],"text":"進入容器時代以後，尤其是K8s提出pod的概念，圍繞業務進程的輔助進程模式更加清晰和明確，這些輔助進程就是sidecar。同樣，這些sidecar也還是完成着傳統的三方面功能，一方面是輔助業務的；一方面是面向管理員的；一方面是面向系統的。容器環境是典型的雲環境，所以這裏的“面向管理員”和“面向系統”又有了新的含義和進一步的需求。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":" "}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#333333","name":"user"}},{"type":"strong"}],"text":"InfoQ：感覺當前對於Service Mesh、微服務，甚至可以擴大到雲原生，似乎都是沒有sidecar不行？爲什麼sidecar這麼重要？"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":" "}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#333333","name":"user"}},{"type":"strong"}],"text":"蔡書：說“沒有sidecar不行”不如說“sidecar的普遍使用是客觀現實，是剛需”"},{"type":"text","marks":[{"type":"color","attrs":{"color":"#333333","name":"user"}}],"text":"。這種剛需的產生我覺得有這麼幾個因素，一個是不同角色需要不同能力的進程協助完成工作，比如業務進程、應用運維、系統運維，彼此工作的和角色的差異，導致了每個角色用自己的sidecar輔助進程是一種分工，也是一種清晰的工作邊界。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":" "}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#333333","name":"user"}}],"text":"另一方面，有些需求是在業務上線後出現的，那麼這個時候，用一個附加的sidecar進程完成管理工作就很順理成章。還有一點，進程是現代Unix和類Unix系統的基本管理單位，進程級的管理是非常成熟的技術。作爲一個對比，其實上一代應用服務器，比如JEE應用服務器，嘗試把很多輔助管理能力放到線程級，但是後來又都逐漸分離到外部進程了。所謂“一個快速、簡潔的Java進程”。這些客觀的需求，使得sidecar輔助進程成爲一種剛需。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":" "}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#333333","name":"user"}},{"type":"strong"}],"text":"InfoQ：使用sidecar模式的優勢是什麼？"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":" "}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#333333","name":"user"}},{"type":"strong"}],"text":"蔡書："},{"type":"text","marks":[{"type":"color","attrs":{"color":"#333333","name":"user"}}],"text":"就像上一個問題裏說到的，sidecar輔助進程的出現很多時候是順理成章、水到渠成的，是一種最佳選擇。簡單來說，sidecar本質就是分而治之，並且天然具有“分工”的屬性，還可以用來解決很多“上線時候還沒有的管理需求”，扮演了管理上的補丁角色。從sidecar proxy的角度看，proxy提供一種“切片管理”的能力，這個是非常經典的設計模式。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":" "}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#333333","name":"user"}},{"type":"strong"}],"text":"InfoQ：前面回顧sidecar歷史淵源的時候，您最後提到容器環境帶來的“新的含義和進一步需求”，這個怎麼理解？能不能具體說說？"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":" "}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#333333","name":"user"}},{"type":"strong"}],"text":"蔡書："},{"type":"text","marks":[{"type":"color","attrs":{"color":"#333333","name":"user"}}],"text":"容器和K8s的普及，使得“雲”距離用戶更近了一步，這裏，我總結了一些和sidecar相關的技術變化，以及“雲”本身帶來的一些變化。很多時候，我認爲這些變化和特徵也是“雲原生”的特徵和驅動力的一部分。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":" "}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#333333","name":"user"}}],"text":"具體包括這麼幾個部分："}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":" "}]},{"type":"numberedlist","attrs":{"start":null,"normalizeStart":1},"content":[{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":1,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#333333","name":"user"}}],"text":"容器啓動的時候，有一個PID=1的進程。通常而言，這個進程就是“業務進程”（實際上pod啓動還有個init進程，叫做pause）。當我們想啓動sidecar進程的時候，目前的做法是通過hook，在啓動過程中啓動sidecar。實際上，這個時候K8s（或者具體的說Kubelet）其實是一個超級進程，它負責啓動業務進程和sidecar。很多時候，sidecar和業務進程，甚至是sidecar之間，是有啓動順序的。但是目前在K8s的體系內，缺少對這種依賴的管理。如果大家熟悉Linux的initd和systemd，會知道系統的啓動過程是由一堆腳本控制的，也包含了一些優先關係。在操作系統時代，這些sidecar的啓動是個“準標準”，也是可以通過Shell腳本“定製化”的。總結來說："},{"type":"text","marks":[{"type":"color","attrs":{"color":"#333333","name":"user"}},{"type":"strong"}],"text":"pod的init過程在標準化、定製化、擴展方面比較簡單，在一個pod內容器多且有依賴和關聯的時候，當前的機制不夠靈活。所以第一個“新”需求就是pod內多進程的啓動依賴及順序，目前容器平臺沒有提供相應的機制。"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":2,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#333333","name":"user"}}],"text":"容器快速被認可，背後最主要的原因是容器“輕量化”，而輕量化是“敏捷”的前提。當我們需要通過sidecar進程來完成某一種輔助功能的時候，我們需要這個輔助進程儘可能輕量化，否則就會有一種頭重腳輕的感覺。前幾天有個技術分享，提到他們業務容器的資源配置是4C8G，然後sidecar資源配置是4C4G。對這種配置，我只能感慨“有錢真好”。大多數用戶還是希望sidecar是很輕量化的。"},{"type":"text","marks":[{"type":"color","attrs":{"color":"#333333","name":"user"}},{"type":"strong"}],"text":"概括地說，第二個“進階”需求是，pod內的sidecar輔助進程需要比傳統主機上更輕量化。"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":3,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#333333","name":"user"}}],"text":"權限。當我們在虛擬機或者物理機上部署sidecar這些輔助進程的時候，有時候我們需要特權，因爲讀寫一些系統信息需要高權限。在主機（虛擬機、物理機）時代，超級用戶加上業務用戶的兩級權限很好地滿足了不同用戶運行不同進程權限管理的需求。但是在容器時代，這個事情變難了。容器環境裏，除了宿主機的管理（通常是特權用戶）和業務進程（通常是普通用戶）之外，多了這些sidecar輔助進程。這些sidecar輔助進程，有些也需要特權、更多的最好是用普通用戶。相當於在容器環境和pod裏，其實出現了3個等級的權限需求：宿主機的root、容器的“root”、容器的普通用戶。這層權限的出現，本質上是雲的多租戶導致的。目前來看，這個中間層的權限比較難處理，因爲業務進程和輔助sidecar進程是共享namespace的。"},{"type":"text","marks":[{"type":"color","attrs":{"color":"#333333","name":"user"}},{"type":"strong"}],"text":"概括起來，第三個“新”需求是sidecar輔助進程通常要求一種介於宿主機root和業務進程之間的權限能力。"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":4,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#333333","name":"user"}}],"text":"擴展性。主機上傳統的sidecar輔助進程，一般都有自己的配置方式（配置文件格式），以及一些擴展方式，比如zabbix可以運行腳本等。這些傳統的輔助進程進入到容器後，管理其實更難了。之前積累的很多管理工具，可以通過配置工具如ansible之類下發，而容器一般提供的方式是configMap，這種配置和擴展的變化導致了嚴重的碎片化，而且方式改變也帶來了新的困難。Sidecar輔助進程的功能，很多是需要這種客戶化和現場定製化的，這部分需要通用、簡單的擴展機制和方式。"},{"type":"text","marks":[{"type":"color","attrs":{"color":"#333333","name":"user"}},{"type":"strong"}],"text":"因此，第四個“進階”需求是sidecar輔助進程通常需要比傳統主機上更簡單、易用、且強大的擴展能力。"}]}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":" "}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#333333","name":"user"}}],"text":"大概總結這麼幾個，其實還有一些，以後想起來再討論。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":" "}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#333333","name":"user"}},{"type":"strong"}],"text":"InfoQ：針對上面這些問題和需求，業內現在有什麼可行的解決辦法嗎？"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#494949","name":"user"}}],"text":" "}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"color","attrs":{"color":"#333333","name":"user"}},{"type":"strong"}],"text":"蔡書："},{"type":"text","marks":[{"type":"color","attrs":{"color":"#333333","name":"user"}}],"text":"這是個好問題，在我看來，整個行業都發現了這些新問題——就是說，pod里正在被塞進越來越多的sidecar。因此整個行業也都在探索可行的解決辦法。這裏介紹下我們"},{"type":"link","attrs":{"href":"https:\/\/github.com\/flomesh-io\/pipy","title":null,"type":null},"content":[{"type":"text","text":"開源項目pipy"}]},{"type":"text","marks":[{"type":"color","attrs":{"color":"#333333","name":"user"}}],"text":"的探索：我們通過infra container的方式爲每個容器提供了PID=1的sidecar，這個pipy進程類似Linux中的initd或者systemd，它的作用是根據需要引入和執行其他的功能；通過pipy repo和pipy js的能力，pipy可以提供目前我們已經識別的各種sidecar所需要的功能，比如服務註冊\/註銷、服務發現、日誌採集、指標採集、主動健康檢查、定時任務、提供網絡代理（也就是sidecar proxy能力）等。這是一種嘗試，也歡迎大家一起來探討。"}]}]}