借助請求級別的隔離，不同團隊可在共享集群上開展實驗。

譯自Environment Replication Doesn’t Work for Microservices，作者 No?nica Mellifera(她/她的)在轉向開發人員關系之前是一個開發人員 7 年。她專門從事容器化工作負載、無服務器和公共云工程。No?nica 一直倡導開放標準，并就此進行了演講和研討會......

什么是驗證代碼是否能夠工作的最佳方式？當我與能力強大的平臺工程師和運維架構師交談時，有一個迷人的趨勢是，沒有人似乎能就測試應該在哪里或如何進行達成一致。

您是在什么時候第一次意識到您的代碼與其他服務不正確地協作的？分階段失敗應該經常發生，因為開發人員在測試重大更改，還是分階段應該總是獲得工作代碼提交？應該在合同測試上花巨大努力，使用復雜的模擬來模擬延遲峰值等情況，還是應該在生產環境上設置金絲雀測試并觀察會發生什么？這些都是在企業平臺工程團隊上沒有一致答案的問題。

讓我們來看看試圖在本地復制復雜的微服務環境的問題。雖然更小的團隊絕對可以為每位工程師提供一個運行在他們的筆記本電腦上的生產集群的副本，但這種方法的可擴展性非常糟糕，并且在本地復制上花費的時間更好地用于創建可以由整個團隊共享并從開發的第一天開始安全用于測試的預發布環境。

二十個微服務的困境

關于最佳開發平臺的所有問題都始于規模。對于我們的案例，想象一個擁有 50 多名工程師和 25 多種微服務的團隊。關于這個規模的團隊，有一些事情使其成為一個拐點，從熟悉單體應用的流程轉變為更分布式、共享、高速發展的團隊。

關于50名工程師和25個微服務的團隊，有什么是真實的？讓我們列出一些觀察結果：

• 團隊太大而無法保持同步和共享知識：C團隊可能在沒有任何A團隊知情的情況下更新數據庫接口。
• 所有微服務所做的計算工作足以考驗一臺普通筆記本電腦。
• 使用了不止一個數據庫。
• 代碼分布在多個倉庫中。

當團隊和產品規模減半時，開發人員可以獲取必要的倉庫，從其他團隊獲得幫助以使事情正常工作，并在其副本過時時，他們可能已經從其他團隊的更新中得知。然而，在這個規模下，這些業務之間的人為交流不再擴展，A團隊中的某人會發現他們的本地復制環境在他們沒有意識到的情況下不同步。

沉沒成本：過度承諾本地副本

在這種情況下，許多團隊實際上會做出決定來購買本地復制，也就是說，他們會開始向該項目投入真正的DevOps資源。突然，我們有責任維護用于本地復制的Dockerfile，開發人員必須更新它以了解其更改是否與其他服務一起使用。

堅持這項工作的原因似乎令人信服：通過一致的本地副本，開發人員可以在更新進入預發布環境之前發現錯誤，并且不會阻塞其他團隊的工作，這些團隊需要預發布環境大部分時間可用。(我在這里使用了“預發布”，但只需將其視為正式上線之前的部署，無論其稱為預發布、QA、測試還是其他名稱。)但是，在這個階段對本地復制投入大量時間有三個主要問題:

• 如果您目前沒有運行整個集群的本地副本，那么架構本身可能需要重新設計，增加標準的服務啟動和運行方式、單一倉庫架構以及明確的服務所有權。
• 許多組件無法在本地很好地復制，包括第三方服務和包含復雜數據結構的數據存儲。結果將是這些組件的模擬或其他高度簡化的副本，這引發了對測試準確性和持續維護成本的擔憂。
• 這種方法長期不可擴展。一旦團隊規模和架構大小都加倍，開發人員的筆記本電腦就無法運行整個系統。一旦筆記本電腦無法運行集群，那么為每個開發者運行相同集群的副本的云基礎設施成本將無法承受。

這并不意味著本地復制對所有團隊都有效，這意味著一旦您意識到您的規模需要全職維護本地副本鏡像，您應該把那個時間花在別的東西上。

為什么您的所有微服務都捆綁在一起？

整個討論又提出了另一個問題：如果您需要測試每次代碼更改，那么您真的擁有微服務嗎？即使您的產品的25個組件作為獨立服務運行，但如果它們耦合得那么緊，以至于無法隔離測試，那么您就只有微服務的名稱嗎？(順便說一句，我真切地希望緊耦合的微服務體系結構的首字母縮寫 MINO 能流行起來。)

關于測試微服務之間集成的每一次討論都會回到這樣一個問題：微服務應該被很好地隔離，這樣您就可以進行合同測試。問題再次歸結為規模。

在小規模下，每個服務都應該可靠地完全滿足與其他服務的合同。即使在大規模下，您集群內的事務也不應產生意外的副作用。然而，在更大的規模下，合同測試的要求會變得越來越復雜。合同測試不測試延遲、多變量請求和數據存儲中的意外數據，這些都是我們希望通過測試覆蓋的情況，然后才準備進入生產環境。

是否有可能覆蓋這些情況？當然可以，但問題是我們是否應該花大量時間來模擬集群中的所有其他服務，或者那時間是否最好花在為預發布服務器建立單一的、高精度的生產環境克隆上。

對我們的產品進行重新架構以更清晰地分離微服務和實現這些服務之間的廣泛合同測試的總體投資回報率可能不是我們希望的大規模技術跨度。

更好的解決方案：作為事實來源的共享集群

如果我們不想投入時間將我們的集群適應工作站或一套深入的合同測試，那么解決方案是一個非常接近生產環境的共享集群。這個預發布環境可以提供關于更改是否能夠與其他服務很好地協作的真實答案，并且當其他服務發生變化時，它是一個需要更新的單一集群。最后，與本地環境不同，它應該 24/7 可用，開發人員不需要更新他們的復制環境。

同樣，我們必須討論規模問題。在 50 名開發人員和 25 個微服務的情況下，多個團隊可能會同時想要在預發布環境上進行測試。這里的規模再次成為拐點:稍小一些，團隊可以在 Slack 上發布他們將在接下來的幾個小時內使用預發布環境。但是隨著我們的發展，保持同步變得更加困難，我們最終會有開發人員等待數小時或數天的預發布環境可用。

使用 Kubernetes namespace 作為團隊的開發環境為復制預發布或生產環境的條件提供了一個強大的解決方案。通過創建一個預發布設置的克隆命名空間，開發人員可以在一個高度模擬生產環境的環境中工作。這種方法可以確保所有服務、配置和依賴項都是對齊的，從而更容易在開發周期的早期捕獲問題。

克隆的命名空間還有助于團隊成員之間的更好協作。由于命名空間是隔離的，多個開發人員可以在不同的功能或錯誤修復上工作，而不會相互干擾。這種隔離對于需要管理復雜 CI/CD 管道的 DevOps 工程師特別有益，因為它允許他們在與生產環境幾乎相同的環境中測試部署腳本和編排過程。該命名空間可以充當最后一個檢查點，在該檢查點上，所有代碼和功能都進行了集成和測試，然后再移至預發布或生產環境。Prezi 等團隊正在使用這種方法，每個開發團隊都有一個命名空間來部署和測試更改。

命名空間復制的問題

謹慎管理這些克隆的命名空間以避免配置漂移至關重要。需要自動化工具和腳本來確保命名空間保持對預發布或生產環境的真實復制。任何對預發布或生產設置的更改都需要盡快在開發命名空間中鏡像。

如果沒有維護這種緊密的集成和同步，那么結果將是已經過時并且開發人員不再信任的命名空間環境。

隨著您的團隊規模的擴大，您將需要更多包含生產環境相關部分副本的命名空間。隨著您需要為每個命名空間復制數據庫、云資源和第三方集成，這可能開始覺得令人生畏。

最后一個考慮因素是運行所有這些復制命名空間的成本，無論是基礎設施成本還是時間成本。或者您一直在運行許多命名空間，這是昂貴的，或者每次團隊想運行集成測試時都會啟動命名空間服務，從而增加測試和實驗的阻力。平臺工程團隊的開銷使我們回到了這樣一個普遍觀點，即環境復制在大規模的微服務團隊中不可擴展。

Uber 和 Lyft 的工程團隊由于同步和測試保真度問題，發現命名空間方法不足，并轉向請求隔離模型，在該模型中，多個團隊可以在單個共享集群上安全實驗。

為什么環境復制不可擴展

本地復制的誘人之處，盡管最初很有前途，但隨著團隊和體系結構的擴展，其局限性就顯露出來了。這不僅僅是關于盡早發現錯誤的問題;而是關于這些測試的準確性和測試環境的可持續性。合同測試雖然有價值，但隨著服務之間交互的復雜性增加，它也顯示出局限性。

在考慮這些微服務規模化集成測試和開發環境的障礙時，我建議您重新考慮我們對“微服務”的理解。如果服務之間相互依賴，以致無法隔離測試，那么這個術語就更像是一個標簽，而不是對體系結構的描述。

共享的預發布環境成為一個務實的中間立場。使用 Kubernetes 命名空間針對特定團隊的環境可以在隔離性和準確性之間實現平衡。然而，即使這種方法也不是沒有其缺點，例如配置漂移的風險和所涉及的運營開銷。

隨著我們的擴展，我們的測試方法也必須與我們一起擴展，始終以那種難以捉摸的準確性、效率和可維護性的組合為目標。近年來，一種新的方法已經突顯出來，它使用共享環境而不需要多個副本，并通過請求隔解來隔離實驗。

請求隔離：開發人員實驗和測試的新模型

在大型企業團隊中，并且在中型開發團隊中也越來越多地使用一種新的模型，它承諾在開發周期的早期進行更快、更好的測試。

請求級別隔離是一種利用上下文傳播和請求路由的微服務環境測試方法。當開發人員想要測試微服務的新版本時，依賴項由運行最新穩定版本(稱為基線)的共享服務池滿足。這種方法可以確保一個開發人員做出的更改與其他開發人員隔離，減輕了跨依賴性和不可預測的預發布環境的問題。

使用共享的預發布環境，我們可以像上述命名空間策略中提到的那樣產生一個高精度的復制空間。但是，與其將組件復制到命名空間中，我們可以使用請求隔離同時部署多個開發人員版本的服務。