王煒 騰訊云 CODING DevOps 高級架構師，Nocalhost 開源項目負責人，CNCF 大使。

本文根據 2021 年 4 月 10 日深圳站舉辦的【騰訊云原生技術開放日】 線下活動中，騰訊云CODING DevOps 高級架構師 王煒 關于“Nocalhost - 五星級的云原生開發體驗”的演講整理而成。

關注【騰訊云原生】公眾號，后臺回復【云原生技術】，即可獲得4月10日云原生開放日所有講師的演講PPT。

大家好，今天跟大家分享的話題是云原生開發環境 Nocalhost。之前已經分享過了在應用上的 K8s 或者容器化之后給我們帶來了一些在運維層面或者發布層面的收益，比如像滾動、灰度、A/B Test 之類的，一些運維方面的能力。其實我們會發現在我們業務應用上了 K8s 容器化、擁抱了微服務之后，我們會遇到一個非常棘手的問題，就是我們在本地怎么去開發它？

相信大部分一線開發同學應該是比較深有體會的，所以今天我們分享的話題就是跟云原生開發息息相關的。

這次分享主要會以這幾個模塊跟大家做主要的介紹：第一個是 Nocalhost 因何而生，我們為什么要做這個項目？第二個是目前主流的云原生背景下開發方式。第三個是我們做開源產品當然要知道我們最終想把它做成什么樣的效果，比如像 K8s 目前是云原生的一個標準。第四個是 Nocalhost 的實現原理。第五個是組件構成，Nocalhost 由哪些組件構成。第六個是我們現場會演示用 Nocalhost 怎么來開發 Istio 官方的demo Bookinfo。

Nocalhost 因何而生

?

第一個是 Nocalhost 因何而生，為什么云原生、微服務、分布式的應用開發很難？ 首先看左邊的圖，左邊的圖從基礎的單體架構上來說，本地的開發體驗是非常好的，比如像以前流行的 PHP，我們在開發 PHP 的時候要在本地修改完代碼、刷新頁面就能立即看到效果了，這是以前傳統的開發方式或者單體開發方式。它是組件少，人員或者規模也比較小，環境搭建或者運維相對來說多比較簡單。

隨著規?；蛘邞脠鼍霸絹碓綇碗s，我們擁抱了微服務以及 K8s 容器化，所以這個時候我們把我們的單體應用拆成了巨大的微服務應用，它的微服務組件可能是由幾十個、數百個組成的。 從右邊這張圖，我們就會發現微服務和微服務之間的調用是非常復雜，意味著本地怎么開發某一個微服務組件呢？常見的痛點是我需要在本地把我所有的微服務給run起來，如果微服務特別巨大，可能需要準備一臺非常強的本地開發機，可能是64G內存，I7或者I9之類的，才能搞定業務系統開發。

擁抱微服務最大的問題可能還是處于開發環境的搭建以及整個開發和調試是比較困難的。

從單體架構的開發自測來說，我們每寫一行代碼或者幾行代碼、十幾行代碼，我們想看一下效果，在單體的架構下是很簡單、快速的，但是在容器化、K8s 這種環境下，其實整個開發自測循環是很慢的，我們常見的一些開發方式可能是我寫一行代碼之后，然后我來運行 docker build，重新構建一個鏡像，可能還要 docker push 把鏡像推到我的倉庫里，再修改集群工作的負載版本，再等 pod 重啟，才能看到最新的效果。整個開發自測循環是非常慢，可能是五分鐘、十分鐘甚至更久的時間。

?

在開發環境上的管理，同時也會有遇到一些問題，就是在單體架構這種開發環境下是很簡單的，準備一個配置不需要那么高的開發機，我就能搞定業務開發。但是在微服務這種背景下，可能有些團隊會采用本地和遠端組合的形式，可能會遇到不同版本的環境管理混亂的問題，甚至是需要等其他開發用完之前的環境，然后我下一個才能去用，出現這種排隊的情況。

?

剛才提到了我們目前主流的開發方式，我們基于目前主流的開發方式整理了一張簡易的圖，重點關注最左邊的開發方式，所有服務運行在本地的情況?？梢园l現，它的編碼和自測反饋循環體驗是最好的。開發測試環境、維護成本、橫向擴容能力，這些其實都是非常弱的。當然，我們使用 K8s 和容器化之后，最右邊的所有服務都運行在云端，除了編碼自測返回、循環反饋體驗不好以外，其他這些給我們帶來的能力或者收益其實是非常棒的，特別是前面我們提到的在運維層面的基本可以實現服務這種自愈以及自動擴縮容等等能力。

?

我們講到最右邊的圖，對 Nocalhost 項目來說，我們希望有沒有可能找到一種方法可以在集合對右邊開發方式所有優點的同時，然后把最左邊所有服務運行在本地的編碼自測反饋循環體驗的五顆星這個優點也放在為右邊的模式下，這是希望Nocalhost 想解決或者希望解決的問題。

?

Nocalhost 的愿景

Nocalhost的愿景，我們產品的愿景是讓云原生的開發回歸原始而簡單。也就是說，跟你在本地開發一個單體應用一樣這么簡單，你不需要考慮一些復雜的背景知識以及應用方面的背景知識。

剛才我們所說，我在傳統的云原生開發可能需要五分鐘甚至十分鐘的體驗，那對Nocalhost 來說，整個過程我們是可以做到秒級。從原來這種開發環境混亂的狀態，到現在 Nocalhost 提供的一個有序的環境管理。Nocalhost 提供的開發環境，本身是不提供計算資源，也就是說 Nocalhost 本身不提供K8s集群，它是用現有的集群資源，通過 Namespace 的方式分配給每個開發者去做開發，如果結合一些云計算彈性方面的能力，甚至可以做到按需分配以及用完銷毀的。

?

Nocalhost 讓業務容器進入一個開發模式

第四個跟大家分享 Nocalhost 的原理，為什么它能夠做到在容器化的開發場景可以做到這么高效的開發，它主要的核心點在于 Nocalhost 可以讓業務容器進入一個開發模式。

?

Nocalhost 有幾個核心的概念，第一個是應用，可能是由很多個微服務組成的，比如 Bookinfo 是一個 Kubernetes 應用。我們公司的服務是由一百多個接近兩百多個微服務組成的，所以這也是一個 Kubernetes 應用。其實在 Kubernetes 體系下是沒有應用這個概念的，所以現在應用領域，比如大家所熟知的 OAM 標準以及 Kubevela，它們是有重新封裝一個應用的概念，這是對 K8s 能力的補充，因為我們都知道應用是幾個工作負載組合成成的，其實這個只有我們才知道，K8s 集群是不知道的，所以這是應用。當然，應用有很多種類型，可以用 Manifest 組成應用，可以 Helm 組成，也可以用 Kustomize 組成的應用，這在 Nocalhost 里面都支持的。

第二個就是集群，也就是計算資源需要用戶來提供。其實這個提供可以說是只需要提供一個集群資源就好了。至于分配給每個開發者，它是基于 Namespace 隔離的，用于部署每個開發者的開發環境以及開發時候用的。

第三個是開發者，開發者在 Nocalhost 里面也是有一個概念的，我這個企業下面可能有很多開發者，我只需給你分配一個開發賬號，你登錄就能進行所有的開發工作了。

最后一個是開發空間，前面已經講過了。

?

在講下一個的話題之前，我們先把 Nocalhost 的環境一鍵初始化起來。Nocalhost 提供了一個 CLI 工具，用來快速初始化整個開發環境，并且會內置一些應用，比如像bookinfo 快速體驗。只要這一條命令就可以了。

?

通過插件端，開發者可以一鍵拉起自己的開發環境，就是點右邊的小火箭就可以開發，就可以拉起完整的一套開發環境了。

?

實現原理是，讓某一個業務容器進入開發模式，甚至是不同的開發者之間在相同一個開發環境里共同來協作開發，比如我開發的業務代碼需要依賴于你的新接口，所以會有一個協同開發的過程。對于 Nocalhost 來說，在同一個 Namespace 可能會有兩個開發者共享開發者，并且去做協同的開發工作。

進入開發模式會發生什么呢？首先我們會替換整個業務容器的鏡像，比如我們會 disable 跟生產、運維有關的東西，HPA、Liveness&Readiness，以及讓它的實例副本數到 1。最重要的一點，我們在開發的時候也會給這個業務容器加一個 Sidecar。這樣，整個 POD 會有兩個容器，第一個是為業務代碼提供 Runtime 能力支持的容器，第二個是文件同步的容器，它們兩個會通過共享卷來共享存儲。

實現了這一步之后，我們本地的代碼其實就是可以通過經由 Sidecar 的能力，同步到遠端開發環境的 POD 里面。再結合 Nocalhost 提供很便捷的獲取遠端容器的 Terminal 的機制，就可以實現在容器里面直接運行業務代碼。

?

為什么業務代碼能在容器里運行？因為這個容器是真正的業務容器，保留了所有你之前給它設定的 ENV，不管你是通過 configMap 掛載，還是在 Deployment 里聲明的 ENV，這些東西都是有保留的，可能有一些業務會在 InitContainer 里做一些魔法的操作，這些東西全會被保留。這就意味著在容器里面 RUN 業務代碼是完全OK的，并且是走整個集群的網絡，在網絡層面以及在流量層面也都是OK的。

?

Nocalhost 除了提供對業務容器直接進入開發以外，我們還會做一個依賴處理的邏輯。打比方，在 Kubernetes 環境下，如果部署一個應用，這個應用可能是由兩百個微服務組成的，你發現很多應用在業務邏輯是有依賴關系的，但是 K8s 并沒有為我們提供這種依賴關系處理，部署完之后很多 POD 會不斷重啟，因為可能有些業務是依賴于 DB、MQ、基礎組件。如果它找不到這些服務，它自己會掛掉，意味著很龐大的微服務真正被拉起來的時候，POD 會被重啟 N 次，由于 K8s 對這些 POD 重啟的時間頻率，它是一個越來越慢的算法，所以這就導致了你拉起整個開發環境的時間是非常久的，像我們內部的系統兩百個微服務左右，如果僅僅用很粗暴的方式去部署大概三十分鐘才能把整個業務全部 RUN 起來，會發現里面很多 POD 重啟次數已經達到幾十次。

這是 Nocalhost 提供的另外一個能力，也就是業務方可以給 Nocalhost 提供一些依賴的聲明式的配置，在部署的時候，Nocalhost會有一個準入控制器。我們會把進集群的所有工作負載攔截，根據你聲明的服務依賴信息給這些服務注入 InitContainer，InitContainer 就是等會等待被依賴的服務啟動，然后我再啟動自己，其實是一個等待的過程。這是由Nocalhost Agent 攔截，并且自動注入的，所以這是 Nocalhost 提供的第二方面大的能力。

?

Nocalhost 的組件，剛才已經大致說到了，一個是 CLI 工具，這個工具是給開發者用的，也就是本地電腦裝這個工具就好了。當然它的命令有很多，你完全可以使用 CLI 工具對你的工作負載進行開發，但是命令非常復雜。

?

還有一個 Sever 端，它有幾個大的功能，一個是我可以創建我的應用，以及開發者、用戶，就是我所有開發人員。

?

剛才所說到 CLI 工具用起來是比較麻煩的，所以提供了一個 Plugin，也就是 IDE 的插件，現在都是可以直接用的，所以你只要安裝，對開發者來說只需要安裝 CLI 工具和 IDE 插件就可以實現非常簡單的云原生的開發體驗。插件的好處在于，因為 IDE 是對接近開發人員的，在插件進行開發環境的操作是最簡便的。

?

最后一個是 Agent，它也是以 Deployment 的形式布局在集群的，當然這些都是自動的。

?

前面的講解，我們實現了像在本地開發單體應用一樣，在 Nocalhost 下的開發體驗集合了所有的應用所有開發環境運行在遠端，并且編碼和自測反饋循環是一個非常好的體驗。

在我們 CODING DevOps 內部目前已經全部使用了，實現的效果是新員工入職當天，他就能夠獨立提交業務代碼。這在以前可能是比較難的，也就是說一個新員工入職可能需要一周左右的時間了解開發環境是怎么樣的、業務系統大概是怎么樣的、我要怎么搭這個開發環境。在真正搭的時候，可能從第二周真正開始，過程中會遇到各種各樣的問題，可能會有自己的師兄或者自己的導師來協助解決。在原來的業務開發模式下，從效率上來說是不高效的。在 CODING 內部，所有應用都是按照業務線分的，像 CI 運行自己最小化的 CI應用、微服務這些整合起來的應用，最小化的應用。CD 也是運行自己最小化的微服務開發環境。

比如我現在接到一個需求，我需要去開發登錄或者是整個消息通知的組件，對于新員工來說，他唯一需要知道的是我需要開發哪個組件就好了。點了開發之后，它會自動幫你克隆代碼，自動打開，甚至你這個應用是怎么運行的，在 Nocalhost 里面都是可以配置的。也就是說，它甚至不需要你這個應用的運行命令是什么樣的。在我們內部使用目前 Nocalhost 支撐了我們近百名開發人員日常的開發工作，所以我們采用的是一個集中式的開發環境的管理。也就是說，一個運維團隊管了所有這些開發資源，這個集群是一個巨大的資源池。

目前 Nocalhost 是開源的，并且采用 Apache 的開源協議，在 GitHub 上是可以找到我們的項目。

?

整體的 RodaMap，目前 0.1.0 版本在 K8s 環境下非常好的開發體驗。當然，也不排除以后會支持其他的環境。

?

依賴分析、按需啟動，目前對開發來說，其實也是一個非常大的痛點。Nocalhost 目前的缺點在于每個開發人員都要運行一套完整的開發環境，也就是說它包含了所有的微服務組件，但實際上你如果要開發某一個微服務組件，它可能是不需要啟動完整開發環境的，所以我們接下來會做依賴分析以及按需去啟動你要開發的微服務組件所依賴的組件。最后我們會實現共享開發環境，這是什么意思呢？這個共享指的是我可能會共享一些基礎組件，打比方，我們現在每一個開發同學都全量拉起了所有的微服務組件，有一些基礎組件平時是不怎么被更新的或者基本上是穩定的狀態。Nocalhost 接下來想實現的目標是對于這些組件，大家一起去共用，結合Service Mesh 的技術做一些流量轉發甚至實現基礎組件是共享的，可以大大減少整個開發環境所需要的一些資源。

QA環節

提問：我想問一下，在一個上百人的研發團隊里，因為有些人對 Docker、K8s 這些知識不熟悉，如何從零開始推廣這種開發模式？

王煒：Nocalhost 要解決的核心問題，其實這也算是一個。你會看到剛才我在對 Bookinfo 微服務組件做開發的時候，我是沒有運行任何的 kubectl 或者是 Docker 相關的命令的，意味著這些知識已經對開發人員屏蔽了。比如你需要看一個工作負載具體的情況，你可能用 kubectl get deploment 的命令去查看，如果你是傳統的開發方式，你可能需要用 kubectl edit 來修改你工作負載的鏡像版本。如果是傳統的開發方式，你需要具備非常多的至少是入門級的或者知道怎么去使用 kubectl 以及 Docker 常見的這些命令。如果你用 Nocalhost 來開發，你會發現全程幾乎不涉及到這些知識的，你所需要做的就是點一下那個錘子，然后去開發它就OK了。

提問：基礎環境中，比如涉及到K8s還有一些 Helm 的編寫，這些是由運維團隊來負責的嗎？

王煒：實際上不是運維團隊，在我們內部會有一個基礎架構的業務團隊來維護基礎這些環境。當然，涉及到每一個微服務你要去更新，就是更新基準環境的時候，這是由每一個業務團隊負責的。其實這個問題痛點我們公司之前也遇到過，你想要維護一套統一的 Helm 或者 Manifest 是非常難的。比如我的微服務，它有可能被任何一個部門更新了，導致我要把它拉起來的時候，我發現各種報錯，完全拉不起來，或者它是舊的版本。這里的核心問題，你們維護的那套東西不是被高頻使用的，所以它即便是出現問題了，它也很難被人發現或者很久才被人發現，慢慢這套東西就不被維護。如果采用 Nocalhost 集中式應用管理，這個問題就會被解決掉。因為拉起部署環境以及進入開發這些動作都是非常高頻的。在一個團隊來說，我們發現只要有了工具化的幫助，你會發現團隊內會形成良性的循環。也就是說，我在用 Nocalhost 開發的時候，我會發現我有一個組件 RUN 不起來，這個組件可能是我負責的或者我維護的，我就會把它更新掉，或者有一些新的 feature，我會把它更新上去，因為我也要依賴于這套東西開發。

提問：假設我們現在搭建這么一套環境，新人進來了，Nocalhost 服務掛了，會不會導致公司整套用不了？容錯方案有沒有？

王煒：沒錯。首先這個答案是肯定的，就像公司采用了 K8s，這個集群掛了，它會導致你的業務沒辦法 RUN，會停止的狀態。實際來說，整個 Nocalhost 是部署在 K8s 環境下的，所以你可以為 Nocalhost 配置一些 HPA 之類的。當然，從 Nocalhost 本身來講是高可用的，但是依賴于你提供的 K8s 集群穩定性。你如果是自建集群，那穩定性可能從概率上來講應該沒有 TKE 高。

2提問：假如我有ABC服務，要開發兩個服務，AB 兩個服務依賴 C 服務，我在線上會不會導致有這些問題？

王煒：你剛才提到的有這些問題，開發模式是部分運行在本地，部分運行在遠端的開發模式。但是 Nocalhost 的開發模式是在你自己開發空間里部署完整一套你所有的業務應用以及微服務組件，所以這是不會的，因為你個人用的就是一套獨立的開發環境或者是跟別人完全不沖突的。

提問：你好，我主要是問一個具體的問題，假設一個 AB 服務，A 服務在迭代，B 服務迭代，可不可以做到跨 Namespace 相互聯調的功能？如果能達到未來所說的，一個是共享資源能夠不要出現復制多份的問題，你們那邊 Namespace 會不會出現膨脹的情況？大概一百多或者兩百多員工，集群非常大，如果是單一的集群可能會存在膨脹的問題。

王煒：第一個問題又分兩個問題，一是你剛剛問到能不能跨 Namespace，這個目前已經在實施了，已經在做了，馬上會支持這種集群級的開發。不管幾個 Namespace，在 Nocalhost 下都可以開發。這位同學非常敏銳發現了 Nocalhost 現在比較不好的一個點，比如我要開發 Prometheus 組件，它是在固定的 Namespace 下面這種組件，用 Nocalhost 開發也是可以的，你需要用 Nocalhost 的 CLI 工具，但它的使用門檻太高了，所以我們接下來會在插件層面支持這種集群級的。不管你提供的是什么樣的權限，可能是管理員或者是具有多個 Namespace 的權限，你可以在不同的 Namespace 下面開發。這是第一個問題。

提問：能不能通過未來服務網格的問題徹底解決第一個問題，達到像你說的每個人到時候就是一個 K8s 集群，并行迭代開發也能相互聯調的問題得到解決。

王煒：是的，用服務網格的方案是可以實現的，是完全可以解決的，但從目前實現方面的技術難度來說，可能 Nocalhost 需要自己做一個獨立的控制面，所以它的實現難度非常大，基本上可能要基于 Istio 做二次開發。這方面我們有長期的規劃，但是從目前來講可能我們團隊認為云資源未來會越來越便宜。在環境資源上看，現有能提供這種方案或者是現有這些資源能滿足開發條件其實暫時還沒有必要在節省資源方面投入太多的精力。

容器服務（Tencent Kubernetes Engine，TKE）是騰訊云提供的基于 Kubernetes，一站式云原生 PaaS 服務平臺。為用戶提供集成了容器集群調度、Helm 應用編排、Docker 鏡像管理、Istio服務治理、自動化DevOps以及全套監控運維體系的企業級服務。

【騰訊云原生】云說新品、云研新術、云游新活、云賞資訊，掃碼關注同名公眾號，及時獲取更多干貨！！

總結

以上是生活随笔為你收集整理的云原生技术开放日PPT大放送 | 五星级的云原生开发体验的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。