Egg介紹：
Egg 奉行『約定優于配置』，按照一套統一的約定進行應用開發，團隊内部采用這種方式可以減少開發人員的學習成本，開發人員不再是『釘子』，可以流動起來。沒有約定的團隊，溝通成本是非常高的，比如有人會按目錄分棧而其他人按目錄分功能，開發者認知不一緻很容易犯錯。但約定不等于擴充性差，相反 Egg 有很高的擴充性，可以按照團隊的約定定制架構。使用 Loader可以讓架構根據不同環境定義預設配置，還可以覆寫 Egg 的預設約定。
K8s介紹：
Kubernetes是Google開源的一個容器編排引擎，簡稱K8s,它支援自動化部署、大規模可伸縮、應用容器化管理。在生産環境中部署一個應用程式時，通常要部署該應用的多個執行個體以便對應用請求進行負載均衡。在K8s中，我們可以建立多個容器，每個容器裡面運作一個應用執行個體，然後通過内置的負載均衡政策，實作對這一組應用執行個體的管理、發現、通路，而這些細節都不需要運維人員去進行複雜的手工配置和處理。
目前公司某項目使用了egg架構，運維團隊部署該項目使用了k8s叢集，今天出現了一個奇怪的問題，我們的打包後的docker 鏡像，在單獨的ECS上可以正常該服務，但是部署到k8s的時候，啟動失敗，
這個問題看似很詭異，一模一樣的鏡像，一模一樣的網絡權限，軟體層面上完全一樣的，為啥啟動不成功。今天運維部門對k8s擴容過，添加過一個8核的work節點，難道是這個節點導緻的，但是這個節點上也運作了很多容器，不單單隻有該項目。
帶着這個思考，和同僚溝通後，結果确實是添加的新的node節點間接導緻了這個問題，了解到他用egg的時候，沒有去定義work程序的數量，egg就會自動去建立work程序，建立的程序資料是基于擷取的實體系統的CPU線程數來決定的。
如上圖所示，該項目所運作的容器的主控端的CPU線程數是8，通過觀察，發現該項目會自動啟動8個程序，如果我們采用32線程的CPU，那它就會在容器中啟動32個程序，但是容器的資源是做過限制的，雖然你看到這麼多CPU線程，但不是給你一個容器用的，一下子請求這麼多資源，肯定會啟動失敗的。而且容器的思想是一個容器運作一個程序，隻幹一件事，這在實體機上部署egg或許這個特性比較方法，但是容器上部署就會出現這種坑。
解決方法：
讓egg和pm2啟動程序的方式一樣，固定運作的程序數，不要動态擷取CPU資訊，去一廂情願的啟動程序，和docker的資源隔離起沖突。
總結：
1.無論使用什麼新架構新技術，使用前必須深入了解和研究；
2.啟動服務的時候，都不能用預設配置，研發和運維溝通後做一個合适的參數，因為本地環境和生産環境還是會有資源容量上的差異，避免各做各的；