唐家三少,小说

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案

基于Docker和Kubernetes的優(yōu)秀架構(gòu)實踐

是否有可能基于Docker和Kubernests搭建一個最酷的架構(gòu)？這篇文章將帶您踏上架構(gòu)之旅，并一路為你講解遇到的各種問題，現(xiàn)在，Let’s go！

十年的谷城網(wǎng)站建設(shè)經(jīng)驗，針對設(shè)計、前端、開發(fā)、售后、文案、推廣等六對一服務(wù)，響應(yīng)快，48小時及時工作處理。全網(wǎng)營銷推廣的優(yōu)勢是能夠根據(jù)用戶設(shè)備顯示端的尺寸不同，自動調(diào)整谷城建站的顯示方式，使網(wǎng)站能夠適用不同顯示終端，在瀏覽器中調(diào)整網(wǎng)站的寬度，無論在任何一種瀏覽器上瀏覽網(wǎng)站，都能展現(xiàn)優(yōu)雅布局與設(shè)計，從而大程度地提升瀏覽體驗。創(chuàng)新互聯(lián)建站從事“谷城網(wǎng)站設(shè)計”,“谷城網(wǎng)站推廣”以來，每個客戶項目都認真落實執(zhí)行。

軟件開發(fā)領(lǐng)域在Docker和Kubernetes時代是如何變化的？是否有可能使用這些技術(shù)搭建一勞永逸的架構(gòu)？當所有東西都被“打包”進容器中時，是否有可能統(tǒng)一開發(fā)及集成的流程？這些決策的需求是什么？它們會帶來什么限制？它們會讓開發(fā)人員更輕松，或者相反，反而增加不必要的復(fù)雜性嗎？

現(xiàn)在是時候以文本和原始插圖方式闡明這些以及其他問題了！

這篇文章將帶您踏上從現(xiàn)實生活到開發(fā)流程再到架構(gòu)回到現(xiàn)實生活的旅程，并一路為您解答在這些?？空军c上遇到的最重要問題。我們將試圖確定一些應(yīng)該成為架構(gòu)一部分的組件和原則，并演示一些示例，但不會進入其實現(xiàn)領(lǐng)域。

文章的結(jié)論可能會讓你心煩意亂，或者無比開心，這一切都取決于你的經(jīng)驗、你對這三章故事的看法，甚至在閱讀本文時你的心情。在下面可以發(fā)表評論或提出問題，讓我知道您的想法！

從現(xiàn)實生活到開發(fā)工作流

在大多數(shù)情況下，我所見過的或者很榮幸搭建的所有開發(fā)流程都只是為了一個簡單的目標——縮短從概念產(chǎn)生到交付生產(chǎn)環(huán)境之間的時間間隔，同時保持一定程度的代碼質(zhì)量。

想法的好壞無關(guān)緊要。因為糟糕的想法來也匆匆，去也匆匆——你只要嘗試一下，就可以把它們丟進故紙堆里。這里值得一提的是，從一個糟糕的想法回滾是可以落在自動化設(shè)施的肩膀上的，這可以自動化您的工作流程。

持續(xù)集成和交付看起來像是軟件開發(fā)領(lǐng)域的救命稻草。究竟還有什么比這更簡單呢？如果你有一個想法，你有代碼，那么就去做吧！集成和交付過程相對而言難以獨立于公司特有的技術(shù)和業(yè)務(wù)流程之外。

然而，盡管任務(wù)看起來很復(fù)雜，但在生活中不時會出現(xiàn)一些優(yōu)秀的想法，這些想法可以讓我們（當然，我自己是確定的）更接近構(gòu)建一個無瑕疵的并且?guī)缀蹩梢栽谌魏螆龊鲜褂玫臋C制。對我來說，離這樣的機制最近的步驟是Docker和Kubernetes，他們的抽象層次和思想方法使我認為現(xiàn)在可以用幾乎相同的方法解決80％的問題。

其余的20％的問題顯然還在原地踏步，但正因如此你才可以將你發(fā)自內(nèi)心的創(chuàng)意天賦聚焦在有趣的工作上，而不是處理重復(fù)的例行公事。只要照料一次“架構(gòu)框架”，就可以讓您忘掉已經(jīng)解決的80％問題。

這一切意味著什么？以及Docker是如何解決開發(fā)工作流程的問題的？讓我們看一個簡單的過程，這對于大多數(shù)工作環(huán)境來說也足夠了：

通過適當?shù)姆椒?，您可以自動化并整合上面序列圖中的所有內(nèi)容，并在未來幾個月內(nèi)將其拋之腦后。

設(shè)置開發(fā)環(huán)境

一個項目應(yīng)該包含一個docker-compose.yml文件，這可以讓你省去考慮在本地機器上運行應(yīng)用程序/服務(wù)需要做些什么以及如何操作的問題。一個簡單的命令docker-compose up應(yīng)該啟動您的應(yīng)用程序及其所有依賴項，使用fixtures填充數(shù)據(jù)庫，上傳容器內(nèi)的本地代碼，啟用代碼跟蹤以便即時編譯，并最終在期望的端口開始響應(yīng)請求。即使在設(shè)置新服務(wù)時，您也不必擔心如何啟動、在哪里提交更改或使用哪個框架。所有這些都應(yīng)該提前在標準說明中描述，并由針對不同設(shè)置的服務(wù)模板指定： 前端、后端和worker 。

自動化測試

所有你想知道的關(guān)于“黑匣子”（至于為什么我把容器稱之為如此的更多信息，將在文章中的稍后部分闡明）的情況是，它里面的一切都完好無損，是或否，1或0。您可以在容器內(nèi)部執(zhí)行有限數(shù)量的命令，而 docker-compose.yml 描述了它的所有依賴關(guān)系，您可以輕松自動化和整合這些測試，而不必過分關(guān)注實現(xiàn)細節(jié)。

比如，像這樣！

在這里，測試不僅意味著單元測試，還包括功能測試、集成測試、（ 代碼樣式 ）測試和副本、檢查過時的依賴關(guān)系以及已使用軟件包的許可證正常與否等等。關(guān)鍵是所有這些都應(yīng)該封裝在Docker鏡像中。

系統(tǒng)交付

無論在何時何地想安裝您的項目都無所謂。結(jié)果就像安裝進程一樣，應(yīng)該始終如一。至于您要安裝的是整個生態(tài)系統(tǒng)的哪個部分或者您將從哪個Git倉庫獲得代碼也沒有區(qū)別。這里最重要的組件是冪等性。應(yīng)該指定的是控制安裝過程的變量。

以下是我在解決這個問題時相當有效的算法：

從所有 Dockerfiles 收集鏡像（例如像這樣）
使用元項目，通過 Kube API 將這些鏡像交付給Kubernetes。啟動交付通常需要幾個輸入?yún)?shù)：

Kube API端點
一個“機密”對象，因不同的環(huán)境而異（本地/測試/預(yù)發(fā)布/生產(chǎn)）
要展示的系統(tǒng)名稱以及針對這些系統(tǒng)的Docker鏡像的標簽（在上一步中獲取）

作為一個涵蓋所有系統(tǒng)和服務(wù)的元項目的例子（換句話說，是一個描述生態(tài)系統(tǒng)如何編排以及如何交付更新的項目），我更愿意使用 Ansible playbooks ，通過這個模塊來與Kube API集成。然而，復(fù)雜的自動化可以參考其他選項，我稍后將詳細討論自己的選擇。但是，您必須考慮中心化/統(tǒng)一的管理架構(gòu)的方式。這樣一個方式可以讓您方便、統(tǒng)一地管理所有服務(wù)/系統(tǒng)，并消除即將到來的執(zhí)行類似功能的技術(shù)和系統(tǒng)叢林可能帶來的任何復(fù)雜情況。

通常，需要如下的安裝環(huán)境：

測試環(huán)境

集成和交付的連續(xù)性

如果你有一個統(tǒng)一的方式來測試Docker鏡像——或者“黑盒子”——你可以假設(shè)這些測試結(jié)果可以讓你無縫地（并且問心無愧）將 功能分支 集成到你的Git倉庫的 上游或主分支 中。

也許，這里交易斷路器是集成和交付的順序。如果沒有發(fā)行版，那么如何通過一組并行的功能分支阻止一個系統(tǒng)上的“競爭條件”？

因此，只有在沒有競爭的情況下才能開始這個過程，否則“競爭條件”會縈繞腦海：

嘗試將 功能分支 更新到 上游 （ git rebase/ merge ）
從 Dockerfiles 構(gòu)建鏡像
測試所有構(gòu)建的鏡像
開始并等待，直到系統(tǒng)交付了構(gòu)建自步驟2的鏡像
如果上一步失敗，則將生態(tài)系統(tǒng)回滾到之前的狀態(tài)
在 上游 合并 功能分支 并將其發(fā)送到存儲庫

在任何步驟中的任何失敗都應(yīng)終止交付過程，并將任務(wù)返回給開發(fā)人員以解決錯誤，無論是失敗的測試還是合并沖突。

您可以使用此過程來操作多個存儲庫。只需一次為所有存儲庫執(zhí)行每個步驟（步驟1用于代碼庫A和B，步驟2用于代碼庫A和B等），而不是對每個單獨的存儲庫重復(fù)執(zhí)行整個流程（步驟1-6用于代碼庫A ，步驟1-6用于代碼庫B，等等）。

此外，Kubernetes允許您分批次地推出更新以進行各種AB測試和風險分析。 Kubernetes是通過分離服務(wù)（接入點）和應(yīng)用程序在內(nèi)部實現(xiàn)的。您可以始終以所需的比例平衡組件的新舊版本，以促進問題的分析并為潛在的回滾提供途徑。

系統(tǒng)回滾

架構(gòu)框架的強制性要求之一是能夠回滾任何部署。反過來，這又需要一些顯式和隱式的細微差別。以下是其中最重要的一些事項：

服務(wù)應(yīng)該能夠設(shè)置其環(huán)境以及回滾更改。例如，數(shù)據(jù)庫遷移、RabbitMQ schema等等。
如果無法回滾環(huán)境，則該服務(wù)應(yīng)該是多態(tài)的，并支持舊版本和新版本的代碼。例如：數(shù)據(jù)庫遷移不應(yīng)該中斷舊版本的服務(wù)（通常是2或3個以前的版本）
向后兼容任何服務(wù)更新。通常，這是API兼容性，消息格式等。

在Kubernetes集群中回滾狀態(tài)相當簡單（運行 kubectl rollout undo deployment/some-deployment ，Kubernetes將恢復(fù)先前的“快照”），但是為了讓此功能生效，您的元項目應(yīng)包含有關(guān)此快照的信息。但是更為復(fù)雜的交付回滾算法讓人望而生畏，盡管它們有時是必需的。

以下是可以觸發(fā)回滾機制的內(nèi)容：

發(fā)布后應(yīng)用程序錯誤的高比例
來自關(guān)鍵監(jiān)控點的信號
失敗的冒煙測試
手動模式——人為因素

確保信息安全和審計

沒有一個工作流程可以奇跡般地“搭建”刀槍不入的安全性并保護您的生態(tài)系統(tǒng)免受外部和內(nèi)部威脅，因此您需要確保您的架構(gòu)框架是在每個級別和所有子系統(tǒng)里按照公司的標準和安全策略執(zhí)行的。

我將在后面的關(guān)于監(jiān)控和告警的章節(jié)討論有關(guān)解決方案的所有三個級別，它們本身也是系統(tǒng)完整性的關(guān)鍵。

Kubernetes擁有一套良好的針對訪問控制、網(wǎng)絡(luò)策略、事件審計以及其他與信息安全相關(guān)的強大工具的內(nèi)置機制，可用于構(gòu)建一個良好的防護邊界，以抵御和阻止數(shù)據(jù)泄露。

從開發(fā)流程到架構(gòu)

應(yīng)該認真考慮將開發(fā)流程與生態(tài)系統(tǒng)緊密集成的想法。將這種集成的需求添加到架構(gòu)的傳統(tǒng)需求集（彈性、可伸縮性、可用性、可靠性、抵御威脅等）中，可以大大提高架構(gòu)框架的價值。這是至關(guān)重要的一個方面，由此導(dǎo)致出現(xiàn)了一個名為“DevOps”（開發(fā)運維）的概念，這是實現(xiàn)基礎(chǔ)設(shè)施全面自動化并優(yōu)化的合理步驟。但是，如果有一個設(shè)計良好的架構(gòu)和可靠的子系統(tǒng)，DevOps任務(wù)可以被最小化。

微服務(wù)架構(gòu)

沒有必要詳細討論面向服務(wù)的架構(gòu)——SOA 的好處，包括為什么服務(wù)應(yīng)該是“微”的。我只會說，如果你決定使用Docker和Kubernetes，那么你很可能理解（并接受）單體應(yīng)用架構(gòu)是很困難甚至根子上就是錯誤的。 Docker旨在運行一個進程并持久化，Docker讓我們聚焦于DDD框架（領(lǐng)域驅(qū)動開發(fā)）內(nèi)進行思考。在Docker中，打包后的代碼被視為具有一些公開端口的黑盒子。

生態(tài)系統(tǒng)的關(guān)鍵組件和解決方案

根據(jù)我在設(shè)計具有更高可用性和可靠性的系統(tǒng)方面的經(jīng)驗，有幾個組件對于微服務(wù)的運維是至關(guān)重要的，稍后我會列出并討論這些組件，我將在Kubernetes環(huán)境中引用它們，也可以參考我的清單作為其它任何平臺的檢查單。

如果你（像我一樣）會得出這樣的結(jié)論，即將這些組件作為常規(guī)的Kubernetes服務(wù)來管理，那么我建議你在除“生產(chǎn)環(huán)境”之外的單獨集群中運行它們。比如“預(yù)發(fā)布”集群，因為它可以在生產(chǎn)環(huán)境不穩(wěn)定并且你迫切需要其鏡像、代碼或監(jiān)控工具的來源時節(jié)省你的時間。可以說，這解決了雞和雞蛋的問題。

身份認證

像往常一樣，它始于訪問——服務(wù)器、虛擬機、應(yīng)用程序、辦公室郵件等。如果您是或想成為主要的企業(yè)平臺（IBM、Google、Microsoft）之一的客戶，則訪問問題將由供應(yīng)商的某個服務(wù)處理。但是，如果您想擁有自己的解決方案，難道只能由您并在您的預(yù)算之內(nèi)進行管理？

此列表可幫助您確定適當?shù)慕鉀Q方案并估算設(shè)置和維護所需的工作量。當然，您的選擇必須符合公司的安全政策并經(jīng)信息安全部門批準。

自動化服務(wù)配置

盡管Kubernetes在物理機器/云虛擬機（Docker、kubelet、kube proxy、etcd集群）上只需要少量組件，但對于新機器的添加和集群管理仍然需要自動化。以下是一些簡單的方法：

KOPS ——此工具允許您在兩個云供應(yīng)商（AWS或GCE）之一上安裝集群
Teraform ——這可以讓您管理任何環(huán)境的基礎(chǔ)設(shè)施，并遵循IAC（基礎(chǔ)架設(shè)施即代碼）的思想
Ansible ——用于任何類型的通用自動化工具

就個人而言，我更喜歡第三個選項（帶有一個 Kubernetes的集成模塊），因為它允許我使用服務(wù)器和Kubernetes對象并執(zhí)行任何類型的自動化。但是，沒有什么能阻止您使用Teraform及其 Kubernetes模塊。 KOPS在“裸機”方面效果不佳，但它仍然是與AWS/GCE一起使用的工具！

Git代碼庫和任務(wù)跟蹤器

對于任何Docker容器，使其日志可訪問的方法是將它們寫入正在容器中運行的根進程的STDOUT或STDERR，服務(wù)開發(fā)人員并不關(guān)心日志數(shù)據(jù)接下來的變化，而主要是它們應(yīng)該在必要時可用，并且包含過去某個點的記錄。滿足這些期許的所有責任在于Kubernetes以及支持生態(tài)系統(tǒng)的工程師。

在官方文檔中，您可以找到關(guān)于處理日志的基本（和好的）策略的說明，這將有助于您選擇用于聚合和存儲大量文本數(shù)據(jù)的服務(wù)。

在針對日志系統(tǒng)的推薦服務(wù)中，同一文檔提到 fluentd 用于收集數(shù)據(jù)（在集群的每個節(jié)點上作為代理啟動時）以及用于存儲和索引數(shù)據(jù)的 Elasticsearch 。即使你可能不贊同這個解決方案的效率，但鑒于它的可靠性和易用性，我認為這至少是一個好的開始。

Elasticsearch是一個資源密集型的解決方案，但它可以很好地擴展并有現(xiàn)成的Docker鏡像，可以運行在單個節(jié)點以及所需大小的集群上。

跟蹤系統(tǒng)

即使代碼很好，然而還是會確實發(fā)生故障，接著你想在生產(chǎn)環(huán)境中非常仔細地研究它們，并試圖了解“如果在我的本地機器上一切工作正常，那么在生產(chǎn)環(huán)境上究竟發(fā)生了什么錯誤？”。比如緩慢的數(shù)據(jù)庫查詢、不正確的緩存、較慢的磁盤或與外部資源的連接、生態(tài)系統(tǒng)中的交易，瓶頸以及規(guī)模不足的計算服務(wù)都是您不得不跟蹤和估算在實際負載下代碼執(zhí)行時間的一些原因。

Opentracing 和 Zipkin 足以應(yīng)付大多數(shù)現(xiàn)代編程語言的這一任務(wù)，并且在封裝代碼之后不會增加額外的負擔。當然，收集到的所有數(shù)據(jù)應(yīng)該存儲在適當?shù)牡胤?，并作為一個組件使用。

通過上述的開發(fā)標準和服務(wù)模板可以解決在封裝代碼以及通過服務(wù)、消息隊列、數(shù)據(jù)庫等轉(zhuǎn)發(fā)“Trace ID”時出現(xiàn)的復(fù)雜情況。后者也考慮到了方法的一致性。

監(jiān)控和告警

Prometheus 已經(jīng)成為現(xiàn)代監(jiān)控系統(tǒng)中事實上的標準，更重要的是，它在Kubernetes上獲得了開箱即用的支持。您可以參考官方Kubernetes文檔來了解更多關(guān)于監(jiān)控和警報的信息。

監(jiān)控是必須安裝在集群內(nèi)的少數(shù)幾個輔助系統(tǒng)之一，集群是一個受監(jiān)控的實體。但是對于監(jiān)控系統(tǒng)的監(jiān)控（抱歉有些啰嗦）只能從外部進行（例如，從相同的“預(yù)發(fā)布”環(huán)境）。在這種情況下，交叉檢查可作為一個針對任何分布式環(huán)境的便捷解決方案，這不會使高度統(tǒng)一的生態(tài)系統(tǒng)架構(gòu)復(fù)雜化。

整個監(jiān)控范圍可以分為三個完全邏輯隔離的層級。以下是我認為的在每個層級最重要的跟蹤點例子：

物理層：網(wǎng)絡(luò)資源及其可用性——磁盤（I/O，可用空間）——單個節(jié)點（CPU、RAM、LA）的基本資源
集群層：——每個節(jié)點上主集群系統(tǒng)的可用性（kubelet、kubeAPI、DNS、etcd等）——可用資源數(shù)量及其均勻分布——允許的可用資源相對于服務(wù)消耗的實際資源的監(jiān)控——pod的重新加載
服務(wù)層：——任何類型的應(yīng)用程序監(jiān)控——從數(shù)據(jù)庫內(nèi)容到API調(diào)用頻率——API網(wǎng)關(guān)上的HTTP錯誤數(shù)量——隊列大小和worker的利用率——數(shù)據(jù)庫的多個度量標準（復(fù)制延遲、事務(wù)的時間和數(shù)量、緩慢的請求等）——對非HTTP進程的錯誤分析——發(fā)送到日志系統(tǒng)請求的監(jiān)控（可以將任何請求轉(zhuǎn)換為度量標準）

至于在每個層級的告警通知，我想推薦使用了無數(shù)次的其中一個外部服務(wù)，可以發(fā)送通知電子郵件，短信或打電話給手機號碼。我還會提到另一個系統(tǒng)—— OpsGenie ——它與 Prometheus的alertmanaer 是緊密集成的。

OpsGenie是一種彈性的告警工具，可幫助處理升級、全天候工作、通知渠道選擇等等。在團隊之間分發(fā)告警也很容易。例如，不同級別的監(jiān)控應(yīng)向不同的團隊/部門發(fā)送通知：物理——Infra + Devops，集群——Devops，應(yīng)用程序——每一個相關(guān)的團隊。

API Gateway和單點登錄

要處理諸如授權(quán)、認證、用戶注冊（外部用戶——公司客戶）和其他類型的訪問控制等任務(wù)，您需要高度可靠的服務(wù)，以保持與API Gateway的彈性集成。使用與“身份服務(wù)”相同的解決方案沒有什么壞處，但是您可能需要分離這兩種資源以實現(xiàn)不同級別的可用性和可靠性。

內(nèi)部服務(wù)的集成不應(yīng)該很復(fù)雜，您的服務(wù)不應(yīng)該擔心用戶和對方的授權(quán)和身份驗證。相反，架構(gòu)和生態(tài)系統(tǒng)應(yīng)該有一個處理所有通信和HTTP流量的代理服務(wù)。

讓我們考慮一下最適合與API Gateway集成的方式，即整個生態(tài)系統(tǒng)——令牌。此方法適用于所有三種訪問方案：從UI、從服務(wù)到服務(wù)以及從外部系統(tǒng)。接著，接收令牌（基于登錄名和密碼）的任務(wù)由用戶界面本身或服務(wù)開發(fā)人員完成。區(qū)分UI中使用的令牌的生命周期（較短的TTL）和其他情況（較長的和自定義的TTL）也是有意義的。

以下是API Gateway解決的一些問題：

從外部和內(nèi)部訪問生態(tài)系統(tǒng)服務(wù)（服務(wù)不直接相互通信）
與單點登錄服務(wù)集成：令牌轉(zhuǎn)換和附加HTTPS請求，頭部包含所請求服務(wù)的用戶標識數(shù)據(jù)（ID、角色和其他詳細信息）——根據(jù)從單點登錄服務(wù)接收到的角色啟用/禁用對所請求服務(wù)的訪問控制
針對HTTP流量的單點監(jiān)控
復(fù)合不同服務(wù)的API文檔（例如，復(fù)合 Swagger的json/yml文件）
能夠根據(jù)域和請求的URI管理整個生態(tài)系統(tǒng)的路由
用于外部流量的單一接入點，以及與接入供應(yīng)商的集成

事件總線和企業(yè)集成/服務(wù)總線

如果您的生態(tài)系統(tǒng)包含數(shù)百個可在一個宏域中工作的服務(wù)，則您將不得不處理服務(wù)通信的數(shù)千種可能方式。為了簡化數(shù)據(jù)流，您應(yīng)該具備在發(fā)生特定事件時將信息分發(fā)到大量收件人的能力，而不管事件的上下文如何。換句話說，您需要一個事件總線來發(fā)布基于標準協(xié)議的事件并訂閱它們。

作為事件總線，您可以使用任何可以操作所謂Broker的系統(tǒng)： RabbitMQ 、 Kafka 、 ActiveMQ 等。一般來說，數(shù)據(jù)的高可用性和一致性對于微服務(wù)是至關(guān)重要的，但是由于 CAP定理，您仍然不得不犧牲某些東西來實現(xiàn)總線的正確分布和集群化。

自然，事件總線應(yīng)該能夠解決各種服務(wù)間通信問題，但隨著服務(wù)數(shù)量從幾百個增加到幾千個甚至幾萬個，即使是基于事件總線的架構(gòu)也會望而卻步，您將需要尋找另一種解決方案。一個很好的例子就是集成總線方法，它可以擴展上述“Dumb管——智能消費”策略的功能。

有幾十個使用“ 企業(yè)集成/服務(wù)總線 ”方法的理由，其目的是減少面向服務(wù)架構(gòu)的復(fù)雜性。以下是其中幾個理由：

聚合多個消息
將一個事件拆分為幾個事件
對于事件的系統(tǒng)響應(yīng)的同步/事務(wù)分析
接口的協(xié)調(diào)，這對于與外部系統(tǒng)的集成特別重要
事件路由的高級邏輯
與相同服務(wù)的多重集成（從外部和內(nèi)部）
數(shù)據(jù)總線的不可擴展中心化

作為企業(yè)集成總線的一款開源軟件，您可能需要考慮 Apache ServiceMix ，其中包含幾個對于此類SOA的設(shè)計和開發(fā)至關(guān)重要的組件。

數(shù)據(jù)庫和其他有狀態(tài)的服務(wù)

和Kubernetes一樣，Docker一次又一次地改變了所有用于需要數(shù)據(jù)持久化以及與磁盤緊密相關(guān)的服務(wù)的游戲規(guī)則。有人說服務(wù)應(yīng)該在物理服務(wù)器或虛擬機上以舊的方式“生存”。我尊重這一觀點，并且不會談?wù)撍膬?yōu)點和缺點，但我相當肯定這種說法的存在僅僅是因為在Docker環(huán)境中暫時缺乏管理有狀態(tài)服務(wù)的知識、解決方案和經(jīng)驗。

我還應(yīng)該提到數(shù)據(jù)庫經(jīng)常占據(jù)存儲世界的中心位置，因此您選擇的解決方案應(yīng)該完全準備好在Kubernetes環(huán)境中工作。

根據(jù)我的經(jīng)驗以及市場情況，我可以區(qū)分以下幾組有狀態(tài)的服務(wù)以及每個服務(wù)最適合的Docker解決方案的示例：

數(shù)據(jù)庫管理系統(tǒng)—— PostDock 是在任何Docker環(huán)境中PostgreSQL簡單可靠的解決方案
隊列/消息代理—— RabbitMQ 是構(gòu)建消息隊列系統(tǒng)和路由消息的經(jīng)典軟件。 RabbitMQ配置中的 cluster_formation 參數(shù)對于集群設(shè)置是必不可少的
高速緩存服務(wù)—— Redis 被認為是最可靠和彈性的數(shù)據(jù)高速緩存解決方案之一
全文搜索——我上面已經(jīng)提到過的 Elasticsearch 技術(shù)棧，最初用于全文搜索，但同樣擅長存儲日志和任何具有大量文本數(shù)據(jù)的工作
文件存儲服務(wù)——用于任何類型的文件存儲和交付（ftp，sftp等）的一般化服務(wù)組

依賴鏡像

如果您尚未遇到您需要的軟件包或依賴項已被刪除或暫時不可用的情況，請不要認為這種情況永遠不會發(fā)生。為避免不必要的不可用性并為內(nèi)部系統(tǒng)提供安全保護，請確保構(gòu)建和交付服務(wù)都不需要Internet連接。配置鏡像和復(fù)制所有的依賴項到內(nèi)部網(wǎng)絡(luò)：Docker鏡像、rpm包、源代碼庫、python/go/js/php模塊。

這些以及其他任何類型的依賴關(guān)系都有自己的解決方案。最常見的可以通過查詢“ private dependency mirror for ... ”來Google搜索。

從架構(gòu)到真實生活

不管你喜不喜歡，你的整個架構(gòu)遲早會難以為繼。它總是會發(fā)生：技術(shù)過時很快（1 - 5年），方法和方法論——有點慢（5 - 10年），設(shè)計原則和基礎(chǔ)——偶爾（10 - 20年），但終歸是不可避免的。

考慮到技術(shù)的過時，需要總是試圖讓自己的生態(tài)系統(tǒng)處于技術(shù)創(chuàng)新的高峰期，計劃并推出新的服務(wù)以滿足開發(fā)人員、業(yè)務(wù)和最終用戶的需求，向您的利益相關(guān)者推廣新的實用程序，交付知識來推動您的團隊和公司前進。

通過融入專業(yè)社區(qū)、閱讀相關(guān)文獻并與同事交流，保持自己處于生態(tài)鏈的頂端。注意項目中的新機會以及正確使用新趨勢。試驗并應(yīng)用科學(xué)方法來分析研究結(jié)果，或依靠您信任和尊重的其他人的結(jié)論。

除非你是本領(lǐng)域的專家，否則很難為根本性的變化做好準備。我們所有人只會在我們的整個職業(yè)生涯中見證一些重大的技術(shù)變化，但并不是我們頭腦中的知識數(shù)量使得我們攀登到頂峰的，而是我們思維的開放性以及接受蛻變的能力。

回到標題中的問題：“是否有可能搭建一個更好的架構(gòu)？”。答案顯而易見：不，不是“一勞永逸”，但一定要在某種程度上積極爭取，在未來某個“很短的時間”，你一定會成功的！

本文標題：基于Docker和Kubernetes的優(yōu)秀架構(gòu)實踐
本文來源：http://m.fisionsoft.com.cn/article/dhhedss.html