借助請(qǐng)求級(jí)別的隔離，不同團(tuán)隊(duì)可在共享集群上開展實(shí)驗(yàn)。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

最后一個(gè)考慮因素是運(yùn)行所有這些復(fù)制命名空間的成本，無論是基礎(chǔ)設(shè)施成本還是時(shí)間成本。或者您一直在運(yùn)行許多命名空間，這是昂貴的，或者每次團(tuán)隊(duì)想運(yùn)行集成測(cè)試時(shí)都會(huì)啟動(dòng)命名空間服務(wù)，從而增加測(cè)試和實(shí)驗(yàn)的阻力。平臺(tái)工程團(tuán)隊(duì)的開銷使我們回到了這樣一個(gè)普遍觀點(diǎn)，即環(huán)境復(fù)制在大規(guī)模的微服務(wù)團(tuán)隊(duì)中不可擴(kuò)展。

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

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

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

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

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

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

請(qǐng)求隔離：開發(fā)人員實(shí)驗(yàn)和測(cè)試的新模型

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

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

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