26 月 XNUMX 日，我們舉辦了 Apache Ignite GreenSource 聚會，開源專案的貢獻者在會上發言 。 這個社區生活中一個重要的事件是組件的重組 ，它允許您將自訂微服務直接部署到 Ignite 叢集中。 他在聚會中談到了這個艱難的過程 、軟體工程師和 Apache Ignite 貢獻者已有兩年多。
讓我們從 Apache Ignite 的整體情況開始。 這是一個分散式鍵/值儲存資料庫，支援 SQL、事務性和快取。 此外，Ignite 可讓您將自訂服務直接部署到 Ignite 叢集中。 開發人員可以存取 Ignite 提供的所有工具 - 分散式資料結構、訊息傳遞、串流媒體、計算和資料網格。 例如，當使用資料網格時，管理單獨的資料儲存基礎架構的問題以及由此產生的管理費用就消失了。
使用服務網格 API，您只需在組態中指定部署方案以及對應的服務本身即可部署服務。
通常，部署方案指示應在叢集節點上部署的執行個體數量。 典型的部署方案有兩種。 第一個是叢集單例：在任何給定時間，保證使用者服務的一個實例在叢集中可用。 第二種是節點單例：在每個叢集節點上部署一個服務實例。
使用者還可以指定整個叢集中服務實例的數量，並定義謂詞來過濾合適的節點。 在這種情況下，服務網格本身將計算部署服務的最佳分佈。
另外，還有Affinity Service這樣的功能。 親和性是定義金鑰與分區的關係以及拓樸中各方與節點的關係的函數。 透過該鍵，您可以確定儲存資料的主節點。 透過這種方式，您可以將自己的服務與金鑰和關聯函數快取相關聯。 如果親和函數發生變化，就會發生自動重新部署。 這樣，服務將始終位於其需要操作的資料附近，從而減少存取資訊的開銷。 這種方案可以稱為一種並置計算。
既然我們已經弄清楚了Service Grid的美妙之處，那麼我們就來談談它的發展歷史。
之前發生了什麼
服務網格的先前實作基於 Ignite 的事務複製系統快取。 Ignite 中的「快取」一詞指的是儲存。 也就是說，這並不像您想像的那樣是暫時的。 儘管快取是複製的並且每個節點都包含整個資料集，但在快取內部它具有分區表示。 這是由於儲存優化所致。
當使用者想要部署服務時發生了什麼事？
- 叢集中的所有節點使用內建的連續查詢機制訂閱更新儲存體中的資料。
- 發起節點在讀取提交事務下，在包含服務配置（包括序列化實例）的資料庫中進行記錄。
- 當收到新條目的通知時，協調器根據配置計算分配。 結果物件被寫回資料庫。
- 如果節點是分發的一部分，則協調器必須部署它。
什麼不適合我們
在某些時候，我們得出結論：這不是使用服務的方式。 有幾個原因。
如果部署過程中出現錯誤，那麼只能從發生錯誤的節點的日誌中找到。 只有非同步部署，因此從部署方法將控制權傳回給使用者後，需要一些額外的時間來啟動服務 - 在此期間使用者無法控制任何事情。 為了進一步發展服務網格、創建新功能、吸引新用戶並使每個人的生活更輕鬆，需要做出一些改變。
在設計新的服務網格時，我們首先希望提供同步部署的保證：一旦使用者從API傳回控制權，他就可以立即使用服務。 我還想賦予發起者處理部署錯誤的能力。
此外，我想簡化實施，即擺脫交易和重新平衡。 儘管快取是複製的並且沒有平衡，但在具有許多節點的大型部署期間還是會出現問題。 當拓撲發生變化時，節點需要交換訊息，並且在大型部署中，這些數據可能會很重。
當拓樸不穩定時，協調器需要重新計算服務的分配。 一般來說，當您必須在不穩定的拓撲上處理交易時，這可能會導致難以預測的錯誤。
問題
什麼是沒有伴隨問題的全球變遷？ 第一個是拓樸結構的變化。 你需要明白，在任何時刻，甚至在服務部署的時刻，節點都可以進入或離開叢集。 此外，如果在部署時節點加入集群，則需要一致地將有關服務的所有資訊傳輸到新節點。 我們不僅討論已經部署的內容，還討論當前和未來的部署。
這只是可以收集在單獨清單中的問題之一：
- 如何在節點啟動時部署靜態配置的服務？
- 從叢集離開節點 - 如果該節點託管服務該怎麼辦？
- 如果協調員變更了怎麼辦？
- 如果客戶端重新連接叢集怎麼辦？
- 是否需要處理啟用/停用請求以及如何處理？
- 如果他們要求銷毀緩存，而我們有與之相關的關聯服務怎麼辦？
這還不是全部。
解決方法
作為目標，我們選擇了事件驅動方法，使用訊息實現流程通訊。 Ignite 已經實作了兩個允許節點在它們之間轉發訊息的元件 - communications-spi 和 discovery-spi。
Communication-spi允許節點直接通訊並轉發訊息。 它非常適合發送大量數據。 Discovery-spi 可讓您向叢集中的所有節點發送訊息。 在標準實作中，這是使用環形拓撲來完成的。 還與 Zookeeper 集成，在本例中使用星形拓撲。 另一個值得注意的重要點是 discovery-spi 保證訊息一定會以正確的順序傳遞到所有節點。
讓我們看一下部署協定。 所有使用者的部署和取消部署請求均透過 discovery-spi 傳送。 這給了以下內容 保證:
- 該請求將被叢集中的所有節點接收。 這將允許請求在協調器更改時繼續處理。 這也意味著在一則訊息中，每個節點都將擁有所有必要的元數據，例如服務配置及其序列化實例。
- 嚴格的訊息傳遞順序有助於解決配置衝突和競爭請求。
- 由於節點進入拓撲也是透過 discovery-spi 處理的，因此新節點將接收使用服務所需的所有資料。
當收到請求時，叢集中的節點會驗證該請求並建立處理任務。 這些任務排隊，然後由單獨的工作人員在另一個執行緒中處理。 之所以以這種方式實現，是因為部署可能會花費大量時間，並且會嚴重延遲昂貴的發現流程。
來自佇列的所有請求都由部署管理員處理。 它有一個特殊的工作人員從該隊列中提取任務並初始化它以開始部署。 此後，將發生以下操作：
- 由於新的確定性分配函數，每個節點獨立計算分佈。
- 節點產生包含部署結果的訊息並將其傳送給協調器。
- 協調器聚合所有訊息並產生整個部署過程的結果，該結果透過 discovery-spi 傳送到叢集中的所有節點。
- 收到結果後，部署過程結束，然後從佇列中刪除任務。
新的事件驅動設計：org.apache.ignite.internal.processors.service.IgniteServiceProcessor.java
如果在部署期間發生錯誤，節點會立即將此錯誤包含在傳送給協調器的訊息中。 訊息聚合後，協調器將獲得有關部署期間所有錯誤的訊息，並將透過 discovery-spi 發送此訊息。 錯誤訊息將在叢集中的任何節點上可用。
服務網格中的所有重要事件均使用此操作演算法進行處理。 例如，更改拓撲也是透過 discovery-spi 發送的訊息。 總的來說，與先前的協議相比，該協議相當輕量且可靠。 足以應付部署期間的任何情況。
接下來會發生什麼
現在談談計劃。 Ignite 專案的任何重大變更都是作為 Ignite 改進計劃（稱為 IEP）完成的。 服務網格重新設計還有一個 IEP - 帶有嘲諷的標題“服務網格中的石油變化”。 但實際上，我們換的不是機油，而是整個引擎。
我們將 IEP 中的任務分為兩個階段。 第一個是主要階段，包括重新設計部署協定。 它已經包含在 master 中，您可以嘗試新的 Service Grid，它將出現在 2 版本中。 第二階段包括許多其他任務：
- 熱重新部署
- 服務版本控制
- 提高容錯能力
- 瘦客戶端
- 用於監控和計算各種指標的工具
最後，我們可以為您提供服務網格的建議，以建立容錯、高可用性的系統。 我們也邀請您造訪我們的網站： и 分享您的經驗。 您的經驗對社區來說非常重要；它將幫助您了解下一步的發展方向，以及未來如何開發組件。
來源： www.habr.com