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

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

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

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

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

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

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

想法的好壞無關(guān)緊要。 因?yàn)樵愀獾南敕▉硪泊掖?，去也匆?mdash;—你只要嘗試一下，就可以把它們丟進(jìn)故紙堆里。 這里值得一提的是，從一個(gè)糟糕的想法回滾是可以落在自動化設(shè)施的肩膀上的，這可以自動化您的工作流程。

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

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

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

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

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

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

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

自動化測試

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

比如， 像這樣 ！

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

系統(tǒng)交付

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

以下是我在解決這個(gè)問題時(shí)相當(dāng)有效的算法：

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

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

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

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

測試環(huán)境

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

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

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

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

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

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

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

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

系統(tǒng)回滾

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

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

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

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

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

確保信息安全和審計(jì)

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

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

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

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

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

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

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

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

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

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

身份認(rèn)證

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

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

自動化服務(wù)配置

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

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

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

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

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

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

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

Elasticsearch是一個(gè)資源密集型的解決方案，但它可以很好地?cái)U(kuò)展并有現(xiàn)成的Docker鏡像，可以運(yùn)行在單個(gè)節(jié)點(diǎn)以及所需大小的集群上。

跟蹤系統(tǒng)

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

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

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

監(jiān)控和告警

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

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

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

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

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

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

API Gateway和單點(diǎn)登錄

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

依賴鏡像

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

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

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

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

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

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

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

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