這篇文章主要講解了“微服務(wù)CD怎么實現(xiàn)”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“微服務(wù)CD怎么實現(xiàn)”吧！

創(chuàng)新互聯(lián)公司主要從事成都做網(wǎng)站、成都網(wǎng)站制作、成都外貿(mào)網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務(wù)。立足成都服務(wù)新絳,十多年網(wǎng)站建設(shè)經(jīng)驗,價格優(yōu)惠、服務(wù)專業(yè),歡迎來電咨詢建站服務(wù):18980820575

微服務(wù)和CD

按照Martin Fowler的說法，微服務(wù)架構(gòu)是“將軟件設(shè)計一組為可獨立部署的服務(wù)的方式“。這種方式目前已經(jīng)成為構(gòu)建分布式系統(tǒng)/應(yīng)用的主流；按照J(rèn)ez Humble的說法，CD（持續(xù)交付）是“能夠以可持續(xù)的方式安全快速地將所有類型的變更 - 包括新功能、配置、錯誤修復(fù)和實驗 - 投入生產(chǎn)”。

無論是一體化架構(gòu)還是微服務(wù)架構(gòu)，無論目標(biāo)部署環(huán)境或我們的架構(gòu)選擇如何，設(shè)計好CD工作流程以使我們對應(yīng)用的任何更改投入生產(chǎn)都很重要。CD工作流程是DevOps流程的核心，能夠很好的串聯(lián)組織中的各種功能，包括開發(fā)、QA以及IT運維等等。

微服務(wù)架構(gòu)CD的4項挑戰(zhàn)

1. 維護(hù)復(fù)雜分布式系統(tǒng)的完整性：由于我們將大型一體化系統(tǒng)分解成為了更小、更易于管理的微服務(wù)，因此系統(tǒng)本身的整體復(fù)雜性會增加，我們開始需要處理分布式系統(tǒng)相關(guān)的問題；

2. 安全快速地發(fā)布功能：當(dāng)我們的功能可能涉及一個或多個微服務(wù)的更改時，需要特別考慮一下如何管理頻繁的功能發(fā)布；

3. 管理不同技術(shù)堆棧的部署：微服務(wù)環(huán)境通常包括用于服務(wù)的不同技術(shù)堆棧，跨技術(shù)對戰(zhàn)的管理和部署過程很有挑戰(zhàn)性；

4. 獨立部署服務(wù)的過程和工具：有許多工具可用于構(gòu)建CD工作流程，但選擇工具、制定CD工作流并不是一件容易的事。

微服務(wù)架構(gòu)CD的5點思考

1. 準(zhǔn)備好測試策略

跟傳統(tǒng)一體化架構(gòu)應(yīng)用相比，微服務(wù)架構(gòu)的測試和驗證更加細(xì)致，也更加復(fù)雜。一個有效的測試策略必須同時考慮到測試單個服務(wù)和驗證整個系統(tǒng)行為的需要。

對于服務(wù)的pre-production測試，特別是以隔離的方式測試，傳統(tǒng)方法仍然適用。測試金字塔仍然可以幫助我們在不同類型的測試之間保持平衡。但是，在測試服務(wù)聚合時，這種測試方式的效果有限。我們會遇到一些在測試環(huán)境中無法模擬的錯誤類別，例如由分布式系統(tǒng)中的最終一致性引起的問題，導(dǎo)致系統(tǒng)部分失敗的硬件和網(wǎng)絡(luò)故障等。

我們最好利用一些技術(shù)來作為傳統(tǒng)測試的補充，例如synthetic user testing、lightweight user acceptance testing以及fault injection testing等等。

2. 檢查好CI實踐

CI是CD的關(guān)鍵實踐。除了構(gòu)建服務(wù)器、構(gòu)建定義相關(guān)的考慮，基于主干的開發(fā)和功能切換是實現(xiàn)簡單而強大的CI過程的兩個關(guān)鍵實踐。

在基于主干的開發(fā)中，開發(fā)人員在一個名為“trunk”的分支中協(xié)作。這樣做的好處是，避免開發(fā)分支的drift和由此產(chǎn)生的merge hell。這與維護(hù)長期特征和釋放分支的做法相反。在分支模型中，雖然我們可能會在各個分支上運行構(gòu)建，但事實上，我們沒有進(jìn)行持續(xù)集成。

要進(jìn)行基于主干的開發(fā)，需要有稱為feature toggles的控件。功能切換支持WIP和已完成功能的組合的多次提交。通過這些切換，我們可以在生產(chǎn)環(huán)境中關(guān)閉不完整特性的顯示，直到這些特性在生產(chǎn)環(huán)境中得到充分的開發(fā)和測試。特性切換通常存儲在靠近代碼基的規(guī)范或配置文件中，并由CD管道中的自動化程序在特定環(huán)境中打開切換。

一旦我們有了維護(hù)feature toggles的機制，我們可以使用相同的機制來引入其他類別的toggles，如release toggles（控制對未完成的代碼的訪問）、Ops toggles（控制生產(chǎn)代碼的行為）、permissions toggles（到打開特權(quán)用戶的特定行為）和experimental toggles（對于多變量測試 - 在使其成為永久性之前接收到的功能的程度）。

3. 計劃好環(huán)境

環(huán)境計劃包括我們的環(huán)境集、它們的預(yù)期用途、通過這些環(huán)境促進(jìn)工件的策略以及在這些環(huán)境中的toggle狀態(tài)。

首先，考慮需要什么環(huán)境以及它們的預(yù)期用例。組織中不同的部門有不同的競爭需求。在創(chuàng)建環(huán)境時，我們應(yīng)該滿足所有這些相互競爭的需求。

其次，如果可能的話，考慮使用云基礎(chǔ)設(shè)施動態(tài)創(chuàng)建環(huán)境。例如使用Kubernetes的標(biāo)簽功能，可以在飛行測試環(huán)境中創(chuàng)建自動化測試，而不是在長期存在的環(huán)境。

第三，CD管道會生成許多artifacts，我們應(yīng)該考慮要存儲多少artifacts？我們需要多少repositories等等。

4. 管理好配置

應(yīng)用的配置包括那些每次部署時不盡相同的東西，應(yīng)該與代碼分開存儲。那么當(dāng)我們擁有一組微服務(wù)時，應(yīng)該如何處理配置呢？

一種辦法是在Consul或Vault等存儲庫中集中管理部署配置，在Chef和CD管道中擴(kuò)展部署配置只會徒增理解難度。

另一種技術(shù)是采用標(biāo)準(zhǔn)化分發(fā)配置的流程，不管服務(wù)的技術(shù)對戰(zhàn)如何，讓服務(wù)根據(jù)堆棧處理配置。例如，我們通常參考12-factors，避免分發(fā)配置文件。

最后，像證書這樣的關(guān)鍵部分需要一個治理過程來確保它們得到適當(dāng)?shù)墓芾?。通常會是手動的過程，但我們需要早點考慮并安排妥當(dāng)。

5. 準(zhǔn)備好應(yīng)對可能的錯誤

在微服務(wù)系統(tǒng)中，多個服務(wù)頻繁更新，當(dāng)服務(wù)的部署引入不穩(wěn)定性或bug時，我們怎么辦？

回滾，找到故障的根源并盡快修復(fù)，在大多數(shù)情況下是最好的反應(yīng)。能夠?qū)崿F(xiàn)回滾的一個先決條件是確保我們能夠從熱修復(fù)分支直接發(fā)布到生產(chǎn)。

回滾操作在生產(chǎn)環(huán)境中往往非常棘手。在大多數(shù)情況下，如果更改不大，并且明白問題其中的緣由，回滾會相對容易些。但如果部署包含了一些不容易理解的更改，例如DB更改，特別是那些涉及到模式的更改，則需要在連續(xù)部署中將DB更改與代碼更改分開部署，以確保DB更改與早期版本的代碼向后兼容。

感謝各位的閱讀，以上就是“微服務(wù)CD怎么實現(xiàn)”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對微服務(wù)CD怎么實現(xiàn)這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是創(chuàng)新互聯(lián)，小編將為大家推送更多相關(guān)知識點的文章，歡迎關(guān)注！