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

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

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

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

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

二十個微服務(wù)的困境

關(guān)于最佳開發(fā)平臺的所有問題都始于規(guī)模。對于我們的案例，想象一個擁有 50 多名工程師和 25 多種微服務(wù)的團隊。關(guān)于這個規(guī)模的團隊，有一些事情使其成為一個拐點，從熟悉單體應(yīng)用的流程轉(zhuǎn)變?yōu)楦植际健⒐蚕?、高速發(fā)展的團隊。

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

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

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

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

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

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

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

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

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

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

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

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

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

對我們的產(chǎn)品進行重新架構(gòu)以更清晰地分離微服務(wù)和實現(xiàn)這些服務(wù)之間的廣泛合同測試的總體投資回報率可能不是我們希望的大規(guī)模技術(shù)跨度。

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

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

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

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

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

命名空間復(fù)制的問題

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

如果沒有維護這種緊密的集成和同步，那么結(jié)果將是已經(jīng)過時并且開發(fā)人員不再信任的命名空間環(huán)境。

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

最后一個考慮因素是運行所有這些復(fù)制命名空間的成本，無論是基礎(chǔ)設(shè)施成本還是時間成本?；蛘吣恢痹谶\行許多命名空間，這是昂貴的，或者每次團隊想運行集成測試時都會啟動命名空間服務(wù)，從而增加測試和實驗的阻力。平臺工程團隊的開銷使我們回到了這樣一個普遍觀點，即環(huán)境復(fù)制在大規(guī)模的微服務(wù)團隊中不可擴展。

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

為什么環(huán)境復(fù)制不可擴展

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

在考慮這些微服務(wù)規(guī)?；蓽y試和開發(fā)環(huán)境的障礙時，我建議您重新考慮我們對“微服務(wù)”的理解。如果服務(wù)之間相互依賴，以致無法隔離測試，那么這個術(shù)語就更像是一個標簽，而不是對體系結(jié)構(gòu)的描述。

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

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

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

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

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

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