![頭圖.png](https://intranetproxy.alipay.com/skylark/lark/0/2021/png/21956387/1627348489978-e9f7d088-8bf8-49b3-a046-6ff927eef3ff.png#clientId=ub48dfedc-5213-4&from=ui&id=uca70a2e3&margin=%5Bobject%20Object%5D&name=%E5%A4%B4%E5%9B%BE.png&originHeight=720&originWidth=1080&originalType=binary&ratio=1&size=655456&status=done&style=none&taskId=u2cf47ca9-2125-4da4-abd7-07e20da1ca0)
作者｜劉浩楊
來源｜[爾達 Erda 公眾號](https://mp.weixin.qq.com/s/5u3W8kPAUo6FE98qlk5OAA)

本文整理自劉浩楊在 GopherChina 2021 北京站主會場的演講，微信新增：Erda202106，聯絡小助手即可獲取講師 PPT。

# 前言
當今時代，數字化轉型概念在 ToB 領域非常火熱，越來越多的企業需要數字化轉型，因此越來越多的廠商湧入了 ToB 市場，端點就是其中一員。

端點的核心業務是給企業提供從採購、交易、履約、倉儲到零售全鏈路的數字化轉型解決方案。圍繞這個目的，我們建立了一整套面向雲原生的企業數字化軟體產品，其中：

- PaaS 平臺 Erda 是技術底座。
- Trantor 是具有 HPAPaaS 能力的研發底座，執行在 Erda 之上，提供低程式碼和高效開發的能力。
- Gaia 是完整的業務能力平臺，覆蓋計劃、尋源、採購、營銷、服務、銷售、交易、履約、結算等企業供應鏈業務領域，提供會員營銷、全渠道運營、SRM 採購和線上銷售平臺等業務產品。

透過這幾層能力的組合，使我們具備了生產可定製 SaaS 化產品的能力，為企業客戶提供端到端的解決方案，滿足各行業不同客戶的各類需求。所以可以看到在這個分層的企業數字化研發體系中，我們透過 PaaS 平臺向下遮蔽複雜的基礎設施，使整個業務系統擁有架構多雲之上的能力；同時，PaaS 平臺也向上提供微服務研發和治理的技術中臺能力，讓上層使用者能夠更專注於業務系統自身的構建。

接下來，簡單介紹一下我們在構建 Erda 過程中的思考，文章後半部分將回到技術本身，來分享一下我們如何使用 Golang 實現雲原生的 PaaS 平臺。

![image.png](https://intranetproxy.alipay.com/skylark/lark/0/2021/png/114913/1626857998997-2e6a2d02-9b96-402d-b3d7-08fe722ca2ed.png#height=527&id=a3Orl&margin=%5Bobject%20Object%5D&name=image.png&originHeight=1054&originWidth=1390&originalType=binary&ratio=1&size=341837&status=done&style=none&width=695)
# 軟體交付面臨的問題和挑戰
端點從 2012 年成立到現在，一直聚焦在企業級軟體開發和交付上，我們也從最開始的軟體定製交付，到今天使用標準軟體 + 二開機制解決定製需求的方式交付。在這個過程中，我們遇到的問題可以總結為以下 4 點：

1. 隨著交付規模的快速增長，開發和交付團隊要如何提效？
1. 業務軟體系統如何適配複雜的客戶部署環境？
1. 大規模交付的部署過程需要可被標準化。
1. 交付上線後需要持續保障業務穩定性。

如今，敏捷開發是一個相對普及的概念，我們在做軟體交付的時候，也需要把開發流程從傳統的瀑布式開發轉變為敏捷開發，比如一個理想的開發方式是：使用專案協同工具來管理研發過程的需求、任務、缺陷；使用 gitflow 來管理功能需求的開發；使用自動化的流水線實現持續整合；然後基於容器化來部署我們的軟體；部署之後觸發自動化測試來驗證功能的正確性。同時，像 API 閘道器、微服務治理、容器服務、流計算等這些在網際網路公司流行的技術，也逐漸開始受到大型傳統企業的青睞，這對我們的要求也是進一步提高。

為了解決這些問題，我們就需要一個完整的 DevOps 平臺來支撐整個研發交付的流程，來達到提高研發效能的目的。
![image.png](https://intranetproxy.alipay.com/skylark/lark/0/2021/png/114913/1627023947732-502a63da-94fd-49a4-a12f-84c3c05bc610.png#height=798&id=u841395c1&margin=%5Bobject%20Object%5D&name=image.png&originHeight=798&originWidth=1440&originalType=binary&ratio=1&size=149082&status=done&style=none&width=1440)
剛才講了在研發過程中的問題，接下來聊一下在需求開發完成後，去企業提供的環境進行交付的環節。

在我們做過的客戶裡面，有自建機房用 zstack 來提供虛擬化，也有采購阿里雲、騰訊雲、或者微軟雲 azure 的 ECS，還有的會提供現成的容器環境但管理介面不同，比如 Rancher 和 OpenShift，這些情況我們都碰到過。甚至最近的一個專案裡，客戶提供的是 arm 架構的執行環境。

因為這些企業提供的環境千差萬別，所以交付就變成了一件很痛苦的事情。

回顧計算機軟體的發展歷史，我們知道 java 是現在很流行的一個開發語言和平臺，java 能流行的很大一個原因是因為它提出了 Java 虛擬機器，透過編譯 Java 程式碼到通用的位元組碼，再由執行時去即時編譯位元組碼到不同平臺的彙編方式來實現“一次編寫，到處執行”。那麼，我們構建的軟體系統是否也可以像 java 一樣 “一次打包，到處執行”？說到這裡，可能很多人都會想到：基於 Docker 和 Kubernetes 作為軟體的執行時也可以讓我們的軟體製品遮蔽掉不同的部署環境。但是，管理不同環境下的 Kubernetes 也是一件很複雜的事情，我們需要一個平臺來向上承載不同的業務系統，向下管理資源和應用排程。

我們今天的做法是透過一個多雲管理平臺來解決這個問題。
![image.png](https://intranetproxy.alipay.com/skylark/lark/0/2021/png/114913/1627024053855-12736c30-ce0a-487d-9abc-47ef7146d6bb.png#height=1038&id=ua8c0c5a6&margin=%5Bobject%20Object%5D&name=image.png&originHeight=1038&originWidth=1916&originalType=binary&ratio=1&size=605299&status=done&style=none&width=1916)

很多軟體系統在驗收交付上線後，如果沒有一個完整的平臺實時監控、洞察系統的健康狀態，將會導致各種問題（穩定性、異常、錯誤、攻擊）時有發生，嚴重影響業務的正常執行。保證業務穩定性也是我們可以提供給客戶的核心服務之一。

在之前的案例裡，我們利用 PaaS 上監控的高度擴充套件性，幫助一家排名世界 500 強的外企搭建了一套雲上的統一監控運維平臺，真正實現了從雲產品，比如 SLB、WAF、ECS、RDS，到平臺層、再到 PaaS 上執行的業務系統的全鏈路監控和日誌資料的統一分析，再透過 PaaS 內建的視覺化和告警入口，使得客戶只需要投入很少的 IT 運維人員就能夠保證系統的穩定性。

另一個場景是我們的 PaaS 平臺自身。我們現在同時在運維著 100+ 的 Kubernetes 叢集，但全職負責運維的同事大概只有三四人，而且可預見規模擴大的同時，也不需要在運維上投入更多的人力，這也得益於我們對平臺可觀測性的全面覆蓋。

所以可以看到，研發、交付、運維遇到的很多問題，我們都是透過 PaaS 很好地解決了。
![image.png](https://intranetproxy.alipay.com/skylark/lark/0/2021/png/114913/1627024143785-75f56d10-612f-42f7-88a7-881ee6547119.png#height=412&id=u544998a6&margin=%5Bobject%20Object%5D&name=image.png&originHeight=874&originWidth=1696&originalType=binary&ratio=1&size=695722&status=done&style=none&width=800)
# 端點一站式 PaaS : Erda
前面提到，我們構建 PaaS 很大一部分是來自端點自身的需求。早在 2016 年我們就開始搭建端點的部署和應用監控平臺，當時的選擇是使用 Docker 和 Jenkins 等開源工具、讓業務應用手寫 dockerfile 的方式來進行釋出；在監控的選型上，使用 Zipkin 作為分散式應用的追蹤系統、使用 ELK 作為日誌平臺，這可能也是很多公司常見的做法。這套系統搭建起來以後，在一段時間裡滿足了公司內部的開發使用，但是隨著業務對平臺要求越來越多，我們也引入了更多的開源元件，維護這套系統的成本也越來越高。同時，有客戶希望我們能把技術平臺也一起對外輸出，很顯然使用開源元件混搭的這臺系統並不能滿足我們的要求。

在 2017 年，我們想要重新設計一個以應用為中心的研發平臺產品，於是選擇了以 DC/OS 為底座，在上層使用 Java 構建 DevOps 和服務治理平臺，並且在 2018 年初交付了第一個客戶。現在來看，選擇 mesos 而不是 K8s，當時是走了彎路的，所以從 2018 年下半年開始，我們也全面擁抱 K8s 生態。同時因為 Java 的效能和資源佔用問題，我們做了第二次的 PaaS 架構升級，開始使用  Golang 重寫了大部分的平臺元件，也因為要同時支援 DC/OS 和 K8s 兩個容器平臺，我們拆分出了異構的排程器模組和流水線模組。時至今日，我們正在交付的所有客戶都已經在使用 K8s 架構。

越往後走，我們開發的功能就越多，平臺覆蓋的範圍也越大。我們陸陸續續在平臺上實現了微服務治理、快資料、移動開發、邊緣計算等諸多平臺級應用，演變成了今天 Erda 的一站式 PaaS 產品矩陣。

![image.png](https://intranetproxy.alipay.com/skylark/lark/0/2021/png/114913/1626945500901-e867060e-aa76-4e64-8eef-654035f77040.png#height=520&id=u2spb&margin=%5Bobject%20Object%5D&name=image.png&originHeight=1040&originWidth=2188&originalType=binary&ratio=1&size=1023976&status=done&style=none&width=1094)
上圖是 Erda 現今的產品大圖，其中以多雲管理、 DevOps、微服務治理和快資料四個平臺為核心。我們在多雲管理平臺裡面實現了兩個比較重要的能力：

- 一個是對異構資源環境的支援，支援管理物理機、虛擬機器、支援原生的 K8s 叢集、DC/OS 叢集等。
- 另一個能力是原生的多叢集架構，可以透過不同的叢集對環境進行物理隔離，比如實現開發、測試和生產環境的資源互不影響。基於容器化，我們也可以很容易地實現對資源池的精細管理，按 CPU 和記憶體的粒度精確控制不同應用的資源分配等。

在多雲平臺之上，DevOps、微服務和快資料平臺分別來管理業務和資料。在業務側提供軟體開發的需求、開發、測試、部署、運維全生命週期的功能，在資料側也透過批流一體實現真正快資料治理能力。除此之外，業務和資料的統一協同，業務可以更大程度地透過數字進行描述，從而實現更為精細化的運營。
![image.png](https://intranetproxy.alipay.com/skylark/lark/0/2021/png/114913/1626947208313-1f2cc1cb-0398-4b29-bb25-fc253f24dc09.png#height=485&id=GKQI0&margin=%5Bobject%20Object%5D&name=image.png&originHeight=970&originWidth=1840&originalType=binary&ratio=1&size=1291584&status=done&style=none&width=920)
# Erda 架構的思考
前面介紹了 Erda 提供的的一站式能力，那麼我們是怎麼去實現在 PaaS 上實現構建不同的平臺服務，實現同一個核心支援微服務開發和資料治理的能力呢？首先來看我們對 PaaS 擴充套件架構的思考。

在最初的版本里，我們只有簡單的應用部署功能，把所有的程式碼放在一起構建了一個單體服務。隨著平臺功能逐漸增多，我們也開始把系統拆分成更多的微服務，在拆分的過程中，嚴格遵守一些設計原則，進行合理的架構分層來避免服務爆炸。在 Erda 當前的系統架構中，我們把系統分為三層：平臺應用層，服務層和 PaaS 的核心層，並且約定每一層之間不允許產生橫向呼叫，只允許呼叫下一層服務提供的介面。

**核心層**提供了 PaaS 和基礎設施互動的能力**，**它包含三個核心元件和相對獨立的監控系統：

- cluster manager 透過和每個叢集的 cluster agent 通訊，實現多叢集管理的能力。
- pipeline 服務實現了 workflow 的編排和 job 排程能力，包括短時任務、資料的批任務、流任務等。
- orchestrator 服務實現了 workload 的編排和有狀態/無狀態的服務排程能力。
- 監控系統負責收集、計算和展示每個叢集上報的可觀察性資料。

****

**服務層**類似於業務系統中提到的中臺概念，提供平臺中的公共功能模組的能力，如使用者、租戶、許可權、通知、報表、事件、審計、版本控制、專案管理等。

**應用層**則是每個平臺呼叫下層的能力進行自身的業務邏輯封裝，同時提供和前端互動的介面。

透過這樣一個分層架構，可以很容易地去實現一個新的平臺應用。例如在實現移動開發平臺時，程式碼管理、構建流水線、審計可以複用 DevOps 原有的能力，使用者行為分析、異常分析等功能依賴監控系統的能力得以實現。

![image.png](https://intranetproxy.alipay.com/skylark/lark/0/2021/png/114913/1626963125838-04028fbe-2fc2-4164-b342-53297ca1960c.png#height=503&id=VPJBn&margin=%5Bobject%20Object%5D&name=image.png&originHeight=1005&originWidth=1746&originalType=binary&ratio=1&size=277103&status=done&style=none&width=873)

眾所周知，Kubernetes 作為雲原生應用的最佳部署平臺，開放了容器執行時介面（CRI）、容器網路介面（CNI）和容器儲存介面（CSI），這些介面讓 Kubernetes 的開放性變得最大化，而 Kubernetes 本身則專注於容器排程。同樣，在以應用為中心的 DevOps 平臺中，CI/CD 是最為核心的能力，而我們也認為 CI/CD 的核心是對 workflow 和 workload 的管理，所以我們也開放了 workflow 介面和 workload 介面，讓 DevOps 平臺專注於應用開發管理，而不必關注 JOB 和應用被部署到何種平臺上。
![image.png](https://intranetproxy.alipay.com/skylark/lark/0/2021/png/114913/1626972847584-dfe10177-d634-423a-94b3-962bc6329032.png#height=515&id=KbxQ6&margin=%5Bobject%20Object%5D&name=image.png&originHeight=1030&originWidth=1626&originalType=binary&ratio=1&size=350205&status=done&style=none&width=813)
這裡我們也在實踐基礎設施即程式碼的思想。在 Erda 上，你可以使用 pipeline.yaml 來定義應用的 CI/CD 全流程，比如程式碼拉取、質量掃描、單測執行、應用編譯、構建和部署。

一個 pipeline.yaml 的示例如下：
```yaml
stages:
  stage:
  - git-checkout:
  stage:
  - buildpack:
      params:
        context: ${git-checkout}
  stage:
  - release:
      params:
        services:
          trade-server: ${buildpack:image}
          erda_yaml: ${git-checkout}/erda.yaml
  stage:
  - deploy:
      params:
        release_id: ${release:id}

```

同時，還可以使用宣告式的 erda.yaml 來描述你的應用微服務架構，包括微服務之間的依賴關係、對中介軟體的依賴等，任何標準的 erda.yml 都可以被 DevOps 平臺所部署。一個 erda.yaml 的示例如下：

```yaml
services:
  trade-server:
    resources:
      cpu: 2
      mem: 2048
    deployments:
      replicas: 2
    ports:
     - port: 8080
    envs:
      ENABLE_ALIPAY: true
addons:
  mysql:
    plan: mysql:basic
    options:
      version: 5.7.23
      create_dbs: trade_db

```

值得一提的是，基於 pipeline（流水線）和 erda（部署）兩個定義之上，我們構建了豐富的 addon 和 action 市場，你可以把自己的服務打包成一個開箱即用的 addon，也可以來實現自己的流水線 action，這些機制讓 DevOps 平臺的擴充套件性得到極大的增強。

我們再來看一下 Erda 微服務平臺的設計。共分為控制面和微服務引擎兩個部分，它們之間透過我們設計的協議進行通訊。通常，我們會使用 Erda 內建的微服務引擎，這裡的選型是使用了 Spring Cloud Alibaba 元件作為內建實現，可以相容企業原有的 Spring Cloud & Dubbo 的業務應用，不需要改動任何程式碼即可接入。同時，對於有特殊需求使用雲服務的使用者，也支援直接對接雲廠商的微服務引擎，我們已經實現了阿里雲 MSE 的可選實現。在這樣的設計下，現在很流行的 ServiceMesh 系統比如 Istio 也可以很容易的作為 Erda 微服務引擎的一種實現被接入。
![image.png](https://intranetproxy.alipay.com/skylark/lark/0/2021/png/114913/1626973249648-5a2840f8-3d85-4480-8d9e-499d4a85fdec.png#height=520&id=g3B09&margin=%5Bobject%20Object%5D&name=image.png&originHeight=1040&originWidth=1492&originalType=binary&ratio=1&size=345547&status=done&style=none&width=746)
最後，我們再來講一下監控系統的設計。在 Erda 的場景裡，監控系統同時支撐基礎監控、APM 和瀏覽器端的監控，所以我們沒有直接使用社群流行的監控系統，比如 Prometheus 或者 Skywalking，而是選擇了自研一套監控系統，在採集端適配社群的標準化協議。

首先我們在每個叢集中安裝基於 Telegraf 深度定製的 Cluster Agent，負責採集 Kubernetes、Erda 在叢集中部署元件的可觀察性資料，同時這個 Agent 也可以模擬成一個 Prometheus Server，拉取叢集中被自動發現的 Exporters 資料。

那麼在每個節點上，也會部署一個 Node Agent，可以自動發現節點上的 Pod，並把 Pod 識別為 Erda 平臺定義的 Service、Job 或者 Addon 元件。同時 Node Agent 也會作為一個本地 Proxy，接收 Pod 中的業務應用 Java Agent 探針和 NodeJS 探針上報的應用請求和 Trace 資料，轉發給後端的 Metrics Gateway 元件。
在未來，我們計劃支援更多的第三方協議，如 SkyWalking 和 OpenTelemetry，來更多地提高 Erda 在可觀察性上的擴充套件。
![image.png](https://intranetproxy.alipay.com/skylark/lark/0/2021/png/114913/1626974279947-1addf678-c628-4c07-86ab-7b990442b3e0.png#height=494&id=g37PE&margin=%5Bobject%20Object%5D&name=image.png&originHeight=1359&originWidth=2200&originalType=binary&ratio=1&size=233197&status=done&style=none&width=800)
# Erda Infra 模組化開發框架
前面從架構的角度講了我們對 PaaS 擴充套件的一些思考，也提到透過微服務的方式來構建整個平臺，實現微服務化的重點就是要對系統功能進行合理拆解，把系統拆解成諸多邊界清晰、可以內聚的業務模組。

雖然在 golang 社群中有很多 web 開發框架，如 gin、go-zero、beego，但深思熟慮後，我們發現需要的不僅僅是一個 Web 框架和微服務框架，而且還需要一個以模組化開發為核心，可以透過介面對系統進行擴充套件的開發體系。基於此我們設計了 Erda Infra，一套輕量級 Go 微服務框架，包含大量現成的模組和工具，能夠快速構建起以模組化驅動的應用程式。

Erda-Infra 的核心特性包括：

- 以模組化設計方式來驅動應用系統實現，支援模組可插拔。
- 統一配置讀取，支援預設值、支援從檔案、環境變數、命令列引數讀取。
- 統一模組的初始化、啟動、關閉。
- 統一管理模組間的依賴關係。
- 支援模組間的依賴注入。
- 包含大量現成的微模組 Provider，包括 etcd、docker、cassandra 、es 的 sdk、Http Server、gRPC Server等。
- 使用 Protocol Buffer 定義介面，支援自動生成 gRPC 和 HTTP 介面和客戶端呼叫程式碼。 
- 提供快速構建模組的程式碼生成工具。

![image.png](https://intranetproxy.alipay.com/skylark/lark/0/2021/png/114913/1626976681652-d724a604-793f-4297-af64-bba3efe8a651.png#height=520&id=u44720b61&margin=%5Bobject%20Object%5D&name=image.png&originHeight=1040&originWidth=1412&originalType=binary&ratio=1&size=103162&status=done&style=none&width=706)
Erda 現在有數千個功能點包含在幾十個服務裡面，一旦服務功能拆分設計的不合理，很容易引發整個專案的維護成本問題。我們在從架構層面審視模組拆分的同時，也期望使用開發框架來對開發進行一些約束。

**第一個原則**是對模組的拆分粒度要儘可能小，讓每個模組的邏輯能高度內聚，對外的依賴可以松耦合。拿應用監控這個子系統來說，我們拆解成了拓撲、服務列表、服務監控、瀏覽器監控、錯誤分析、鏈路追蹤等相對獨立的模組，然後使用 Erda Infra 提供的能力拼裝到一起組成監控的服務。

**第二個原則**是模組的開發者需要面向介面開發，而不是面向實現；模組之間依賴介面，而不是具體的實現類。這樣做的好處是需要對模組進行擴充套件的時候，可以不需要修改已有的程式碼。我們也在 Erda Infra 中實現了依賴注入容器，透過類似 Spring 中 IoC 的方式，讓開發模組的人更關注自己負責的邏輯單元。

下面來看一個 Erda Infra 中最簡單的模組示例，我們把模組定義為 provider 結構，可以把需要注入的介面宣告在 provider 的欄位中，同時還需要實現 Init 、Run 函式來控制模組的生命週期，最後把定義好的模組註冊到全域性的服務容器中，即可完成一個微模組的實現。

![image.png](https://intranetproxy.alipay.com/skylark/lark/0/2021/png/114913/1627018674377-0183e12a-61cc-42a9-b051-4c0b183147bf.png#height=627&id=udb7d32cd&margin=%5Bobject%20Object%5D&name=image.png&originHeight=1264&originWidth=1612&originalType=binary&ratio=1&size=569058&status=done&style=none&width=800)

那麼我們如何在服務容器中定位到實現的介面呢？Erda Infra 提供了一個 Provide 介面，在這個介面中我們可以顯示宣告介面的具體實現，下面是 mysql-client 模組的宣告示例：

![image.png](https://intranetproxy.alipay.com/skylark/lark/0/2021/png/114913/1627018936223-45ba528d-0008-4c3b-9405-e71475717877.png#height=300&id=u96ba9d3c&margin=%5Bobject%20Object%5D&name=image.png&originHeight=636&originWidth=1696&originalType=binary&ratio=1&size=347005&status=done&style=none&width=800)

對於介面的獲取，Erda Infra 提供了自動注入和使用服務定位器來解析兩種方式。

自動注入和 Spring 的使用一樣，透過在欄位上標記 autowired 標籤即可生效：

![image.png](https://intranetproxy.alipay.com/skylark/lark/0/2021/png/114913/1627019038150-0814a8b2-52a0-46a7-bad6-655abbf16e52.png#height=466&id=ue10a2858&margin=%5Bobject%20Object%5D&name=image.png&originHeight=466&originWidth=900&originalType=binary&ratio=1&size=169659&status=done&style=none&width=900)

服務定位器模式則可以使用在後臺任務中，透過框架的服務上下文來獲取需要的介面具體實現：

![image.png](https://intranetproxy.alipay.com/skylark/lark/0/2021/png/114913/1627019096414-20f5e302-34e1-4524-adbe-e22930412b78.png#height=572&id=uc894cde0&margin=%5Bobject%20Object%5D&name=image.png&originHeight=572&originWidth=1128&originalType=binary&ratio=1&size=290739&status=done&style=none&width=1128)

最後再來聊一聊 Erda 中的 API 定義方式，我們把 API 統一都定義在 Protobuf 檔案中，這樣可以統一生成 gRPC、HTTP、OpenAPI 介面，以及 Client 的程式碼。

假設系統中有一個服務叫 Greeter ，定義如下所示。其中：透過 google.api.http 選項，來定義 http 相關的資訊，可以自動把請求的資料解析到 Path 引數和 Query 引數上。還可以透過在對應的介面上宣告 +publish 特殊的註釋，來表示釋出該介面到 OpenAPI 上，如果想要把某個介面強制標記為內部介面，那麼也可以透過  +private 註釋來實現。
```protobuf
// +publish prefix:"/api/greeter" backend-prefix:"/api" service:"user-center"
service GreeterService {
	// say hello
	// +publish
	rpc SayHello (HelloRequest) returns (HelloResponse)  {
	  option (google.api.http) = {
		get: "/api/hello/{name}",
	  };
	}
  }
  
  message HelloRequest {
	string name = 1;
  }
  
  message HelloResponse {
	string data = 1;
  }
```

Erda Infra 作為我們使用的基礎框架，現在還有一些不完善的地方，我們後續計劃繼續新增服務註冊發現的支援，來實現執行時的服務模組管理等，以此持續增強 Erda 的平臺擴充套件性。

### 總結
我們從 3 月開始計劃 Erda 的開源，到現在已經構建了第一個穩定的開源版本，第二個版本也將在近期釋出。

Erda 本身提供的一站式服務開發治理和資料治理功能已經非常豐富，我們接下來將會重點對使用者體驗和功能細節進行打磨，對開原始碼重構以提高程式碼質量，簡化平臺的安裝部署方式等。歡迎大家關注 Erda 開源專案，一起探討、交流雲原生 PaaS 相關的技術，共建開源社群。

- Erda Github 地址：[https://github.com/erda-project/erda](https://github.com/erda-project/erda)
- Erda Cloud 官網：[https://www.erda.cloud/](https://www.erda.cloud/)

基於 Golang 構建高可擴充套件的雲原生 PaaS（附 PPT 下載）

相關文章