這篇文章將帶您踏上從現(xiàn)實(shí)生活到開(kāi)發(fā)流程再到架構(gòu)，最后回到現(xiàn)實(shí)生活的旅程，并一路為您解答在這些?？空军c(diǎn)上遇到的最重要問(wèn)題。 

軟件開(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í)你的心情。

從現(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è)想法，你有代碼，那么就去做吧！

如果不是輕微的問(wèn)題，這將是完美無(wú)瑕的——集成和交付過(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ā)自內(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)用程序及其所有依賴項(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)于“黑匣子”（至于為什么我把容器稱之為如此的更多信息，將在文章中的稍后部分闡明）的情況是，它里面的一切都完好無(wú)損，是或否，1 或 0。

您可以在容器內(nèi)部執(zhí)行有限數(shù)量的命令，而 docker-compose.yml 描述了它的所有依賴關(guān)系，您可以輕松自動(dòng)化和整合這些測(cè)試，而不必過(guò)分關(guān)注實(shí)現(xiàn)細(xì)節(jié)。比如，像這樣[1]！

在這里，測(cè)試不僅意味著單元測(cè)試，還包括功能測(cè)試、集成測(cè)試、（代碼樣式）測(cè)試和副本、檢查過(guò)時(shí)的依賴關(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 收集鏡像（例如像這樣[2]）。

使用元項(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)名稱以及針對(duì)這些系統(tǒng)的 Docker 鏡像的標(biāo)簽（在上一步中獲?。?/li>

作為一個(gè)涵蓋所有系統(tǒng)和服務(wù)的元項(xiàng)目的例子（換句話說(shuō)，是一個(gè)描述生態(tài)系統(tǒng)如何編排以及如何交付更新的項(xiàng)目），我更愿意使用 Ansible playbooks，通過(guò)這個(gè)模塊[3]來(lái)與 Kube API 集成。

然而，復(fù)雜的自動(dòng)化可以參考其他選項(xiàng)，我稍后將詳細(xì)討論自己的選擇。 但是，您必須考慮中心化/統(tǒng)一的管理架構(gòu)的方式。

這樣一個(gè)方式可以讓您方便、統(tǒng)一地管理所有服務(wù)/系統(tǒng)，并消除即將到來(lái)的執(zhí)行類似功能的技術(shù)和系統(tǒng)叢林可能帶來(lái)的任何復(fù)雜情況。

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

• “測(cè)試”——用于對(duì)系統(tǒng)進(jìn)行一些手動(dòng)檢查或調(diào)試
• “預(yù)發(fā)布”——用于近乎實(shí)時(shí)的環(huán)境以及與外部系統(tǒng)的集成（通常位于DMZ而不是測(cè)試環(huán)境）
• “生產(chǎn)”——最終用戶的實(shí)際環(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è)試[4]
• 手動(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[5]的好處，包括為什么服務(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í)間?？梢哉f(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)行管理？

此列表[6]可幫助您確定適當(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，用于任何類型的通用自動(dòng)化工具。

就個(gè)人而言，我更喜歡第三個(gè)選項(xiàng)（帶有一個(gè) Kubernetes 的集成模塊），因?yàn)樗试S我使用服務(wù)器和 Kubernetes 對(duì)象并執(zhí)行任何類型的自動(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)的工程師。

在官方文檔[7]中，您可以找到關(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ì)發(fā)生故障，接著你想在生產(chǎn)環(huán)境中非常仔細(xì)地研究它們，并試圖了解“如果在我的本地機(jī)器上一切工作正常，那么在生產(chǎn)環(huán)境上究竟發(fā)生了什么錯(cuò)誤？”。

比如緩慢的數(shù)據(jù)庫(kù)查詢、不正確的緩存、較慢的磁盤(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ù)層：任何類型的應(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[8]——它與 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è)（外部用戶——公司客戶）和其他類型的訪問(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 文件[9]）。
• 能夠根據(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 定理[10]，您仍然不得不犧牲某些東西來(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ù)總線[11]”方法的理由，其目的是減少面向服務(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[12]，其中包含幾個(gè)對(duì)于此類 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)樵?Docker 環(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ù)，用于任何類型的文件存儲(chǔ)和交付（ftp，sftp 等）的一般化服務(wù)組。

依賴鏡像

如果您尚未遇到您需要的軟件包或依賴項(xiàng)已被刪除或暫時(shí)不可用的情況，請(qǐng)不要認(rèn)為這種情況永遠(yuǎn)不會(huì)發(fā)生。

為避免不必要的不可用性并為內(nèi)部系統(tǒng)提供安全保護(hù)，請(qǐng)確保構(gòu)建和交付服務(wù)都不需要 Internet 連接。

配置鏡像和復(fù)制所有的依賴項(xiàng)到內(nèi)部網(wǎng)絡(luò)：Docker 鏡像、rpm 包、源代碼庫(kù)、python/go/js/php 模塊。

這些以及其他任何類型的依賴關(guān)系都有自己的解決方案。 最常見(jiàn)的可以通過(guò)查詢“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ò)融入專業(yè)社區(qū)、閱讀相關(guān)文獻(xiàn)并與同事交流，保持自己處于生態(tài)鏈的頂端。注意項(xiàng)目中的新機(jī)會(huì)以及正確使用新趨勢(shì)。試驗(yàn)并應(yīng)用科學(xué)方法來(lái)分析研究結(jié)果，或依靠您信任和尊重的其他人的結(jié)論。

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

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

相關(guān)鏈接：

[1]https://gist.github.com/paunin/3303c8cb8dd231f961c01c0b69188c59

[2]https://github.com/paunin/images-builder

[3]https://github.com/paunin/ansible-kubernetes-module

[4]https://en.wikipedia.org/wiki/Smoke_testing_%28software%29

[5]https://www.google.com/search?q=SOA

[6]https://en.wikipedia.org/wiki/List_of_single_sign-on_implementations

[7]https://kubernetes.io/docs/concepts/cluster-administration/logging/

[8]https://www.opsgenie.com/

[9]https://swagger.io/

[10]https://en.wikipedia.org/wiki/CAP_theorem

[11]https://en.wikipedia.org/wiki/Enterprise_service_bus

[12]http://servicemix.apache.org/