作者 ｜ 一嘯

來源 ｜ 爾達 Erda 公眾號

背景故事

2017 年初，我們基於 DC/OS (mesos + marathon) 開始構建端點自己的 PaaS 平臺，核心任務就是解決公司的軟體開發和部署交付效率問題，建設公司的研發效能(DevOps)、智慧監控運維(APM、Monitoring) 等技術平臺。

其實 DC/OS 還是很好用的：

首先，它集大成了一個完整的容器平臺，不需要過於關注各個細節模組，比如網路。

其次，它在多服務的一鍵編排部署方面也是非常方便的，現在 K8s 主要還是依賴 Helm 來實現，但 DC/OS 存在的最大問題就是使用者數仍太少，問題出現後，需要自行探索解決問題。（估計我們團隊是國內 DC/OS 運維最專業的團隊之一，分母不大於 3。）

這裡講述一件讓我們團隊記憶非常深刻的故事：2018 年夏天的一個週六，我們到公司加班，準備保障業務團隊的釋出，結果公司的整個 DC/OS 的網路都掛了！！原本，我們計劃保障完業務的釋出就去聚餐吃飯，結果被硬生生折騰了一個通宵。

這天夜裡，我們嘗試了所有能找到的方法和建議，把所有能做的事情都做了，結果還是沒有用，仍然沒有辦法恢復網路。最終，我們決定清理掉整個叢集的網路後設資料，重建網路，事情才被真正解決（事實上，摸索出 “清理所有後設資料，重建網路” 這個方法就花了很長時間）。

好了，現在拉回正題。基於 DC/OS 的 PaaS 在 2018 年 4 月完成了第一個正式客戶的生產部署後，又陸續交付生產了好幾個客戶。就這樣，我們一路磕磕跘跘地走完 2018 年，在 2019 年就決定要開始轉型到 K8s 了。

Erda 的發展之路

在架構設計 PaaS 平臺的第一天，就決定要把底層的容器平臺 (DC/OS) 給抽象遮蔽掉，所以我們採用了 infrastructure as code 的理念定義了一個 dice.yaml 的規範 (dice 是 PaaS 平臺的名字) ，dice.yaml 規範的核心就是：“以應用為中心，以開發者為中心”去定義、使用基礎設施資源等。“以應用為中心” 其實並不是什麼新概念，Heroku 早已提出並實踐，我們只是把這個概念做得更極致了些，當然，Heroku 的基礎架構並不算先進，甚至有點落後。

“以應用為中心，以開發者為中心” 對於端點來說是非常重要的，我們一定要讓業務開發的同學只關注業務本身，不用去理解：容器是什麼？K8s Deployment、Statefulset、Service、 Ingress、Pod 等這些東西是什麼？更不需要關心應用跑在一個什麼樣的網路上？也不用關注應用的監控接入、監控覆蓋、診斷分析這些事情。其實，這對絕大多數企業來講都是非常重要的。

“抽象、遮蔽掉底層的容器平臺“ 這個設計除了給業務開發降低了極大的門檻，同時也給我們團隊自身帶來了很大的便利。主要體現在轉型 K8s 的時候，只需要針對性的開發一個 K8s 外掛就完成了（不是給 K8s 開發外掛，是給我們 PaaS 平臺開發外掛）。其實，在支援 K8s 之前，我們還和阿里雲的 EDAS 合作開發了 EDAS 外掛，支援將應用部署到 EDAS 上，On EDAS 這個模式也陸陸續續地交付了好幾個客戶。我們將容器平臺外掛化後，對接 Openshift/Rancher 等也是一件非常容易的事情，這對很多企業私有云環境是非常友好的。

從支援自建 K8s，再到支援阿里雲容器服務、然後又是 AWS、Azure 等，我們一路支援的客戶越來越多。我們發現：如今，在公有云上要從 0 建立一個企業的 IT 環境（測試、生產）還是要做非常多的事情，並且還需要具備非常專業的技能知識， 比如需要涉及 ECS、網路、儲存、資料庫、SLB、中介軟體、容器服務、安全等等。在我們的部分客戶中，上述從 0 建立雲環境的事情都是由我們幫客戶完成的。所以，我們需要提效，需要將這些麻煩的事情給自動化掉，於是就基於 terraform 開發了整個自動化流程。作為一個產品型團隊，我們做任何事情都會想著產品化，一開始就將 terraform 自動化的雲資源編排流程做到雲管平臺產品裡了。

越往後走，我們開發的功能越來越多，平臺覆蓋的範圍也越來越大，後續又支援了邊緣計算管理、快資料平臺、移動開發等。這些功能的原始訴求都來自於端點的真實場景，比如 pos 應用就是一個邊緣場景。

4 年走來，讓我們感到最欣慰的事情，並不是做了多少產品功能，而是從 2018 年中開始，我們就堅持每月釋出一個版本，並且給所有客戶升級到最新版，從來沒有出現過程式碼分叉維護，包括前面提到從 DC/OS 轉到 K8s 的大遷移、大升級（這是我個人心裡覺得做得很牛的一件事情）。時至今日，我們的平臺已經管理了上百個 K8s 叢集的應用，我們的目標之一就是 “成為管理最大規模 K8s 應用的平臺”。

我們為什麼要開源？

2021 年初（春節前），我們在思考 21 年規劃時，才開始意識到自己做了很多事情，開發了一個很強大的產品，我們在產品開發這條路上走得很紮實、很專注，完全忽略了分享給更多的人、回饋社群、建設影響力等重要的事情。

所以，在春節後，我們團隊全力投入將整個平臺完全開源。做開源這件事情，我們想得很清楚，要做就是全部開源，不留所謂的高階功能（私貨），不留內部程式碼分支，整個團隊的日常迭代開發全部轉移到 GitHub 上執行。我們希望做一個長期主義者，用 3 年、5 年，甚至更長的時間持續建設一個足夠好的開源社群，打造一個頂級的開源專案。

放眼全球，我們可以找到非常多的優秀開源專案，但大多數開源專案都是以工具屬性為主，比如：前端 js 庫、開發框架、基礎伺服器軟體等，直接開源產品（或者稱之為商品）的專案卻不多，我個人認為開源產品逐漸會成為這個領域的新趨勢，社會肯定朝著更高效、低成本的方向去演進，基礎工具或技術將會是真正的基礎設施 ，對大多數人來說都不用過於關注它；面向使用者群，解決大多數使用者的直接問題（第一問題）才是社會價值的最大化。

直接開源產品也給我們帶了新的麻煩，我們希望、也歡迎大家免費使用開源的產品，但肯定不希望某一個公司或組織直接將我們的開源產品進行二次銷售（含服務），所以我們決定先採用 AGPLv3 協議進行開源。採用 AGPLv3 的出發點不是為了限制個人、企業自己內部使用，僅僅是防止軟體或服務再銷售。

4 年來我們的 PaaS 平臺一直叫 Dice，目前已經做到了 4.0 版本，所以我們非常糾結在開源社群的第一個版本是 4.0 還是 1.0，如果是 4.0 對社群來講看上去會非常奇怪。最終，我們為了和公司所有的產品命名保持一致，把 Dice 改名成 Erda。Erda 是《基地》小說中地球的別名，Terminus (端點)、Erda、Trantor、Gaia 等都是源自於這部小說中的星球名稱。完成改名後，新名字新起點，所以開源社群從 1.0 版本開始釋出，也就顯得很自然了。

Erda 開源專案有一個小小的願景：“能夠在 Erda 平臺上構建任何型別的應用，持續提升應用研發效能；能夠將應用部署、分發到任何雲、任何地方；能以應用為中心持續完成應用的監控、診斷、治理”。

爾達 Erda 公眾號快速玩轉指南

數字時代是創新的時代，而開發者正是這個時代的踐行者，他們用自己獨特的面孔參與到數字時代建設中。Erda 作為開源的一站式雲原生 PaaS 平臺，旨在為開發者提供穩定可靠、功能全面、相容生態、開源開放的雲原生 PaaS 平臺和最佳實踐，也希望能夠和廣大開發者不斷交流，共同進步，而這也正是我們開創【爾達 Erda】公眾號的初衷：為廣大開發者提供一個技術交流聚集點。

在這裡，除了可以自由分享觀點外，你還可以定期看到我們準備的以下內容：

• 產品動態

• 技術最新進展

• 行業趨勢分析

• 技術解讀

• 最佳實踐

• 技術分享

• 相關技術解讀

• 行業大會現場演講圖文回顧

• 活動分享

• 活動動態

• 技術直播發布

• ······

如果你有其它想要了解的內容，也歡迎到公眾號後臺留言，或者新增小助手微信（Erda202106）加入交流群！

歡迎參與開源

四年風雨，終歸要歷遍山河。

Erda 作為開源的一站式雲原生 PaaS 平臺，具備 DevOps、微服務觀測治理、多雲管理以及快資料治理等平臺級能力。點選下方連結即可參與開源，和眾多開發者一起探討、交流，共建開源社群。歡迎大家關注、貢獻程式碼和 Star！

Erda Github 地址：

Erda Cloud 官網：

————————————————

版權宣告：本文為CSDN博主「爾達 Erda」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處連結及本宣告。

原文連結：https://blog.csdn.net/m0_59358648/article/details/118085240