基于Docker和Kubernetes的優(yōu)秀架構(gòu)實(shí)踐
是否有可能基于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)有效的算法:
- 從所有
Dockerfiles
收集鏡像(例如 像這樣 ) - 使用元項(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è)過程,否則“競爭條件”會縈繞腦海:
- 嘗試將
功能分支
更新到上游
(git rebase/ merge
) - 從
Dockerfiles
構(gòu)建鏡像 - 測試所有構(gòu)建的鏡像
- 開始并等待,直到系統(tǒng)交付了構(gòu)建自步驟2的鏡像
- 如果上一步失敗,則將生態(tài)系統(tǒng)回滾到之前的狀態(tài)
- 在
上游
合并功能分支
并將其發(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í)間”,你一定會成功的!