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

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

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

這篇文章將帶您踏上從現實生活到開發流程再到架構回到現實生活的旅程，并一路為您解答在這些停靠站點上遇到的最重要問題。 我們將試圖確定一些應該成為架構一部分的組件和原則，并演示一些示例，但不會進入其實現領域。

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

從現實生活到開發工作流

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

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

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

然而，盡管任務看起來很復雜，但在生活中不時會出現一些優秀的想法，這些想法可以讓我們（當然，我自己是確定的）更接近構建一個無瑕疵的并且幾乎可以在任何場合使用的機制。 對我來說，離這樣的機制最近的步驟是Docker和Kubernetes，他們的抽象層次和思想方法使我認為現在可以用幾乎相同的方法解決80％的問題。

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

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

通過適當的方法，您可以自動化并整合上面序列圖中的所有內容，并在未來幾個月內將其拋之腦后。

設置開發環境

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

自動化測試

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

比如， 像這樣 ！

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

系統交付

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

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

1. 從所有 Dockerfiles 收集鏡像（例如 像這樣 ）
2. 使用元項目，通過 Kube API 將這些鏡像交付給Kubernetes。 啟動交付通常需要幾個輸入參數： 

• Kube API端點
• 一個“機密”對象，因不同的環境而異（本地/測試/預發布/生產）
• 要展示的系統名稱以及針對這些系統的Docker鏡像的標簽（在上一步中獲取）

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

通常，需要如下的安裝環境：

測試環境

集成和交付的連續性

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

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

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

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

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

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

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

系統回滾

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

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

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

以下是可以觸發回滾機制的內容：

• 發布后應用程序錯誤的高比例
• 來自關鍵監控點的信號
• 失敗的 冒煙測試
• 手動模式——人為因素

確保信息安全和審計

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

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

Kubernetes擁有一套良好的針對 訪問控制 、 網絡策略 、 事件審計 以及其他與信息安全相關的強大工具的內置機制，可用于構建一個良好的防護邊界，以抵御和阻止數據泄露。

從開發流程到架構

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

微服務架構

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

生態系統的關鍵組件和解決方案

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

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

身份認證

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

此列表 可幫助您確定適當的解決方案并估算設置和維護所需的工作量。 當然，您的選擇必須符合公司的安全政策并經信息安全部門批準。

自動化服務配置

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

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

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

Git代碼庫和任務跟蹤器

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

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

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

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

跟蹤系統

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

Opentracing 和 Zipkin 足以應付大多數現代編程語言的這一任務，并且在封裝代碼之后不會增加額外的負擔。當然，收集到的所有數據應該存儲在適當的地方，并作為一個 組件 使用。

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

監控和告警

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

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

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

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

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

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

API Gateway和單點登錄

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

內部服務的集成不應該很復雜，您的服務不應該擔心用戶和對方的授權和身份驗證。相反，架構和生態系統應該有一個處理所有通信和HTTP流量的代理服務。

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

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

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

事件總線和企業集成/服務總線

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

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

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

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

• 聚合多個消息
• 將一個事件拆分為幾個事件
• 對于事件的系統響應的同步/事務分析
• 接口的協調，這對于與外部系統的集成特別重要
• 事件路由的高級邏輯
• 與相同服務的多重集成（從外部和內部）
• 數據總線的不可擴展中心化

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

數據庫和其他有狀態的服務

和Kubernetes一樣，Docker一次又一次地改變了所有用于需要數據持久化以及與磁盤緊密相關的服務的游戲規則。有人說服務應該在物理服務器或虛擬機上以舊的方式“生存”。我尊重這一觀點，并且不會談論它的優點和缺點，但我相當肯定這種說法的存在僅僅是因為在Docker環境中暫時缺乏管理有狀態服務的知識、解決方案和經驗。

我還應該提到數據庫經常占據存儲世界的中心位置，因此您選擇的解決方案應該完全準備好在Kubernetes環境中工作。

根據我的經驗以及市場情況，我可以區分以下幾組有狀態的服務以及每個服務最適合的Docker解決方案的示例：

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

依賴鏡像

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

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

從架構到真實生活

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

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

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

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

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