翻譯、編排：Dancy

【譯者按：本文介紹了Slack公司如何通過在CI/CD中實現(xiàn)編排級的斷路器（orchestration-level circuit breakers）來提高開發(fā)人員的生產(chǎn)力并防止內(nèi)部級聯(lián)故障的發(fā)生。斷路器：類似于電路的保險絲，可以將需要保護的遠程服務(wù)用“斷路器” 封裝起來，在內(nèi)部監(jiān)聽失敗次數(shù)， 一旦失敗次數(shù)達到某閥值后，所有后續(xù)對該服務(wù)的調(diào)用被斷路器截獲，并直接返回錯誤到調(diào)用方，而不會繼續(xù)調(diào)用已經(jīng)出問題的服務(wù)， 從而達到保護調(diào)用方的目的, 整個系統(tǒng)也就不會出現(xiàn)因為超時而產(chǎn)生的瀑布式連鎖反應(yīng)。】

當一個分布式的服務(wù)系統(tǒng)面對海量內(nèi)部請求的挑戰(zhàn)時，會發(fā)生什么情況？如何防止內(nèi)部服務(wù)之間的級聯(lián)故障？當我們對系統(tǒng)進行簡單的水平擴展或垂直擴展并分別達到極限時，應(yīng)該如何重新構(gòu)建開發(fā)的工作流（workflow）？ 回到2020年，以上這些都是Slack公司的工程師們在開發(fā)工作流中經(jīng)常面臨的挑戰(zhàn)。工程師們使用的多個內(nèi)部服務(wù)被拉伸到了極限，導(dǎo)致服務(wù)之間出現(xiàn)級聯(lián)故障。級聯(lián)故障是正反饋回路，如果系統(tǒng)的某個部分規(guī)模化地出現(xiàn)故障，就會導(dǎo)致相鄰系統(tǒng)的請求排隊，從而導(dǎo)致該系統(tǒng)規(guī)模化地出現(xiàn)故障。幾年以來，由于兩個因素，我們的內(nèi)部工具和服務(wù)團隊很難應(yīng)對每月10%的CI/CD請求增長：第一，內(nèi)部人員數(shù)量的增長；第二，服務(wù)和測試的復(fù)雜性。當故障發(fā)生時，整個開發(fā)團隊的開發(fā)速度會變得緩慢，內(nèi)部工具開發(fā)工程師和基礎(chǔ)設(shè)施工程師不得不想辦法盡快恢復(fù)服務(wù)。為了實現(xiàn)這個目標，這些工程師們一般采用以下方式：

將Github Enterprise等設(shè)備擴展到AWS中可提供的最大硬件容量（限制了未來的垂直擴展）。

使用更多的節(jié)點來擴展一項服務(wù)以應(yīng)對新的峰值負載（但卻發(fā)現(xiàn)這會導(dǎo)致基礎(chǔ)設(shè)施中另一項服務(wù)的失敗）。

當然，這些解決方案只能在我們的內(nèi)部服務(wù)達到一個新的峰值負載之前發(fā)揮作用。我們需要一種新的方式來思考這個問題。

本文介紹了Slack的工程師如何通過在內(nèi)部工具中實施編排級的斷路器機制幫助開發(fā)人員提高生產(chǎn)力。Checkpoint是一個CI/CD的編排服務(wù)。開發(fā)者生產(chǎn)力團隊中的工程師們采用了斷路器讓Checkpoint中的請求被推遲或放棄。

CI/CD編排和Webapp中復(fù)雜性和規(guī)模化帶來的挑戰(zhàn)

回到2020年，我們看到兩類相互關(guān)聯(lián)的問題：規(guī)模化和復(fù)雜性。工程師們建立并采用了持續(xù)集成流水線（CI）進行開發(fā)，使用了持續(xù)交付流水線（CD）將Slack系統(tǒng)部署和發(fā)布到生產(chǎn)環(huán)境中。Checkpoint是我們的內(nèi)部平臺，用于調(diào)度代碼的構(gòu)建、測試、部署和發(fā)布。隨著時間的推移，Slack的開發(fā)人員和功能發(fā)布的數(shù)量都不斷增加，這也轉(zhuǎn)化為CI/CD的額外負載。隨著更多功能的發(fā)布，工程師們還編寫了自動化測試腳本以支持新功能的測試。

圖1? Slack Webapp架構(gòu)圖。客戶端連接到三個不同的API，以便實時有效地呈現(xiàn)用戶看到的內(nèi)容

開發(fā)人員數(shù)量和功能發(fā)布數(shù)量這兩個增長矢量導(dǎo)致了定期發(fā)生的新的負載高峰，也會導(dǎo)致個別服務(wù)出現(xiàn)新的故障模式，然后發(fā)生級聯(lián)故障（內(nèi)部服務(wù)之間）和事故。每個服務(wù)都以不同的速度在演進，不一定能通過水平或垂直擴展輕松適應(yīng)新的峰值（下面的例子）。

當故障發(fā)生時，工程師們被召集起來處理大規(guī)模的內(nèi)部事故，解決這些級聯(lián)故障。盡管這些事故沒有影響到Slack的客戶，但仍然占用了工程師們的工作時間，而且往往涉及多個團隊并持續(xù)多天。在事故發(fā)生時，Slack的開發(fā)人員需要忍受持續(xù)集成流水線中測試執(zhí)行的速度下降甚至是停止，以及持續(xù)交付流水線的可用性受到限制等問題。

CI測試/CD工作流會出現(xiàn)Git錯誤，當每天的峰值測試數(shù)量超過了Git應(yīng)用程序可以提供的服務(wù)，就導(dǎo)致Checkpoint（異步作業(yè)處理）中用于調(diào)度測試的任務(wù)增加，讓Checkpoint和Jenkins中執(zhí)行測試的隊列變長。工程師們在測試受限的情況下繼續(xù)進行開發(fā)，讓任務(wù)隊列變得越來越長。

Git是CI流水線和開發(fā)者工具的基礎(chǔ)工具。Git的規(guī)模化問題在建立抽象（如谷歌的Piper）或替代源控制（如Facebook的Mercurial）的大型組織中被充分的記錄下來。2019年，Slack內(nèi)部工具采用Git LFS來處理大文件。在這段時間里，Git設(shè)備一直在垂直方向上擴展。Git中大型 repo的增長對開發(fā)人員一直是一個挑戰(zhàn)，可以通過定制的源碼控制系統(tǒng)（如Piper或Github的monorepo維護）來解決。

Checkpoint有一個內(nèi)部異步任務(wù)隊列（使用自我托管的main-main MySQL，現(xiàn)在使用的是AWS的RDS Aurora），以保持CI/CD編排的狀態(tài)。這個任務(wù)隊列和調(diào)度器會重試失敗的請求。調(diào)度器限制了并發(fā)任務(wù)，以減少負載和數(shù)據(jù)庫上的失敗請求。當一個隊列中有太多的任務(wù)（如測試請求任務(wù)）時，這種有限的并發(fā)性造成滯后，導(dǎo)致CI/CD的用戶重復(fù)請求同一個任務(wù)，從而引發(fā)正反饋循環(huán)和更長的隊列。

在過去，為了應(yīng)對開發(fā)人員數(shù)量的持續(xù)增長，Slack公司的內(nèi)部工具工程師需要定期增加測試執(zhí)行器（test executor）和測試環(huán)境的數(shù)量。如果沒有注意負載極限，來自測試（即測試執(zhí)行器）和Slack環(huán)境（即待測試代碼）的大規(guī)模請求，會導(dǎo)致更多的請求超過CI中的搜索集群可以處理的上限，從而引入錯誤，當然，更多的是增加了對CI/CD流水線的負載。

圖2CI服務(wù)和工具之間級聯(lián)故障的工作流程實例

為什么復(fù)雜性很重要

在Slack公司中，我們通過集成測試和端到端的測試來驗證多個服務(wù)重疊的復(fù)雜工作流的正確性。雖然在開始時公司只有一個服務(wù)（Webapp），但目前已經(jīng)發(fā)展成多個支持用戶體驗的服務(wù)。Slack客戶端連接到三個不同的API，向用戶實時呈現(xiàn)內(nèi)容（見圖1中簡化的架構(gòu)圖）。Slack公司的Webapp是一個復(fù)雜的應(yīng)用程序，包括許多配置（如團隊、企業(yè)和跨企業(yè)信息）。為了測試復(fù)雜的代碼路徑，產(chǎn)品和測試工程師專注于編寫自動化測試，這依賴于大量的移動部件（見圖2）。

斷路器

軟件斷路器是一個從系統(tǒng)工程中借用的概念，它用來檢測外部系統(tǒng)的故障并中斷對已知故障系統(tǒng)的調(diào)用。客戶端是采用斷路器的典型位置。由于我們的CI/CD編排層調(diào)節(jié)了請求在系統(tǒng)中的流動，因此，在將請求發(fā)送給下一個系統(tǒng)之前，我們在編排器消費者服務(wù)中實現(xiàn)了具有斷路器功能的客戶端，同時有多個并發(fā)的任務(wù)調(diào)用客戶端。

圖3斷路器控制流程圖

我們有一個假設(shè)，即斷路器可以最大限度地減少級聯(lián)故障，并提高多個服務(wù)的程序化度量查詢的利用率，而不是基于單個客戶端或服務(wù)的方法。與單個服務(wù)中的傳統(tǒng)斷路器不同，編排級系統(tǒng)的斷路器可以調(diào)節(jié)系統(tǒng)間的請求接口。

當系統(tǒng)所依賴的服務(wù)遇到負載增加的情況或由于負載增加而顯示錯誤時，斷路器就會打開。Checkpoint以編程方式從多個依賴服務(wù)中檢索健康指標。如果下游系統(tǒng)不能為這些請求提供服務(wù)，那么請求將被推遲或放棄。當依賴服務(wù)顯示恢復(fù)時，斷路器將關(guān)閉，這些被推遲的請求將再次開始執(zhí)行。這種對已知故障請求的管理減少了影響構(gòu)建、測試、部署和發(fā)布代碼能力的級聯(lián)故障事件，并減少了CI中的故障執(zhí)行。

實現(xiàn)方法

讓我們從一個用Hacklang實現(xiàn)的抽象類開始，以此為基礎(chǔ)進行討論，并為這個新的工作流創(chuàng)建原型。這里我們討論的重點不是構(gòu)建或測試客戶端，而是Checkpoint，即編排服務(wù)，Checkpoint負責(zé)協(xié)調(diào)CI/CD工作流，其后臺工作系統(tǒng)代表了Slack的構(gòu)建、測試、部署和發(fā)布的命脈。Checkpoint有一個API端點，當一個新的commit被創(chuàng)建時，API端點可以接收GitHub的webhook。從這個commit中，Checkpoint會排入多個后臺任務(wù)，觸發(fā)Jenkins構(gòu)建或測試，然后更新數(shù)據(jù)庫中的測試結(jié)果。

我們選擇在Checkpoint后臺任務(wù)中關(guān)注帶有延遲和減載的斷路。雖然斷路器可以存在于客戶端邏輯中（例如，等待恢復(fù)或阻止工作），但Checkpoint的后臺任務(wù)系統(tǒng)提供了一個獨特的機會，因為它是多個系統(tǒng)之間的調(diào)度程序的中介。

我們使用Trickster在幾個使用PromQL的Prometheus集群中對依賴性服務(wù)指標進行編程式查詢。這個服務(wù)是對多個Prometheus群進行查詢的前端、代理和緩存。

由于內(nèi)部后臺任務(wù)重試和使用延遲的CI請求，Checkpoint不需要半開放狀態(tài)（half-open state）。半開放狀態(tài)對于單獨的客戶端請求和提示這些客戶端的恢復(fù)非常重要。但由于Checkpoint的后臺任務(wù)系統(tǒng)提供重試功能，而且這個斷路器包含了Prometheus查詢的TTL，一旦一個開放的斷路器恢復(fù)，Checkpoint就會隨時恢復(fù)工作。

namespace CheckpointCircuitBreaker;
use type SlackCheckpointPromClient;

/*
* Generic interface for Circuit Breakers in Checkpoint.
* Downstream actions include deferral mechanisms or load shedding.
* @see https://martinfowler.com/bliki/CircuitBreaker.html
*/

enum CircuitBreakerState: string {
  CLOSED = 'closed';
  OPEN = 'open';
}

abstract class CircuitBreaker {

  /**
   * Get the state of this circuit breaker. Note the return value is intentionally
   * not a `Result`. In the case of internal errors, this must
   * decide if the breaker fails open/closed.
   */
  abstract protected function getState(): CircuitBreakerState;

  /**
   * Allow for bypassing a circuit breaker. Used as a circuit breaker for circuit breakers.
   * In a subsequent class, add the following to always allow the request to pass through
   * <<__Override, __Memoize>>
   * public function bypass(): bool { return true; }
   */
  public function bypass(): bool {
    return false;
  }

  public function allowRequest(): bool {
    $state = $this->getState();
    PromClient::circuit_breaker_requests()->inc(1, darray[
      'breaker_type' => (string)static::class,
      'breaker_state' => (string)$state,
    ]);
    if ($this->bypass()) return true;
    return $state === CircuitBreakerState::CLOSED;
  }
}

在第一個代碼實現(xiàn)的sprint中，我們實現(xiàn)了編排服務(wù)健康的斷路器。

當Checkpoint和Jenkins隊列達到一定閾值時，推遲測試任務(wù)。

當所有Slack測試環(huán)境都很忙時，推遲端到端的測試任務(wù)。

為分支上的較早的commit消減測試執(zhí)行的負載。

對于任何有持續(xù)失敗的套件，消減測試重試的負載。

在第二個sprint中，我們實現(xiàn)了共享依賴服務(wù)的斷路器。

Flannel ：在全球多個地區(qū)的邊緣緩存，返回經(jīng)常獲取的團隊范圍的數(shù)據(jù)。

Vitess：所有客戶數(shù)據(jù)的真實來源（采用MySQL語法）。Vitess是一個數(shù)據(jù)庫解決方案，用于部署、擴展和管理大型數(shù)據(jù)庫實例集群。

搜索：提供信息、文件和人的索引的服務(wù)，計算實時集合（通過工作隊列實時提供）和每周集合（用從時間開始的信息進行離線計算）。

Flannel的簡化實現(xiàn)代碼如圖5所示，包括：緩存中的查詢（連同TTL），Prometheus范圍查詢，用戶信息傳遞，以及使用Prometheus范圍查詢對Trickster的調(diào)用。安全性在這里很重要，如果Trickster/Prometheus集群返回一個錯誤，我們讓斷路器保持關(guān)閉，允許請求流過。同樣地，我們?yōu)楫惒饺蝿?wù)之間一致的客戶請求緩存響應(yīng)。

namespace CheckpointCIBotCircuitBreaker;

use namespace Checkpoint{CIIssue, Trickster};

use type CheckpointCIBotDelta{DeltaAnomalyType, DeltaDimensionType};
use type CheckpointCIIssueServiceDepCircuitBreakerType;
use type CheckpointCircuitBreaker{Cacheable, CircuitBreaker, CircuitBreakerState};
use type SlackCheckpointPromClient;

type flannel_callback_error_rate_cache_t = shape(
'ts' => int,
'error_rate' => int,
);

final class FlannelServiceDepCircuitBreaker extends CircuitBreaker {
   use Cacheable;

   const int TTL = 60; // Time-to-Live for cached value
   const int FLANNEL_CALLBACK_ERROR_RATE_THRESHOLD = 5;
   const string PROM_FLANNEL_CLUSTER = 'flannel';
   const string PROM_FLANNEL_QUERY_GLOBAL = 'sum(dcirate1m{error!~"org_login_required"})';
   const string ISSUE_MESSAGE_OPEN = '   Flannel Circuit Breaker is open. Tests are deferred';
   const string ISSUE_MESSAGE_CLOSE = 'This circuit breaker is closed. Tests are starting again';
   const string ISSUE_KEY = ServiceDepCircuitBreakerType::FLANNEL;

   public function __construct(private ?github_repos_t $repo = null, private ?TSlackjsonValidatorPropertiesCheckpointPropertiesTestsItems $test = null) {}

   <<__Override, __Memoize>>
   public function getState(): CircuitBreakerState {

       $cached_key = $this->getCacheKey(self::class, 'flannel_callback_errors');
       $cached_data = cache_get($cached_key);
       $existing_error_rate = 0;

       // If the cache exists, and is fresh enough, use it. Default to Closed
       $result = type_assert_type($cached_data, flannel_callback_error_rate_cache_t::class);
       if ($result->is_error()) { return CircuitBreakerState::CLOSED; }

       $data = $result->get();
       $existing_error_rate = $data['error_rate'];
       if ($this->isValidCache($data['ts'], static::TTL)) {
           if ($existing_error_rate < static::FLANNEL_CALLBACK_ERROR_RATE_THRESHOLD) {
               return CircuitBreakerState::CLOSED;
           } else {
               return CircuitBreakerState::OPEN;
           }
       }
       // Lets fetch the current error rate (and compare against the former one)
       $result = $this->getFlannelCallbackErrorRate();
       if ($result->is_error()) {
           return CircuitBreakerState::CLOSED;
       }

       $error_rate = $result->get();
       $cached_value = shape('ts' => time(), 'error_rate' => $error_rate);
       cache_set($cached_key, $cached_value);

       if ($error_rate >= static::FLANNEL_CALLBACK_ERROR_RATE_THRESHOLD) {
           PromClient::cibot_service_dependency_error_rate_above_threshold()->inc(1, darray[
               'breaker_type' => (string)static::class,
           ]);

           if ($existing_error_rate < static::FLANNEL_CALLBACK_ERROR_RATE_THRESHOLD) {
               CIIssuesend(static::ISSUE_MESSAGE_OPEN, DeltaDimensionType::CIRCUIT_BREAKER, DeltaAnomalyType::CIRCUIT_BREAKER_OPEN, static::ISSUE_KEY);
           }

           return CircuitBreakerState::OPEN;
       }

       // If our circuit breaker was previously open (and now closed), track this new state and mark it in our issues dataset
       if ($existing_error_rate >= static::FLANNEL_CALLBACK_ERROR_RATE_THRESHOLD) {
           CIIssueend(static::ISSUE_MESSAGE_CLOSE, DeltaDimensionType::CIRCUIT_BREAKER, DeltaAnomalyType::CIRCUIT_BREAKER_OPEN, static::ISSUE_KEY);
       }
       return CircuitBreakerState::CLOSED;
   }

用戶交互

每一個斷路器中都會獲取數(shù)據(jù)，并在通道檢測到問題時發(fā)出警報。斷路器打開后將從不同的角度呈現(xiàn)故障。一個典型的工作流程是：我們團隊的成員注意到斷路器打開，然后向?qū)?yīng)的團隊通道匯報詳細信息。

圖6. #alerts-ci-issue中的自動斷路器信息的截圖，導(dǎo)致錯誤率激增而將問題報告給搜索團隊

在自動斷路信息中，每個環(huán)節(jié)都會顯示對同一問題的不同看法。類似的遞延信息也會顯示在Checkpoint的客戶端，如圖7所示：

圖7自動斷路器信息截圖：Checkpoint的PR/測試視圖中顯示服務(wù)問題和測試狀態(tài)（"Jenkins隊列目前很高，隊列下降后測試將繼續(xù)"）

我們之前提到，Checkpoint對不同的服務(wù)錯誤率進行查詢，我們創(chuàng)建了一個小型的內(nèi)部問題庫向Slack報告處于打開狀態(tài)的斷路器。評估這些特定的問題（而不是看到無差別的錯誤峰值）逐步提高了我們對斷路器的推斷能力。此外，我們擴展了這個問題庫，以便在測試執(zhí)行器、測試環(huán)境和測試集中進行異常檢測（例如，高于預(yù)期的失敗、錯誤率、持續(xù)時間或失誤率）。這些反過來又為開發(fā)人員提供了更流暢的體驗。

圖8 測試集執(zhí)行異常檢測的屏幕截圖

對開發(fā)者的影響

自從引入兩套基礎(chǔ)設(shè)施和依賴性服務(wù)斷路器以來，我們已經(jīng)通過延遲測試任務(wù)減少了級聯(lián)故障的面積，并通過負載消減讓測試執(zhí)行的吞吐量變得平滑。

帶來的結(jié)果是大大改善了開發(fā)人員的體驗。在過去的兩年里，內(nèi)部工具的級聯(lián)故障事件為零，并且，關(guān)鍵服務(wù)的負載大大降低，這有利于提升CI/CD的用戶體驗。

而這些事故在2020年之前是很常見的。我們定期對CI編排中的依賴服務(wù)負載進行編程式查詢來遇到新的峰值負載。在最近的Git LFS事件中，雖然癥狀與早期的事故相似，但情況會被定位到測試執(zhí)行器，團隊能夠修復(fù)和隔離故障，而不會出現(xiàn)級聯(lián)故障。

現(xiàn)在，當工程師的測試被推遲到系統(tǒng)恢復(fù)時，他們會從Checkpoint的客戶端得到反饋。在使用斷路器之前，這些測試會因為下游系統(tǒng)的過載而出現(xiàn)故障。推遲測試總體上降低了自動化測試的不穩(wěn)定性，同時也降低了多個測試執(zhí)行任務(wù)之間的相關(guān)性。圖9顯示了測試請求的巨大變化，這些測試請求與最初commit測試請求的工程師不再相關(guān)（例如，更新的提交），這些測試請求需要多次重復(fù)測試來解決不穩(wěn)定性。注意每個斷路器實現(xiàn)期（2020年3月和2020年8月）后的兩條曲線變化。

圖9基于10%增長的已執(zhí)行測試集的預(yù)測（紅色），以及消減負載并延遲任務(wù)后的曲線變化（黃色）

最后，為了了解測試的反饋回路，使用CI流水線的團隊已經(jīng)統(tǒng)一了一個業(yè)務(wù)指標 "測試結(jié)果獲取時間"（time to test results）。這個指標考察的是開發(fā)人員從CI中執(zhí)行的構(gòu)建和測試任務(wù)中獲得結(jié)果所需要的實際。團隊成員擔(dān)心的是，添加斷路器以推遲或減輕負載與快速獲得持續(xù)集成結(jié)果是背道而馳的。在過去的幾年里，這個指標并沒有向錯誤的方向發(fā)展（更慢），而是一直很穩(wěn)定，因為許多相同的測試都會失敗，然后向用戶顯示的是測試不穩(wěn)定的結(jié)果。

結(jié)語

本文分享了Slack公司的內(nèi)部CI/CD編排系統(tǒng)Checkpoint的編排級斷路器的決策要點和結(jié)果。

在這個項目之前，Slack的工程師們看到了挑戰(zhàn)，因為內(nèi)部工具的請求達到了新的峰值，當一個系統(tǒng)出現(xiàn)故障，就可能將故障級聯(lián)到其他系統(tǒng)。斷路器位于CI流水線中的各系統(tǒng)之間的接口，可以最大限度地減少級聯(lián)故障。

自從該項目在2020年完成后，工程師們在使用內(nèi)部工具鏈時不再遇到系統(tǒng)間的級聯(lián)故障。工程師們還看到了服務(wù)可用性的提高，Checkpoint的整體吞吐量的提升，以及更少的不良開發(fā)者體驗，如失敗的服務(wù)帶來的測試不穩(wěn)定。斷路器的實現(xiàn)對整個Slack的工程師的生產(chǎn)力產(chǎn)生了實質(zhì)性影響。

現(xiàn)在，多個團隊正在嘗試使用這個程序化指標查詢框架，通過自動構(gòu)建、測試、部署、發(fā)布和回滾，幫助Slack實現(xiàn)持續(xù)部署。

審核編輯：湯梓紅