Kubernetes, Kafka微服務架構模式講解及相關使用者案例
問題導讀
1.微服務有什麼特點？
2.本文介紹了哪些案例？
3.你認為事件驅動的微服務、容器、Kubernetes和機器學習結合可以有哪些應用？
隨著當今業務和技術的快速變化，開發人員，資料科學家和IT運營部門正在共同構建具有新技術和動態架構的智慧應用程式，因為它們具有靈活性，交付速度和可維護性。 這篇文章將介紹有助於進化架構的技術：containers，Kubernetes和Kafka API。 然後我們將看一些Kafka 架構模式和使用者案例.
容器架構
容器簡化了從開發到部署的過程，無需擔心可移植性或可重複性。 開發人員可以將應用程式及其執行應用程式所需的所有依賴項，庫和配置檔案打包到容器映象中。 容器是可執行的映象例項，可以部署到任何位置：膝上型電腦，本地伺服器或雲端。
與虛擬機器相比，容器具有類似的資源和隔離優勢，但重量更輕，因為容器虛擬化作業系統而不是硬體。 容器更便攜，更高效，佔用更少的空間，使用更少的系統資源。
Kubernetes 架構
Kubernetes提供了一個配置，自動化和管理的平臺：
容器的智慧和平衡排程
容器的建立，刪除和移動
易於擴充套件容器
監測和自我修復能力
Kubernetes叢集由至少一個管理叢集的主節點和多個工作節點組成，其中容器化應用程式使用Pod執行。 Pod是一個或多個容器的邏輯分組，它們一起安排並共享資源。 Pod允許多個容器在主機上執行並共享資源，例如：儲存，網路和容器執行時資訊。
主節點以這種方式管理叢集：
API伺服器解析YAML配置並將配置儲存在etcd鍵值儲存中。
etcd儲存並複製當前配置和叢集的執行狀態。
排程程式排程工作節點上的pod。
controller 管理器管理非終止控制迴圈的狀態，例如pod副本。
微服務架構風格是一種將應用程式開發為圍繞特定業務功能構建的一組小型企業可部署服務的方法。 微服務方法與容器和Kubernetes完全一致。 通過跨多個節點部署服務，您可以獲得模組化，廣泛的並行性和經濟高效的擴充套件。 微服務模組化有助於獨立更新/部署，並有助於避免單點故障，這有助於防止大規模中斷。
MapR Data Fabric包含一個本機整合的Kubernetes卷驅動程式，可提供持久儲存卷，以訪問本地，跨雲和邊緣的任何資料。 有狀態應用程式可用於生產用例，機器學習管道和多租戶用例的容器中。
事件驅動的微服務架構
大多數業務資料是作為一系列事件或事件流生成的：例如，Web或移動應用程式互動，感測器資料，銀行交易和醫療裝置。 微服務通常具有事件驅動架構，使用僅附加事件流，例如Kafka或MapR事件流（提供Kafka API）。
使用MapR-ES（或Kafka），事件被分組為稱為“topics”的事件的邏輯集合。 主題【topics】被分割槽並行處理。
與佇列不同，事件在傳遞後不會被刪除，而是保留在分割槽上，可供其它消費者使用。
基於流的有效時間設定，舊的訊息會被刪除。如果設定為0，則永遠不會被刪除。
在讀取時，訊息不會從主題中刪除，並且主題可以具有多個不同的消費者；這允許不同的消費者針對不同的目的處理相同的訊息。Pipelining 也是可能的，其中消費者將event 釋出到另一個主題。
MAPR ES提供可擴充套件的高效能訊息傳遞，在普通硬體上每秒傳送數百萬條訊息。釋出/訂閱kafka API提供解耦的通訊，使得在不破壞現有程序的情況下很容易新增新的listeners 或新publishers 。
當將這些訊息傳遞能力與微服務相結合時，可以極大地增強構建、部署和維護複雜資料管道的靈活性。通過簡單地連結多個微服務來構建流水線，每個微服務監聽某些資料的到達，執行指定的任務，並且可選地將其自己的訊息釋出到一個主題。
流是記錄系統
事件源是一種體系結構模式，其中應用程式的狀態由一系列事件決定，每個事件都記錄在僅追加事件儲存或則流中。 例如，假設每個“事件”是對資料庫中條目的增量更新。 在這種情況下，特定條目的狀態僅僅是與該條目有關的事件的累積。在下面的示例中，流儲存所有存款和取款事件的佇列，資料庫表儲存當前帳戶餘額。
流或資料庫，哪一個是更好的記錄系統？流中的事件可以用來重建資料庫中的賬戶餘額，而資料庫卻不能反過。
微服務新增到單片銀行應用程式
銀行通常有大型機應用程式，這些應用程式執行成本高，難於更新，也難於完全替換。讓我們來看看如何將事件驅動的微服務新增到一個整體銀行應用程式中，該應用程式包括支付事務和批處理作業，用於欺詐檢測、報表和促銷郵件。
在如下所示的設計中，來自單片資料庫提交日誌的支付事務被髮布到流中，流被設定為永不丟棄資料。不變事件儲存(流)成為記錄系統，事件由不同的資料管道根據用例處理。事件資料管道通向多種語言永續性、不同的資料儲存技術，每一種技術都提供不同的物化檢視:MapR-DB HBase和MapR-DB JSON文件、圖形和搜尋資料庫，因此，微服務總是以最合適的格式顯示其資料的最新檢視。使用命令查詢責任分離模式。
事件儲存通過在流中重新執行事件來提供重建狀態——這是事件來源模式。事件可以重新處理，以建立新的索引、快取或資料檢視。
consumer簡單的讀取從最舊的訊息到最新的建立一個數據檢視
現在支付交易來自實時，使用Spark Machine Learning和Streaming進行實時欺詐檢測可能比以前更容易，如資料流所示：
對於流中的事件具有較長的保留時間允許更多的分析和功能被新增。
通過新增事件和微服務來開發體系結構
隨著更多的事件源，可以新增流處理和機器學習以提供新的功能。跨範圍的互動（包括點選流、點選率、呼叫中心報告、客戶偏好和購買資料）的機器學習技術可以用來提供見解，例如：財務建議、預測、警報和相關優惠。例如，可以將Web點選流分析與購買歷史相結合，將共享行為親和力的客戶分組，以便更好地針對廣告。當客戶點選目標提供，觸發MAPR DB中的客戶配置檔案更新，並向前景自動運動時，可以將領先事件新增到流中。
醫療保健例項
現在讓我們來看看如何實現流優先架構。 來自某醫院，供應商和實驗室的資料。 MapR-ES解決了HIPAA合規性的資料沿襲問題，因為流成為每個資料變化的無限，不可變日誌的記錄系統。 多語言永續性解決了儲存多種資料格式的問題。 可以為不同的用例提供，探索和分析MapR-DB HBase API / MapR-DB JSON API，圖形和搜尋資料庫，物化檢視。
零售示例
一家大型零售商希望提高季節敏捷性和庫存紀律，以便對需求變化作出反應並減少降價。
資料收集自銷售交易、庫存狀況和定價、競爭情報、社交媒體、天氣和客戶(去掉個人身份識別)，以便集中分析與改善業務相關的相關性和模式。大資料演算法分析店內和線上購物、Twitter趨勢、本地體育賽事和天氣購買模式，構建個性化客戶體驗的創新應用程式，同時提高物流效率。銷售點交易被分析以提供產品推薦或折扣，基於哪些產品是一起購買的，或者是在其他產品之前。預測分析是用來知道在某些特定的日子裡，哪些產品在某些特定的商店裡賣得更多，以減少庫存過剩，並保持對最需要的產品的適當儲備，從而幫助優化供應鏈。
結論
幾個不同的技術轉移的融合極大地改變了應用程式的構建方式。事件驅動的微服務、容器、Kubernetes和機器學習資料管道的結合正在加速下一代智慧應用的發展，這些應用正在利用現代計算基礎設施所驅動的現代計算範例。MAPR融合資料平臺集成了全球事件流、實時資料庫能力和可擴充套件的企業儲存，以及資料處理和分析引擎的集合，為新一代的資料處理流水線和智慧應用提供動力。
轉載註明來自about雲
本文連結
http://www.aboutyun.com/forum.php?mod=viewthread&tid=24783
本公眾號精彩文章推薦：