基于Docker和Kubernetes的優(yōu)秀架構(gòu)實(shí)踐
是否有可能基于Docker和Kubernests搭建一個(gè)最酷的架構(gòu)?這篇文章將帶您踏上架構(gòu)之旅,并一路為你講解遇到的各種問(wèn)題,現(xiàn)在,Let’s go!
軟件開(kāi)發(fā)領(lǐng)域在Docker和Kubernetes時(shí)代是如何變化的? 是否有可能使用這些技術(shù)搭建一勞永逸的架構(gòu)? 當(dāng)所有東西都被“打包”進(jìn)容器中時(shí),是否有可能統(tǒng)一開(kāi)發(fā)及集成的流程? 這些決策的需求是什么? 它們會(huì)帶來(lái)什么限制? 它們會(huì)讓開(kāi)發(fā)人員更輕松,或者相反,反而增加不必要的復(fù)雜性嗎?
現(xiàn)在是時(shí)候以文本和原始插圖方式闡明這些以及其他問(wèn)題了!
這篇文章將帶您踏上從現(xiàn)實(shí)生活到開(kāi)發(fā)流程再到架構(gòu)回到現(xiàn)實(shí)生活的旅程,并一路為您解答在這些停靠站點(diǎn)上遇到的最重要問(wèn)題。 我們將試圖確定一些應(yīng)該成為架構(gòu)一部分的組件和原則,并演示一些示例,但不會(huì)進(jìn)入其實(shí)現(xiàn)領(lǐng)域。
文章的結(jié)論可能會(huì)讓你心煩意亂,或者無(wú)比開(kāi)心,這一切都取決于你的經(jīng)驗(yàn)、你對(duì)這三章故事的看法,甚至在閱讀本文時(shí)你的心情。 在下面可以發(fā)表評(píng)論或提出問(wèn)題,讓我知道您的想法!
從現(xiàn)實(shí)生活到開(kāi)發(fā)工作流
在大多數(shù)情況下,我所見(jiàn)過(guò)的或者很榮幸搭建的所有開(kāi)發(fā)流程都只是為了一個(gè)簡(jiǎn)單的目標(biāo)——縮短從概念產(chǎn)生到交付生產(chǎn)環(huán)境之間的時(shí)間間隔,同時(shí)保持一定程度的代碼質(zhì)量。
想法的好壞無(wú)關(guān)緊要。 因?yàn)樵愀獾南敕▉?lái)也匆匆,去也匆匆——你只要嘗試一下,就可以把它們丟進(jìn)故紙堆里。 這里值得一提的是,從一個(gè)糟糕的想法回滾是可以落在自動(dòng)化設(shè)施的肩膀上的,這可以自動(dòng)化您的工作流程。
持續(xù)集成和交付看起來(lái)像是軟件開(kāi)發(fā)領(lǐng)域的救命稻草。 究竟還有什么比這更簡(jiǎn)單呢? 如果你有一個(gè)想法,你有代碼,那么就去做吧!集成和交付過(guò)程相對(duì)而言難以獨(dú)立于公司特有的技術(shù)和業(yè)務(wù)流程之外。
然而,盡管任務(wù)看起來(lái)很復(fù)雜,但在生活中不時(shí)會(huì)出現(xiàn)一些優(yōu)秀的想法,這些想法可以讓我們(當(dāng)然,我自己是確定的)更接近構(gòu)建一個(gè)無(wú)瑕疵的并且?guī)缀蹩梢栽谌魏螆?chǎng)合使用的機(jī)制。 對(duì)我來(lái)說(shuō),離這樣的機(jī)制最近的步驟是Docker和Kubernetes,他們的抽象層次和思想方法使我認(rèn)為現(xiàn)在可以用幾乎相同的方法解決80%的問(wèn)題。
其余的20%的問(wèn)題顯然還在原地踏步,但正因如此你才可以將你發(fā)自?xún)?nèi)心的創(chuàng)意天賦聚焦在有趣的工作上,而不是處理重復(fù)的例行公事。 只要照料一次“架構(gòu)框架”,就可以讓您忘掉已經(jīng)解決的80%問(wèn)題。
這一切意味著什么?以及Docker是如何解決開(kāi)發(fā)工作流程的問(wèn)題的? 讓我們看一個(gè)簡(jiǎn)單的過(guò)程,這對(duì)于大多數(shù)工作環(huán)境來(lái)說(shuō)也足夠了:
通過(guò)適當(dāng)?shù)姆椒ǎ梢宰詣?dòng)化并整合上面序列圖中的所有內(nèi)容,并在未來(lái)幾個(gè)月內(nèi)將其拋之腦后。
設(shè)置開(kāi)發(fā)環(huán)境
一個(gè)項(xiàng)目應(yīng)該包含一個(gè)docker-compose.yml文件,這可以讓你省去考慮在本地機(jī)器上運(yùn)行應(yīng)用程序/服務(wù)需要做些什么以及如何操作的問(wèn)題。 一個(gè)簡(jiǎn)單的命令docker-compose up應(yīng)該啟動(dòng)您的應(yīng)用程序及其所有依賴(lài)項(xiàng),使用fixtures填充數(shù)據(jù)庫(kù),上傳容器內(nèi)的本地代碼,啟用代碼跟蹤以便即時(shí)編譯,并最終在期望的端口開(kāi)始響應(yīng)請(qǐng)求。 即使在設(shè)置新服務(wù)時(shí),您也不必?fù)?dān)心如何啟動(dòng)、在哪里提交更改或使用哪個(gè)框架。 所有這些都應(yīng)該提前在標(biāo)準(zhǔn)說(shuō)明中描述,并由針對(duì)不同設(shè)置的服務(wù)模板指定: 前端、后端和worker
。
自動(dòng)化測(cè)試
所有你想知道的關(guān)于“黑匣子”(至于為什么我把容器稱(chēng)之為如此的更多信息,將在文章中的稍后部分闡明)的情況是,它里面的一切都完好無(wú)損,是或否,1或0。您可以在容器內(nèi)部執(zhí)行有限數(shù)量的命令,而 docker-compose.yml
描述了它的所有依賴(lài)關(guān)系,您可以輕松自動(dòng)化和整合這些測(cè)試,而不必過(guò)分關(guān)注實(shí)現(xiàn)細(xì)節(jié)。
比如, 像這樣 !
在這里,測(cè)試不僅意味著單元測(cè)試,還包括功能測(cè)試、集成測(cè)試、( 代碼樣式
)測(cè)試和副本、檢查過(guò)時(shí)的依賴(lài)關(guān)系以及已使用軟件包的許可證正常與否等等。 關(guān)鍵是所有這些都應(yīng)該封裝在Docker鏡像中。
系統(tǒng)交付
無(wú)論在何時(shí)何地想安裝您的項(xiàng)目都無(wú)所謂。 結(jié)果就像安裝進(jìn)程一樣,應(yīng)該始終如一。 至于您要安裝的是整個(gè)生態(tài)系統(tǒng)的哪個(gè)部分或者您將從哪個(gè)Git倉(cāng)庫(kù)獲得代碼也沒(méi)有區(qū)別。 這里最重要的組件是冪等性。 應(yīng)該指定的是控制安裝過(guò)程的變量。
以下是我在解決這個(gè)問(wèn)題時(shí)相當(dāng)有效的算法:
- 從所有
Dockerfiles
收集鏡像(例如 像這樣 ) - 使用元項(xiàng)目,通過(guò) Kube API 將這些鏡像交付給Kubernetes。 啟動(dòng)交付通常需要幾個(gè)輸入?yún)?shù):
- Kube API端點(diǎn)
- 一個(gè)“機(jī)密”對(duì)象,因不同的環(huán)境而異(本地/測(cè)試/預(yù)發(fā)布/生產(chǎn))
- 要展示的系統(tǒng)名稱(chēng)以及針對(duì)這些系統(tǒng)的Docker鏡像的標(biāo)簽(在上一步中獲取)
作為一個(gè)涵蓋所有系統(tǒng)和服務(wù)的元項(xiàng)目的例子(換句話說(shuō),是一個(gè)描述生態(tài)系統(tǒng)如何編排以及如何交付更新的項(xiàng)目),我更愿意使用 Ansible playbooks
,通過(guò) 這個(gè)模塊 來(lái)與Kube API集成。 然而,復(fù)雜的自動(dòng)化可以參考其他選項(xiàng),我稍后將詳細(xì)討論自己的選擇。 但是,您必須考慮中心化/統(tǒng)一的管理架構(gòu)的方式。 這樣一個(gè)方式可以讓您方便、統(tǒng)一地管理所有服務(wù)/系統(tǒng),并消除即將到來(lái)的執(zhí)行類(lèi)似功能的技術(shù)和系統(tǒng)叢林可能帶來(lái)的任何復(fù)雜情況。
通常,需要如下的安裝環(huán)境:
測(cè)試環(huán)境
集成和交付的連續(xù)性
如果你有一個(gè)統(tǒng)一的方式來(lái)測(cè)試Docker鏡像——或者“黑盒子”——你可以假設(shè)這些測(cè)試結(jié)果可以讓你無(wú)縫地(并且問(wèn)心無(wú)愧)將 功能分支
集成到你的Git倉(cāng)庫(kù)的 上游或主分支
中。
也許,這里交易斷路器是集成和交付的順序。如果沒(méi)有發(fā)行版,那么如何通過(guò)一組并行的功能分支阻止一個(gè)系統(tǒng)上的“競(jìng)爭(zhēng)條件”?
因此,只有在沒(méi)有競(jìng)爭(zhēng)的情況下才能開(kāi)始這個(gè)過(guò)程,否則“競(jìng)爭(zhēng)條件”會(huì)縈繞腦海:
- 嘗試將
功能分支
更新到上游
(git rebase/ merge
) - 從
Dockerfiles
構(gòu)建鏡像 - 測(cè)試所有構(gòu)建的鏡像
- 開(kāi)始并等待,直到系統(tǒng)交付了構(gòu)建自步驟2的鏡像
- 如果上一步失敗,則將生態(tài)系統(tǒng)回滾到之前的狀態(tài)
- 在
上游
合并功能分支
并將其發(fā)送到存儲(chǔ)庫(kù)
在任何步驟中的任何失敗都應(yīng)終止交付過(guò)程,并將任務(wù)返回給開(kāi)發(fā)人員以解決錯(cuò)誤,無(wú)論是失敗的測(cè)試還是合并沖突。
您可以使用此過(guò)程來(lái)操作多個(gè)存儲(chǔ)庫(kù)。只需一次為所有存儲(chǔ)庫(kù)執(zhí)行每個(gè)步驟(步驟1用于代碼庫(kù)A和B,步驟2用于代碼庫(kù)A和B等),而不是對(duì)每個(gè)單獨(dú)的存儲(chǔ)庫(kù)重復(fù)執(zhí)行整個(gè)流程(步驟1-6用于代碼庫(kù)A ,步驟1-6用于代碼庫(kù)B,等等)。
此外,Kubernetes允許您分批次地推出更新以進(jìn)行各種AB測(cè)試和風(fēng)險(xiǎn)分析。 Kubernetes是通過(guò)分離服務(wù)(接入點(diǎn))和應(yīng)用程序在內(nèi)部實(shí)現(xiàn)的。您可以始終以所需的比例平衡組件的新舊版本,以促進(jìn)問(wèn)題的分析并為潛在的回滾提供途徑。
系統(tǒng)回滾
架構(gòu)框架的強(qiáng)制性要求之一是能夠回滾任何部署。反過(guò)來(lái),這又需要一些顯式和隱式的細(xì)微差別。以下是其中最重要的一些事項(xiàng):
- 服務(wù)應(yīng)該能夠設(shè)置其環(huán)境以及回滾更改。例如,數(shù)據(jù)庫(kù)遷移、RabbitMQ schema等等。
- 如果無(wú)法回滾環(huán)境,則該服務(wù)應(yīng)該是多態(tài)的,并支持舊版本和新版本的代碼。例如:數(shù)據(jù)庫(kù)遷移不應(yīng)該中斷舊版本的服務(wù)(通常是2或3個(gè)以前的版本)
- 向后兼容任何服務(wù)更新。通常,這是API兼容性,消息格式等。
在Kubernetes集群中回滾狀態(tài)相當(dāng)簡(jiǎn)單(運(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ò)誤的高比例
- 來(lái)自關(guān)鍵監(jiān)控點(diǎn)的信號(hào)
- 失敗的 冒煙測(cè)試
- 手動(dòng)模式——人為因素
確保信息安全和審計(jì)
沒(méi)有一個(gè)工作流程可以奇跡般地“搭建”刀槍不入的安全性并保護(hù)您的生態(tài)系統(tǒng)免受外部和內(nèi)部威脅,因此您需要確保您的架構(gòu)框架是在每個(gè)級(jí)別和所有子系統(tǒng)里按照公司的標(biāo)準(zhǔn)和安全策略執(zhí)行的。
我將在后面的關(guān)于監(jiān)控和告警的章節(jié)討論有關(guān)解決方案的所有三個(gè)級(jí)別,它們本身也是系統(tǒng)完整性的關(guān)鍵。
Kubernetes擁有一套良好的針對(duì) 訪問(wèn)控制 、 網(wǎng)絡(luò)策略 、 事件審計(jì) 以及其他與信息安全相關(guān)的強(qiáng)大工具的內(nèi)置機(jī)制,可用于構(gòu)建一個(gè)良好的防護(hù)邊界,以抵御和阻止數(shù)據(jù)泄露。
從開(kāi)發(fā)流程到架構(gòu)
應(yīng)該認(rèn)真考慮將開(kāi)發(fā)流程與生態(tài)系統(tǒng)緊密集成的想法。將這種集成的需求添加到架構(gòu)的傳統(tǒng)需求集(彈性、可伸縮性、可用性、可靠性、抵御威脅等)中,可以大大提高架構(gòu)框架的價(jià)值。 這是至關(guān)重要的一個(gè)方面,由此導(dǎo)致出現(xiàn)了一個(gè)名為“DevOps”(開(kāi)發(fā)運(yùn)維)的概念,這是實(shí)現(xiàn)基礎(chǔ)設(shè)施全面自動(dòng)化并優(yōu)化的合理步驟。 但是,如果有一個(gè)設(shè)計(jì)良好的架構(gòu)和可靠的子系統(tǒng),DevOps任務(wù)可以被最小化。
微服務(wù)架構(gòu)
沒(méi)有必要詳細(xì)討論 面向服務(wù)的架構(gòu)——SOA 的好處,包括為什么服務(wù)應(yīng)該是“微”的。 我只會(huì)說(shuō),如果你決定使用Docker和Kubernetes,那么你很可能理解(并接受)單體應(yīng)用架構(gòu)是很困難甚至根子上就是錯(cuò)誤的。 Docker旨在運(yùn)行一個(gè)進(jìn)程并持久化,Docker讓我們聚焦于DDD框架(領(lǐng)域驅(qū)動(dòng)開(kāi)發(fā))內(nèi)進(jìn)行思考。 在Docker中,打包后的代碼被視為具有一些公開(kāi)端口的黑盒子。
生態(tài)系統(tǒng)的關(guān)鍵組件和解決方案
根據(jù)我在設(shè)計(jì)具有更高可用性和可靠性的系統(tǒng)方面的經(jīng)驗(yàn),有幾個(gè)組件對(duì)于微服務(wù)的運(yùn)維是至關(guān)重要的,稍后我會(huì)列出并討論這些組件,我將在Kubernetes環(huán)境中引用它們,也可以參考我的清單作為其它任何平臺(tái)的檢查單。
如果你(像我一樣)會(huì)得出這樣的結(jié)論,即將這些組件作為常規(guī)的Kubernetes服務(wù)來(lái)管理,那么我建議你在除“生產(chǎn)環(huán)境”之外的單獨(dú)集群中運(yùn)行它們。 比如“預(yù)發(fā)布”集群,因?yàn)樗梢栽谏a(chǎn)環(huán)境不穩(wěn)定并且你迫切需要其鏡像、代碼或監(jiān)控工具的來(lái)源時(shí)節(jié)省你的時(shí)間。 可以說(shuō),這解決了雞和雞蛋的問(wèn)題。
身份認(rèn)證
像往常一樣,它始于訪問(wèn)——服務(wù)器、虛擬機(jī)、應(yīng)用程序、辦公室郵件等。 如果您是或想成為主要的企業(yè)平臺(tái)(IBM、Google、Microsoft)之一的客戶,則訪問(wèn)問(wèn)題將由供應(yīng)商的某個(gè)服務(wù)處理。 但是,如果您想擁有自己的解決方案,難道只能由您并在您的預(yù)算之內(nèi)進(jìn)行管理?
此列表 可幫助您確定適當(dāng)?shù)慕鉀Q方案并估算設(shè)置和維護(hù)所需的工作量。 當(dāng)然,您的選擇必須符合公司的安全政策并經(jīng)信息安全部門(mén)批準(zhǔn)。
自動(dòng)化服務(wù)配置
盡管Kubernetes在物理機(jī)器/云虛擬機(jī)(Docker、kubelet、kube proxy、etcd集群)上只需要少量組件,但對(duì)于新機(jī)器的添加和集群管理仍然需要自動(dòng)化。 以下是一些簡(jiǎn)單的方法:
- KOPS ——此工具允許您在兩個(gè)云供應(yīng)商(AWS或GCE)之一上安裝集群
- Teraform ——這可以讓您管理任何環(huán)境的基礎(chǔ)設(shè)施,并遵循IAC(基礎(chǔ)架設(shè)施即代碼)的思想
- Ansible ——用于任何類(lèi)型的通用自動(dòng)化工具
就個(gè)人而言,我更喜歡第三個(gè)選項(xiàng)(帶有一個(gè) Kubernetes的集成模塊 ),因?yàn)樗试S我使用服務(wù)器和Kubernetes對(duì)象并執(zhí)行任何類(lèi)型的自動(dòng)化。 但是,沒(méi)有什么能阻止您使用Teraform及其 Kubernetes模塊 。 KOPS在“裸機(jī)”方面效果不佳,但它仍然是與AWS/GCE一起使用的工具!
Git代碼庫(kù)和任務(wù)跟蹤器
對(duì)于任何Docker容器,使其日志可訪問(wèn)的方法是將它們寫(xiě)入正在容器中運(yùn)行的根進(jìn)程的STDOUT或STDERR,服務(wù)開(kāi)發(fā)人員并不關(guān)心日志數(shù)據(jù)接下來(lái)的變化,而主要是它們應(yīng)該在必要時(shí)可用,并且包含過(guò)去某個(gè)點(diǎn)的記錄。滿足這些期許的所有責(zé)任在于Kubernetes以及支持生態(tài)系統(tǒng)的工程師。
在 官方文檔 中,您可以找到關(guān)于處理日志的基本(和好的)策略的說(shuō)明,這將有助于您選擇用于聚合和存儲(chǔ)大量文本數(shù)據(jù)的服務(wù)。
在針對(duì)日志系統(tǒng)的推薦服務(wù)中,同一文檔提到 fluentd 用于收集數(shù)據(jù)(在集群的每個(gè)節(jié)點(diǎn)上作為代理啟動(dòng)時(shí))以及用于存儲(chǔ)和索引數(shù)據(jù)的 Elasticsearch 。即使你可能不贊同這個(gè)解決方案的效率,但鑒于它的可靠性和易用性,我認(rèn)為這至少是一個(gè)好的開(kāi)始。
Elasticsearch是一個(gè)資源密集型的解決方案,但它可以很好地?cái)U(kuò)展并有現(xiàn)成的Docker鏡像,可以運(yùn)行在單個(gè)節(jié)點(diǎn)以及所需大小的集群上。
跟蹤系統(tǒng)
即使代碼很好,然而還是會(huì)確實(shí)發(fā)生故障,接著你想在生產(chǎn)環(huán)境中非常仔細(xì)地研究它們,并試圖了解“如果在我的本地機(jī)器上一切工作正常,那么在生產(chǎn)環(huán)境上究竟發(fā)生了什么錯(cuò)誤?”。比如緩慢的數(shù)據(jù)庫(kù)查詢(xún)、不正確的緩存、較慢的磁盤(pán)或與外部資源的連接、生態(tài)系統(tǒng)中的交易,瓶頸以及規(guī)模不足的計(jì)算服務(wù)都是您不得不跟蹤和估算在實(shí)際負(fù)載下代碼執(zhí)行時(shí)間的一些原因。
Opentracing 和 Zipkin 足以應(yīng)付大多數(shù)現(xiàn)代編程語(yǔ)言的這一任務(wù),并且在封裝代碼之后不會(huì)增加額外的負(fù)擔(dān)。當(dāng)然,收集到的所有數(shù)據(jù)應(yīng)該存儲(chǔ)在適當(dāng)?shù)牡胤?,并作為一個(gè) 組件 使用。
通過(guò)上述的開(kāi)發(fā)標(biāo)準(zhǔn)和服務(wù)模板可以解決在封裝代碼以及通過(guò)服務(wù)、消息隊(duì)列、數(shù)據(jù)庫(kù)等轉(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上獲得了 開(kāi)箱即用 的支持。您可以參考 官方Kubernetes文檔 來(lái)了解更多關(guān)于監(jiān)控和警報(bào)的信息。
監(jiān)控是必須安裝在集群內(nèi)的少數(shù)幾個(gè)輔助系統(tǒng)之一,集群是一個(gè)受監(jiān)控的實(shí)體。但是對(duì)于監(jiān)控系統(tǒng)的監(jiān)控(抱歉有些啰嗦)只能從外部進(jìn)行(例如,從相同的“預(yù)發(fā)布”環(huán)境)。在這種情況下,交叉檢查可作為一個(gè)針對(duì)任何分布式環(huán)境的便捷解決方案,這不會(huì)使高度統(tǒng)一的生態(tài)系統(tǒng)架構(gòu)復(fù)雜化。
整個(gè)監(jiān)控范圍可以分為三個(gè)完全邏輯隔離的層級(jí)。以下是我認(rèn)為的在每個(gè)層級(jí)最重要的跟蹤點(diǎn)例子:
- 物理層:網(wǎng)絡(luò)資源及其可用性——磁盤(pán)(I/O,可用空間)——單個(gè)節(jié)點(diǎn)(CPU、RAM、LA)的基本資源
- 集群層:——每個(gè)節(jié)點(diǎn)上主集群系統(tǒng)的可用性(kubelet、kubeAPI、DNS、etcd等)——可用資源數(shù)量及其均勻分布——允許的可用資源相對(duì)于服務(wù)消耗的實(shí)際資源的監(jiān)控——pod的重新加載
- 服務(wù)層:——任何類(lèi)型的應(yīng)用程序監(jiān)控——從數(shù)據(jù)庫(kù)內(nèi)容到API調(diào)用頻率——API網(wǎng)關(guān)上的HTTP錯(cuò)誤數(shù)量——隊(duì)列大小和worker的利用率——數(shù)據(jù)庫(kù)的多個(gè)度量標(biāo)準(zhǔn)(復(fù)制延遲、事務(wù)的時(shí)間和數(shù)量、緩慢的請(qǐng)求等)——對(duì)非HTTP進(jìn)程的錯(cuò)誤分析——發(fā)送到日志系統(tǒng)請(qǐng)求的監(jiān)控(可以將任何請(qǐng)求轉(zhuǎn)換為度量標(biāo)準(zhǔn))
至于在每個(gè)層級(jí)的告警通知,我想推薦使用了無(wú)數(shù)次的其中一個(gè)外部服務(wù),可以發(fā)送通知電子郵件,短信或打電話給手機(jī)號(hào)碼。我還會(huì)提到另一個(gè)系統(tǒng)—— OpsGenie ——它與 Prometheus的alertmanaer 是緊密集成的。
OpsGenie是一種彈性的告警工具,可幫助處理升級(jí)、全天候工作、通知渠道選擇等等。在團(tuán)隊(duì)之間分發(fā)告警也很容易。例如,不同級(jí)別的監(jiān)控應(yīng)向不同的團(tuán)隊(duì)/部門(mén)發(fā)送通知:物理——Infra + Devops,集群——Devops,應(yīng)用程序——每一個(gè)相關(guān)的團(tuán)隊(duì)。
API Gateway和單點(diǎn)登錄
要處理諸如授權(quán)、認(rèn)證、用戶注冊(cè)(外部用戶——公司客戶)和其他類(lèi)型的訪問(wèn)控制等任務(wù),您需要高度可靠的服務(wù),以保持與API Gateway的彈性集成。使用與“身份服務(wù)”相同的解決方案沒(méi)有什么壞處,但是您可能需要分離這兩種資源以實(shí)現(xiàn)不同級(jí)別的可用性和可靠性。
內(nèi)部服務(wù)的集成不應(yīng)該很復(fù)雜,您的服務(wù)不應(yīng)該擔(dān)心用戶和對(duì)方的授權(quán)和身份驗(yàn)證。相反,架構(gòu)和生態(tài)系統(tǒng)應(yīng)該有一個(gè)處理所有通信和HTTP流量的代理服務(wù)。
讓我們考慮一下最適合與API Gateway集成的方式,即整個(gè)生態(tài)系統(tǒng)——令牌。此方法適用于所有三種訪問(wèn)方案:從UI、從服務(wù)到服務(wù)以及從外部系統(tǒng)。接著,接收令牌(基于登錄名和密碼)的任務(wù)由用戶界面本身或服務(wù)開(kāi)發(fā)人員完成。區(qū)分UI中使用的令牌的生命周期(較短的TTL)和其他情況(較長(zhǎng)的和自定義的TTL)也是有意義的。
以下是API Gateway解決的一些問(wèn)題:
- 從外部和內(nèi)部訪問(wèn)生態(tài)系統(tǒng)服務(wù)(服務(wù)不直接相互通信)
- 與單點(diǎn)登錄服務(wù)集成:令牌轉(zhuǎn)換和附加HTTPS請(qǐng)求,頭部包含所請(qǐng)求服務(wù)的用戶標(biāo)識(shí)數(shù)據(jù)(ID、角色和其他詳細(xì)信息)——根據(jù)從單點(diǎn)登錄服務(wù)接收到的角色啟用/禁用對(duì)所請(qǐng)求服務(wù)的訪問(wèn)控制
- 針對(duì)HTTP流量的單點(diǎn)監(jiān)控
- 復(fù)合不同服務(wù)的API文檔(例如,復(fù)合 Swagger的json/yml文件 )
- 能夠根據(jù)域和請(qǐng)求的URI管理整個(gè)生態(tài)系統(tǒng)的路由
- 用于外部流量的單一接入點(diǎn),以及與接入供應(yīng)商的集成
事件總線和企業(yè)集成/服務(wù)總線
如果您的生態(tài)系統(tǒng)包含數(shù)百個(gè)可在一個(gè)宏域中工作的服務(wù),則您將不得不處理服務(wù)通信的數(shù)千種可能方式。為了簡(jiǎn)化數(shù)據(jù)流,您應(yīng)該具備在發(fā)生特定事件時(shí)將信息分發(fā)到大量收件人的能力,而不管事件的上下文如何。換句話說(shuō),您需要一個(gè)事件總線來(lái)發(fā)布基于標(biāo)準(zhǔn)協(xié)議的事件并訂閱它們。
作為事件總線,您可以使用任何可以操作所謂Broker的系統(tǒng): RabbitMQ 、 Kafka 、 ActiveMQ 等。一般來(lái)說(shuō),數(shù)據(jù)的高可用性和一致性對(duì)于微服務(wù)是至關(guān)重要的,但是由于 CAP定理 ,您仍然不得不犧牲某些東西來(lái)實(shí)現(xiàn)總線的正確分布和集群化。
自然,事件總線應(yīng)該能夠解決各種服務(wù)間通信問(wèn)題,但隨著服務(wù)數(shù)量從幾百個(gè)增加到幾千個(gè)甚至幾萬(wàn)個(gè),即使是基于事件總線的架構(gòu)也會(huì)望而卻步,您將需要尋找另一種解決方案。一個(gè)很好的例子就是集成總線方法,它可以擴(kuò)展上述“Dumb管——智能消費(fèi)”策略的功能。
有幾十個(gè)使用“ 企業(yè)集成/服務(wù)總線 ”方法的理由,其目的是減少面向服務(wù)架構(gòu)的復(fù)雜性。以下是其中幾個(gè)理由:
- 聚合多個(gè)消息
- 將一個(gè)事件拆分為幾個(gè)事件
- 對(duì)于事件的系統(tǒng)響應(yīng)的同步/事務(wù)分析
- 接口的協(xié)調(diào),這對(duì)于與外部系統(tǒng)的集成特別重要
- 事件路由的高級(jí)邏輯
- 與相同服務(wù)的多重集成(從外部和內(nèi)部)
- 數(shù)據(jù)總線的不可擴(kuò)展中心化
作為企業(yè)集成總線的一款開(kāi)源軟件,您可能需要考慮 Apache ServiceMix ,其中包含幾個(gè)對(duì)于此類(lèi)SOA的設(shè)計(jì)和開(kāi)發(fā)至關(guān)重要的組件。
數(shù)據(jù)庫(kù)和其他有狀態(tài)的服務(wù)
和Kubernetes一樣,Docker一次又一次地改變了所有用于需要數(shù)據(jù)持久化以及與磁盤(pán)緊密相關(guān)的服務(wù)的游戲規(guī)則。有人說(shuō)服務(wù)應(yīng)該在物理服務(wù)器或虛擬機(jī)上以舊的方式“生存”。我尊重這一觀點(diǎn),并且不會(huì)談?wù)撍膬?yōu)點(diǎn)和缺點(diǎn),但我相當(dāng)肯定這種說(shuō)法的存在僅僅是因?yàn)樵贒ocker環(huán)境中暫時(shí)缺乏管理有狀態(tài)服務(wù)的知識(shí)、解決方案和經(jīng)驗(yàn)。
我還應(yīng)該提到數(shù)據(jù)庫(kù)經(jīng)常占據(jù)存儲(chǔ)世界的中心位置,因此您選擇的解決方案應(yīng)該完全準(zhǔn)備好在Kubernetes環(huán)境中工作。
根據(jù)我的經(jīng)驗(yàn)以及市場(chǎng)情況,我可以區(qū)分以下幾組有狀態(tài)的服務(wù)以及每個(gè)服務(wù)最適合的Docker解決方案的示例:
- 數(shù)據(jù)庫(kù)管理系統(tǒng)—— PostDock 是在任何Docker環(huán)境中PostgreSQL簡(jiǎn)單可靠的解決方案
- 隊(duì)列/消息代理—— RabbitMQ 是構(gòu)建消息隊(duì)列系統(tǒng)和路由消息的經(jīng)典軟件。 RabbitMQ配置中的
cluster_formation
參數(shù)對(duì)于集群設(shè)置是必不可少的 - 高速緩存服務(wù)—— Redis 被認(rèn)為是最可靠和彈性的數(shù)據(jù)高速緩存解決方案之一
- 全文搜索——我上面已經(jīng)提到過(guò)的 Elasticsearch 技術(shù)棧,最初用于全文搜索,但同樣擅長(zhǎng)存儲(chǔ)日志和任何具有大量文本數(shù)據(jù)的工作
- 文件存儲(chǔ)服務(wù)——用于任何類(lèi)型的文件存儲(chǔ)和交付(ftp,sftp等)的一般化服務(wù)組
依賴(lài)鏡像
如果您尚未遇到您需要的軟件包或依賴(lài)項(xiàng)已被刪除或暫時(shí)不可用的情況,請(qǐng)不要認(rèn)為這種情況永遠(yuǎn)不會(huì)發(fā)生。 為避免不必要的不可用性并為內(nèi)部系統(tǒng)提供安全保護(hù),請(qǐng)確保構(gòu)建和交付服務(wù)都不需要Internet連接。 配置鏡像和復(fù)制所有的依賴(lài)項(xiàng)到內(nèi)部網(wǎng)絡(luò):Docker鏡像、rpm包、源代碼庫(kù)、python/go/js/php模塊。
這些以及其他任何類(lèi)型的依賴(lài)關(guān)系都有自己的解決方案。 最常見(jiàn)的可以通過(guò)查詢(xún)“ private dependency mirror for ... ”來(lái)Google搜索。
從架構(gòu)到真實(shí)生活
不管你喜不喜歡,你的整個(gè)架構(gòu)遲早會(huì)難以為繼。它總是會(huì)發(fā)生:技術(shù)過(guò)時(shí)很快(1 - 5年),方法和方法論——有點(diǎn)慢(5 - 10年),設(shè)計(jì)原則和基礎(chǔ)——偶爾(10 - 20年),但終歸是不可避免的。
考慮到技術(shù)的過(guò)時(shí),需要總是試圖讓自己的生態(tài)系統(tǒng)處于技術(shù)創(chuàng)新的高峰期,計(jì)劃并推出新的服務(wù)以滿足開(kāi)發(fā)人員、業(yè)務(wù)和最終用戶的需求,向您的利益相關(guān)者推廣新的實(shí)用程序,交付知識(shí)來(lái)推動(dòng)您的團(tuán)隊(duì)和公司前進(jìn)。
通過(guò)融入專(zhuān)業(yè)社區(qū)、閱讀相關(guān)文獻(xiàn)并與同事交流,保持自己處于生態(tài)鏈的頂端。注意項(xiàng)目中的新機(jī)會(huì)以及正確使用新趨勢(shì)。試驗(yàn)并應(yīng)用科學(xué)方法來(lái)分析研究結(jié)果,或依靠您信任和尊重的其他人的結(jié)論。
除非你是本領(lǐng)域的專(zhuān)家,否則很難為根本性的變化做好準(zhǔn)備。我們所有人只會(huì)在我們的整個(gè)職業(yè)生涯中見(jiàn)證一些重大的技術(shù)變化,但并不是我們頭腦中的知識(shí)數(shù)量使得我們攀登到頂峰的,而是我們思維的開(kāi)放性以及接受蛻變的能力。
回到標(biāo)題中的問(wèn)題:“是否有可能搭建一個(gè)更好的架構(gòu)?”。答案顯而易見(jiàn):不,不是“一勞永逸”,但一定要在某種程度上積極爭(zhēng)取,在未來(lái)某個(gè)“很短的時(shí)間”,你一定會(huì)成功的!