掌門下一代容器發(fā)布系統(tǒng) Triton

CD 平臺是掌門的持續(xù)交付系統(tǒng)，Triton^[1] 作為 CD 平臺的核心容器發(fā)布組件，自 2020.4 月在 CD 平臺上正式上線，支撐了掌門近 1000 個(gè)應(yīng)用從虛機(jī)遷移至容器的過程，保障了虛機(jī)遷容器過程的穩(wěn)定性。目前，Triton 除了提供日常的應(yīng)用容器發(fā)布、網(wǎng)絡(luò)策略配置、Ingress 域名配置等能力之外，也成為其他組件、平臺的資源交付基座，比如，大規(guī)模的流水線交付^[2]，壓測平臺等。Triton 解決了應(yīng)用生命周期管理的問題，包括開發(fā)、部署、運(yùn)維等，同時(shí)打通了微服務(wù)治理，極大地幫助研發(fā)提升了持續(xù)交付的效率。

1. 背景

云原生架構(gòu)的快速普及帶來了企業(yè)基礎(chǔ)設(shè)施和應(yīng)用架構(gòu)等技術(shù)層面的革新。在 CNCF 2020 年度中國區(qū)云原生調(diào)查報(bào)告里面有一個(gè)亮眼的數(shù)字，72% 的受訪者已經(jīng)在生產(chǎn)環(huán)境當(dāng)中使用 Kubernetes，同期全球調(diào)查報(bào)告的數(shù)字是 83%?？梢钥吹?，在 Kubernetes 的使用率上，中國和全球是持平的。如果看純?nèi)萜魇褂寐?，則更加驚人，超過 92%。從這些數(shù)據(jù)來看，我們可以得出結(jié)論：Kubernetes 和容器已經(jīng)完全進(jìn)入主流市場，成為所有人都在使用的技術(shù)。

在此之前，掌門的應(yīng)用一直跑在虛機(jī)里，但是隨著應(yīng)用規(guī)模的不斷擴(kuò)大，虛機(jī)數(shù)量也隨之快速增加，我們開始在運(yùn)維成本、交付效率、應(yīng)用管理上面臨一些痛點(diǎn)：

1. 應(yīng)用數(shù)量不斷增加，基礎(chǔ)設(shè)施的成本隨之上升，降本迫在眉睫；
2. 業(yè)務(wù)飛速發(fā)展，內(nèi)部對資源、環(huán)境、應(yīng)用的交付效率的要求不斷提高；
3. 應(yīng)用數(shù)量增長很快，大量應(yīng)用的管理給運(yùn)維帶來很大壓力。

所以，為了能夠充分發(fā)揮云原生的優(yōu)勢，靈活地應(yīng)對變化和彈性擴(kuò)展以提升開發(fā)效率，加速迭代并降低成本，掌門于 2020 年 4 月份正式啟動容器化項(xiàng)目。

為了最大程度降低遷移容器過程中對開發(fā)和業(yè)務(wù)的影響，我們決定在應(yīng)用發(fā)布中完成從虛機(jī)到容器的遷移，以保障遷移過程中服務(wù)的穩(wěn)定性，實(shí)現(xiàn)不停服遷移。要實(shí)現(xiàn)這個(gè)目標(biāo)，一個(gè)全新的、支持容器發(fā)布的平臺呼之欲出，Triton 就是在這種背景下誕生的。下面將介紹容器發(fā)布平臺 Triton 的設(shè)計(jì)原理、實(shí)現(xiàn)方案。

2. Triton 設(shè)計(jì)原理及實(shí)現(xiàn)方案

在介紹 Triton 之前我們先看一下 CNCF 對持續(xù)交付的定義，涵蓋了一個(gè)云原生應(yīng)用的全生命周期流程，圖中的一些技術(shù)術(shù)語在本文中也會用到，比如 workload，rollout，canary等， 這篇文檔^[3] 中有詳細(xì)的介紹，需要的話可以查閱。

同時(shí)通過這張圖，也可以清晰地了解 Triton 在整個(gè)持續(xù)發(fā)布系統(tǒng)中的定位。Topic 1，Topic 1.5 的主要內(nèi)容是應(yīng)用模型描述，打包、參數(shù)配置；Topic 4 是資源管理，網(wǎng)絡(luò)，日志/監(jiān)控等平臺側(cè)的功能；而 Triton 聚焦的工作是在 Topic 2 和 Topic 3 ，主要內(nèi)容是應(yīng)用生命周期管理，流量管理，workload 管理，提供發(fā)布策略，比如藍(lán)綠部署、金絲雀部署等。

了解了 Triton 的定位后，下面將從方案選型，架構(gòu)設(shè)計(jì)，UI 交互 3 個(gè)維度來詳細(xì)介紹 Triton 的設(shè)計(jì)原理和實(shí)現(xiàn)方案。

2.1 方案選型

2.1.1 workload 選型

眾所周知，不管是無狀態(tài)的 Deployment 還是有狀態(tài)的 StatefulSet，kubernetes 都是支持服務(wù)的滾動更新的。我們也經(jīng)常在一些文章中看到有基于原生 Deployment 實(shí)現(xiàn)應(yīng)用的滾動發(fā)布和灰度發(fā)布，這種方式開發(fā)簡單容易上手，但是隨之帶來了很多缺陷，使得我們無法細(xì)粒度控制發(fā)布的過程，比如不支持發(fā)布過程中暫停、繼續(xù)，以及流量的優(yōu)雅拉入拉出等能力。

為了實(shí)現(xiàn)更豐富的發(fā)布策略以及更加細(xì)粒度的發(fā)布控制，以保障容器發(fā)布過程的安全、穩(wěn)定，Triton 選擇 OpenKruise^[4] 作為應(yīng)用的 workload。OpenKruise 是 Kubernetes 的一個(gè)標(biāo)準(zhǔn)擴(kuò)展，它可以配合原生 Kubernetes 使用，并為管理應(yīng)用容器、sidecar、鏡像分發(fā)等方面提供更加強(qiáng)大和高效的能力。OpenKruise 提供了很多原生 kubernetes 的增強(qiáng)型資源，CloneSet、Advanced StatefulSet、SidecarSet 等。其中，CloneSet 提供了更加高效、確定可控的應(yīng)用管理和部署能力，支持優(yōu)雅原地升級、指定刪除、發(fā)布順序可配置、并行/灰度發(fā)布等豐富的策略，可以滿足更多樣化的應(yīng)用場景，所以 Triton 選擇基于 CloneSet 來實(shí)現(xiàn)無狀態(tài)應(yīng)用的發(fā)布流程。

2.1.2 發(fā)布流程技術(shù)選型

如何定義一種發(fā)布流程，并按照流程的定義去實(shí)現(xiàn)本次發(fā)布？為了尋找一些靈感，在設(shè)計(jì) Triton 之前我們調(diào)研了目前在云原生領(lǐng)域做得比較好的的一些 CI/CD 組件，像云原生 CI 工具 Tekton，交付工具 Argo 都是設(shè)計(jì)了一套 CRD （自定義資源），然后在 Operator 中實(shí)現(xiàn)相應(yīng)的邏輯以達(dá)到最終的目標(biāo)狀態(tài)（Operator 是由 CoreOS 開發(fā)的，用來擴(kuò)展 Kubernetes API，特定的應(yīng)用程序控制器，其基于 Kubernetes 的資源和控制器概念之上構(gòu)建，但同時(shí)又包含了應(yīng)用程序特定的領(lǐng)域知識。創(chuàng)建 Operator 的關(guān)鍵是 CRD 的設(shè)計(jì)）。

于是我們采用云原生的方式設(shè)計(jì)容器發(fā)布，原生為云而設(shè)計(jì)，在云上運(yùn)行，充分利用和發(fā)揮云平臺的彈性+分布式優(yōu)勢。我們設(shè)計(jì)了一種 CRD 來描述一次容器發(fā)布的完整流程，這樣每次發(fā)布只需要?jiǎng)?chuàng)建 CRD 資源，就能定義好本次的發(fā)布流程，后續(xù)只需要在此資源基礎(chǔ)上修改即可。經(jīng)過內(nèi)部討論，最終該 CRD 被命名為 DeployFlow，即發(fā)布流的意思，關(guān)于 DeployFlow 的詳細(xì)介紹請繼續(xù)閱讀下面的架構(gòu)設(shè)計(jì)。

2.2 架構(gòu)設(shè)計(jì)

在解決了 workload 和發(fā)布流程的技術(shù)選型后，DeployFlow 這個(gè) CRD 的設(shè)計(jì)就成為了我們要去聚焦的核心工作。下圖展示了 Triton 的主要設(shè)計(jì)架構(gòu)，可以看到在 Kubernetes 和 OpenKruise 的基礎(chǔ)之上，完成一次發(fā)布需要的配置由 CRD 定義，發(fā)布流程相關(guān)的邏輯控制通過 Operator 實(shí)現(xiàn)，同時(shí) Triton 提供 REST、GRPC API 和前端 UI 實(shí)現(xiàn)交互。

2.2.1 DeployFlow 和 Operator 實(shí)現(xiàn)

首先介紹下 DeployFlow 這個(gè) CRD，通過 DeployFlow 我們定義了一次發(fā)布中需要的配置以及發(fā)布過程中需要的狀態(tài)展示。

// DeployFlow is the Schema for the deploys API
type DeployFlow struct {
 metav1.TypeMeta   `json:",inline"`
 metav1.ObjectMeta `json:"metadata,omitempty"`

 Spec   DeployFlowSpec   `json:"spec,omitempty"`
 Status DeployFlowStatus `json:"status,omitempty"`
}

Spec 字段的內(nèi)容分為兩部分，一部分是與應(yīng)用相關(guān)的信息，比如 AppID、GroupId、副本數(shù)量、AppName等，另一部分是指定發(fā)布策略，比如是 create還是 update 操作，是 scale in 還是 scale out，不同的操作對應(yīng)不同的發(fā)布策略，詳細(xì)的字段解釋可以通過下面代碼來理解。

type DeployFlowSpec struct {
 // Important: Run "make" to regenerate code after modifying this file

 AppID        int    `json:"appID"`
 GroupID      int    `json:"groupID"`
 AppName      string `json:"appName"`
 ......
 Action       string `json:"action"`

 // +nullable
 UpdateStrategy *DeployUpdateStrategy `json:"updateStrategy,omitempty"`

 // +nullable
 NonUpdateStrategy *DeployNonUpdateStrategy `json:"nonUpdateStrategy,omitempty"`
}

DeployUpdateStrategy 代表了本次發(fā)布是一次更新操作，也就是會使 CloneSet 中的 UpdateRevision 字段發(fā)生變化，一般 create、update rollback 就是采用 DeployUpdateStrategy 的字段定義。

DeployNonUpdateStrategy 代表本次發(fā)布不會觸發(fā)資源更新，也就是 UpdateRevision 不會發(fā)生變化，一般 scale in、scale out、restart 等操作要采用 DeployNonUpdateStrategy。

不同的發(fā)布策略肯定有不同的字段，但大部分的策略都是可以共用的，所以在此之上我們抽象出一個(gè)基礎(chǔ)發(fā)布策略 BaseStrategy，由于 BaseStrategy 中的字段太多，我們這里放一張 CRD 的 schema 資源視圖，然后再選擇其中重要的字段進(jìn)行解釋。

先介紹 DeployPhase 字段，DeployPhase 表示一次發(fā)布過程中，DeployFlow 所經(jīng)歷的階段。

字段的意思都比較好理解，這里就不展開講 了。

在 BaseStrategy 中有個(gè)比較重要的字段 - BatchSize ，表示批次大小。這意味著 DeployFlow 支持分批次發(fā)布，用戶可以自定義每個(gè)批次最大發(fā)布的副本數(shù)量，DeployFlow 會計(jì)算出本次發(fā)布的總批次是多少從而提前給出發(fā)布概覽。

從 BaseStrategy 的 paused、canceled 字段就可以知道，在發(fā)布過程中可以隨時(shí)暫停、繼續(xù)或者取消本次發(fā)布。Mode 表示 DeployFlow 不同批次之間的觸發(fā)方式，分為 auto 和 manual 兩種，當(dāng)選擇 auto 模式的時(shí)候，通過字段 BatchIntervalSeconds 可以設(shè)置不同批次之間的時(shí)間間隔，如果選擇手動模式則每個(gè)批次之間需要手工觸發(fā)。

由于 DeployFlow 是分批次發(fā)布，所以每個(gè)批次需要有階段顯示 - BatchPhase ，以表示當(dāng)前的批次所處的階段，我們來詳細(xì)解釋每種階段的含義。

BatchPending: 表示當(dāng)前批次的 pod 正在準(zhǔn)備資源，比如此時(shí) pod 正在被調(diào)度中，image 在下載中，對應(yīng) Kubernetes 中的 pod 處于 Pending，ContainerCreating 狀態(tài)。

BatchSmoking: 表示當(dāng)前批次的 pod 正在啟動過程中，pod 處于 Running 狀態(tài)，但是 ContainerReady 字段還沒有置為 true。

BatchSmoked: 表示當(dāng)前批次的所有 pod 都已經(jīng)啟動成功，也就是 pod 中的 ContainerReady 字段已經(jīng)被置為 true，但是 Ready 字段還處于 false。此時(shí)如果通過 service 來處理服務(wù)流量的話，啟動的 pod 并不會被加入到對應(yīng) service 的 endpoint，如果是微服務(wù)架構(gòu)，則該 pod 并不會被拉入到微服務(wù)的注冊中心，從而保證了業(yè)務(wù)流量的安全。正是擁有了這種機(jī)制以及批次間可暫停的能力，我們可以輕松實(shí)現(xiàn)應(yīng)用的金絲雀發(fā)布，這個(gè)在后面還會詳細(xì)講到。

BatchBaking: 表示當(dāng)前批次的所有 pod 都已經(jīng)啟動成功，正在執(zhí)行流量拉入操作，也就是將 pod 的 Ready 字段置為 true。

BatchBaked: 表示當(dāng)前批次的所有 pod 的 Ready 字段都已被置為 true，pod 開始接收生產(chǎn)流量，至此也意味著本批次的結(jié)束，可以開始下一批次的操作。

在批次進(jìn)行過程中，會有 smoke 失敗或者 bake 失敗的情況，對應(yīng)的狀態(tài)就是 SmokeFailed和 BakeFailed。

在 UpdateStrategy 中有一個(gè) canary 字段，意味著 DeployFlow 支持金絲雀發(fā)布。其實(shí)在講解了上述 DeployFlow 分批次處理的能力后，在此基礎(chǔ)之上實(shí)現(xiàn)金絲雀發(fā)布是比較簡單的。也就是在金絲雀批次處于 BatchSmoked 狀態(tài)的時(shí)候，讓發(fā)布暫停，在流量拉入之前也可以進(jìn)行一些 API 驗(yàn)證的操作，開發(fā)者在驗(yàn)證沒問題之后手工將該批次拉入，拉入金絲雀批次后， DeployFlow 也處于暫停的狀態(tài)，此時(shí)開發(fā)者可以觀察線上流量的監(jiān)控，確認(rèn)沒有問題后再執(zhí)行后面批次的發(fā)布。后面的 UI 交互會更加直觀地展示該功能，這里我們先通過一張 DeployFlow 的狀態(tài)流轉(zhuǎn)示意圖完整地展示一次發(fā)布的過程，我們以本次發(fā)布分為兩個(gè)批次為例，金絲雀批次和普通批次。結(jié)合本圖與上文的 CRD 解釋，相信讀者會對 DeployFlow 有一個(gè)更加清晰的認(rèn)知。

至此，在 DeployUpdateStrategy 、BaseStrategy 中的核心字段都已經(jīng)介紹完了，在 DeployNonUpdateStrategy 中還有一個(gè) PodsToDelete 字段，這個(gè)字段是在應(yīng)用縮容、重啟操作時(shí)起作用的，原生 Kubernetes 對于資源的縮容操作有自己的規(guī)則，不能隨意選擇想要縮容的 pod。但是在 DeployFlow 中，你可以指定 pod 縮容，指定 pod 重啟。

通過上面的介紹，讀者對 DeployFlow 這個(gè) CRD 的 spec 字段有了一定了解，下面來看下發(fā)布過程中我們需要展示的 status 字段。

熟悉 Kubernetes 的同學(xué)應(yīng)該能夠從字段的字面意思了解這些字段的含義，這里就不詳細(xì)展開了。

CRD 設(shè)計(jì)完成后，Operator 的實(shí)現(xiàn)也就是水到渠成的事情了，除了 DeployFlow 的 Operator，Triton 中還重新實(shí)現(xiàn)了一些 controller 來滿足個(gè)性化的需求，比如 Event controller 用來將發(fā)布過程中 pod、Cloneset、DeployFlow 等組件的日志發(fā)送到 ES 以方便開發(fā)者查看發(fā)布的情況，ReadinessGates controller 用來控制自定義 ReadinessGate 的拉入拉出操作等。

同時(shí) Triton 提供 REST & GRPC API 來操作 DeployFlow，調(diào)用方即使不了解容器和 Kubernetes 的知識，也可以很容易對接到 Triton 上實(shí)現(xiàn)發(fā)布的功能。

2.3 UI 交互

底層架構(gòu)以及核心組件 DeployFlow 的設(shè)計(jì)邏輯雖然稍顯復(fù)雜，但得益于 Triton 暴露的 REST & GRPC API 以及豐富的 status 字段，使得前端在發(fā)布的 UI 交互邏輯上能夠做到簡潔直觀。下面讓我們從 UI 入手，看下 Triton 如何進(jìn)行應(yīng)用的交付以及對應(yīng)用的副本實(shí)例的規(guī)劃。

2.3.1 發(fā)布入口及發(fā)布清單

進(jìn)入生產(chǎn)發(fā)布頁面，在容器發(fā)布頁簽，選擇需要發(fā)布的 group，點(diǎn)擊“發(fā)布”。

點(diǎn)擊后彈出一個(gè)發(fā)布清單的頁面，在這里需要配置本次發(fā)布需要的策略以及相關(guān)參數(shù)。

其中有些參數(shù)在上面的 CRD 設(shè)計(jì)篇章中已經(jīng)有所描述，比如應(yīng)用描述，批次大小，批次間處理方式，批次間隔等，這里不再贅述。啟動超時(shí)時(shí)間 是開放給開發(fā)者自定義應(yīng)用需要用來啟動的時(shí)間，比如有些應(yīng)用尤其是 java 應(yīng)用，在真正啟動之前需要執(zhí)行一些 warm up 的操作，開發(fā)者就可以根據(jù)自己應(yīng)用的實(shí)際情況填寫該值，避免這類應(yīng)用啟動失敗。微服務(wù)拉出等待時(shí)間 是用來支持微服務(wù) pod 優(yōu)雅退出的。

那何謂優(yōu)雅退出，為什么要優(yōu)雅退出呢？在Kubernetes 中當(dāng)刪掉一個(gè) pod 的時(shí)候，理想狀況當(dāng)然是 Kubernetes 從對應(yīng)的 Service(假如有的話)把這個(gè) pod 摘掉，同時(shí)給 pod 發(fā) SIGTERM 信號讓 pod 中的各個(gè)容器優(yōu)雅退出就行了。但實(shí)際上 pod 有可能犯各種幺蛾子:

• 已經(jīng)卡死了，處理不了優(yōu)雅退出的代碼邏輯或需要很久才能處理完成;
• 優(yōu)雅退出的邏輯有 BUG，自己死循環(huán)了;
• 代碼寫得野，根本不理會 SIGTERM;

因此，Kubernetes 的 pod 終止流程中還有一個(gè)“最多可以容忍的時(shí)間”，即 grace period (在 pod 的 .spec.terminationGracePeriodSeconds 字段中定義)，這個(gè)值默認(rèn)是 30 秒，我們在執(zhí)行 kubectl delete 的時(shí)候也可通過 --grace-period 參數(shù)顯式指定一個(gè)優(yōu)雅退出時(shí)間來覆蓋 pod 中的配置。而當(dāng) grace period 超出之后，Kubernetes 就只能選擇 SIGKILL 強(qiáng)制干掉 pod 了。

但是在微服務(wù)的場景下，除了把 pod 從 Kubernetes 的 Service 上摘下來以及進(jìn)程內(nèi)部的優(yōu)雅退出之外，我們還必須做一些額外的事情，比如說從 Kubernetes 外部的服務(wù)注冊中心上反注冊，不然可能會出現(xiàn) pod 已經(jīng)被刪掉，但是注冊中心上還留著已刪掉 pod 的服務(wù)信息，此時(shí)有流量進(jìn)入的話就會出現(xiàn)服務(wù)不可用的情況。所以我們在 prestop hook 中定義了一個(gè)名為 gracefully_shutdown 的文件來處理 pod 刪除后的微服務(wù)優(yōu)雅退出。

spec:
  contaienrs:
  - name: demo-container
    lifecycle:
      preStop:
        exec:
          command: ["/bin/sh"，"-c"，"/gracefully_shutdown"]

右側(cè)的發(fā)布策略以及本次發(fā)布概覽在之前的架構(gòu)設(shè)計(jì)中已經(jīng)講過，這里不在贅述。

2.3.2 開始發(fā)布

完成發(fā)布配置后，即可開始發(fā)布。

• 發(fā)布進(jìn)度：展示發(fā)布的批次，及各個(gè)批次所啟動的實(shí)例數(shù)量和狀態(tài)。在發(fā)布過程中，人工操作的入口也在此區(qū)域；
• 實(shí)例列表：展示發(fā)布的實(shí)例，可以切換實(shí)例版本查看各版本的實(shí)例；
• 副本狀態(tài)：形如 0/1/0/0 對應(yīng) Pending/Running/Ready/Failed 四個(gè)狀態(tài)的數(shù)量(1個(gè) pod 在發(fā)布中)，其中 Running 對應(yīng)發(fā)布中實(shí)例數(shù)，Ready 發(fā)布成功實(shí)例數(shù)，Failed 發(fā)布失敗實(shí)例數(shù)。

2.3.3 發(fā)布過程

一個(gè)典型的發(fā)布包括“金絲雀批次啟動（Smoking）”-“金絲雀批次點(diǎn)火（Baking）”-“滾動發(fā)布（Rollout）” 三個(gè)階段。

1. 金絲雀批次啟動中（Smoking）

2. 金絲雀批次啟動成功，可以驗(yàn)證接口，確認(rèn)沒問題，可將其拉入點(diǎn)火（Baking）

3. 金絲雀批次點(diǎn)火中，實(shí)例已接流量，由于此時(shí) DeployFlow 處于暫停狀態(tài)，開發(fā)者可以有充足的時(shí)間可觀察日志、監(jiān)控等是否有異常，確認(rèn)沒問題后再觸發(fā)滾動發(fā)布（Rollout）

4. 滾動發(fā)布中，如選擇“手動” 模式，每個(gè)滾動批次都需要人為觸發(fā)

滾動發(fā)布過程中，可以看到新舊實(shí)例的版本數(shù)量在交替變化。

5. 發(fā)布成功

至此，一次完整的 DeployFlow 流程就走完了，發(fā)布到達(dá)成功的狀態(tài)?？梢钥吹矫總€(gè)批次所負(fù)責(zé)的 pod 數(shù)量以及 pod 狀態(tài)、日志等信息。

2.3.4 指定實(shí)例的操作

在實(shí)例運(yùn)行過程中，如果發(fā)現(xiàn)實(shí)例負(fù)載異?；蛐枰匦录虞d apollo 配置，就會有重啟實(shí)例的需求。Kubernetes 本身沒有提供重啟的操作邏輯，一般通過殺掉一個(gè) pod 來達(dá)到重啟的效果，但這種方式比較粗暴而且存在安全隱患。Triton 提供了安全的重啟策略，會先新增一個(gè) pod 如果該 pod 啟動成功成功，再刪掉你所指定要重啟的 pod，以此來達(dá)到安全重啟的效果，這就是 Triton 的指定實(shí)例重啟的功能。

同樣的原理，縮容的操作也可以指定想要縮掉的 pod 。

該功能的實(shí)現(xiàn)得益于 OpenKruise 中增強(qiáng)型無狀態(tài) workload CloneSet 提供的能力，具體的功能描述可以參考 OpenKruise 文檔。

上面的內(nèi)容就是有關(guān) Triton 核心能力的 UI 交互，整個(gè)過程力求簡潔、清晰，避免給開發(fā)者造成額外的理解負(fù)擔(dān)，這為我們?nèi)萜鞯慕尤搿⑼七M(jìn)提供了很大的便捷。

3. 總結(jié)與展望

每個(gè)公司的容器發(fā)布平臺都不盡相同，可能會有讀者看完說 Triton 封裝了太多的 Kubernetes 細(xì)節(jié)，沒有向開發(fā)者真正展示原生 Kubenetes 的狀態(tài)、含義或者理念。其實(shí)從一開始，我們的目標(biāo)就是設(shè)計(jì)適用于掌門自身研發(fā)體系的容器發(fā)布系統(tǒng)，減少開發(fā)對發(fā)布操作的學(xué)習(xí)成本，從而快速上手以更快地賦能研發(fā)流程的迭代，加速業(yè)務(wù)應(yīng)用的上線。而簡潔清晰的 API 也有利于我們設(shè)計(jì)出更加簡單的用戶界面，簡單的用戶界面又讓我們在推廣時(shí)受益。

上圖是 Triton 的一些關(guān)鍵指標(biāo)，可見 Triton 已經(jīng)成為 CD 平臺的核心能力，在用戶需求的迭代中不斷進(jìn)化，不過，現(xiàn)在的 Triton 依然有很大的優(yōu)化空間，主要有：

1. 掌門有大量的 socket 長連接應(yīng)用，對于這類應(yīng)用的容器化，以及容器化后如何發(fā)布，還沒有清晰的設(shè)計(jì)方案；
2. Triton 按應(yīng)用粒度進(jìn)行發(fā)布，不支持跨應(yīng)用的發(fā)布流程編排;
3. 對開發(fā)者快速拉起本地測試環(huán)境的支持較弱。

我們目前也在進(jìn)行針對這些優(yōu)化項(xiàng)的工作。

我們團(tuán)隊(duì)負(fù)責(zé)掌門研發(fā)效能平臺的建設(shè)，服務(wù)于掌門所有研發(fā)人員。作為掌門研發(fā)體系的核心組成部分，致力于保障高質(zhì)量的交付和研發(fā)效率的提升。當(dāng)前 CD 平臺已經(jīng)在 CI/CD 和監(jiān)控告警形成閉環(huán)，今后我們會沿著需求、設(shè)計(jì)、開發(fā)、構(gòu)建、驗(yàn)證、發(fā)布這個(gè)路徑進(jìn)行更廣的探索，打造真正的研發(fā)效能平臺。目前掌門正在進(jìn)行生產(chǎn)環(huán)境容器化的升級，如果你對 Triton 或者 Kunernetes 感興趣，歡迎加入我們一起打磨生產(chǎn)應(yīng)用容器化的設(shè)計(jì)與落地方案。

參考資料