自2019年起，俄羅斯推出了強制標示法。 該法並不適用於所有商品組，且各產品組強制標示的生效日期也不同。 菸草、鞋子和藥品將首先受到強制標籤的約束；隨後將添加其他產品，例如香水、紡織品和牛奶。 這項立法創新促進了新的 IT 解決方案的開發，使追蹤產品從生產到最終消費者購買的整個生命鏈成為可能，直至流程的所有參與者：包括國家本身和所有銷售商品的組織。強制性標籤。
在X5中，追蹤貼標籤商品並與國家和供應商交換資料的系統稱為「Marcus」。 讓我們按順序告訴您它是如何開發的、由誰開發的、它的技術堆疊是什麼，以及為什麼我們有一些值得自豪的東西。
真正的高負載
「Marcus」解決了許多問題，最主要的就是X5資訊系統與貼標產品狀態資訊系統（GIS MP）整合交互，追蹤貼標產品的動向。 該平台還儲存我們收到的所有標籤代碼以及這些代碼在物體之間移動的整個歷史記錄，並有助於消除標籤產品的重新分級。 以第一組標籤商品中包含的菸草產品為例，光是一卡車香菸就包含約 600 萬包，每包都有自己獨特的代碼。 我們系統的任務是追蹤和驗證每個此類包裝在倉庫和商店之間移動的合法性，並最終驗證其向最終買家銷售的可接受性。 我們每小時記錄大約 000 筆現金交易，我們還需要記錄每個這樣的包裹是如何進入商店的。 因此，考慮到物體之間的所有運動，我們預計每年會有數百億筆記錄。
M隊
儘管 Marcus 被視為 X5 內的一個項目，但它是使用產品方法來實現的。 團隊按照 Scrum 進行工作。 該專案於去年夏天啟動，但直到十月才取得第一個成果——我們自己的團隊已完全組建完畢，系統架構已開發完畢，設備也已購買。 現在團隊有16人，其中XNUMX人參與後端和前端開發，XNUMX人參與系統分析。 另外還有六人參與手動、負載、自動化測試和產品維護。 此外，我們還有一位 SRE 專家。
我們團隊中不僅開發人員編寫程式碼；幾乎所有人員都知道如何編程和編寫自動測試、載入腳本和自動化腳本。 我們特別關注這一點，因為即使是產品支援也需要高水準的自動化。 我們總是盡力為以前沒有程式設計的同事提供建議和幫助，並給他們一些小任務來完成。
由於冠狀病毒大流行，我們將整個團隊轉移到遠端工作；所有開發管理工具的可用性以及 Jira 和 GitLab 中建立的工作流程使我們可以輕鬆通過此階段。 遠距度過的幾個月表明，團隊的生產力並沒有因此受到影響；對於許多人來說，工作的舒適度有所提高，唯一缺少的是即時溝通。
遠距團隊會議
遠距工作期間的會議
解決方案的技術棧
X5 的標準儲存庫和 CI/CD 工具是 GitLab。 我們使用它來儲存程式碼、持續測試以及部署到測試和生產伺服器。 當至少 2 位同事需要批准開發人員對程式碼所做的變更時，我們也使用程式碼審查的做法。 靜態程式碼分析器 SonarQube 和 JaCoCo 幫助我們保持程式碼整潔並確保所需的單元測試覆蓋率等級。 對程式碼的所有變更都必須經過這些檢查。 所有手動執行的測試腳本隨後都會自動化。
為了成功實施「Marcus」的業務流程，我們必須依序解決許多技術問題。
任務1.系統水平可擴展性的需求
為了解決這個問題，我們選擇了微服務架構方法。 同時，了解服務的職責範圍也非常重要。 我們嘗試將它們劃分為業務運營，同時考慮流程的具體情況。 例如，倉庫的收貨不是很頻繁，但是規模很大，需要從國家監管機構快速獲取所收貨物的單位信息，一次發貨的數量達到600000萬件。 ，檢查是否可以接受該產品進入倉庫，並返回倉庫自動化系統的所有必要資訊。 但倉庫出貨的強度要大得多，但同時資料量卻很小。
我們在無狀態的基礎上實現所有服務，甚至嘗試將內部操作劃分為步驟，使用我們所謂的 Kafka 自主題。 這是微服務向自身發送訊息的情況，這使您可以平衡資源密集型操作的負載並簡化產品維護，稍後會詳細介紹。
我們決定將與外部系統互動的模組分成單獨的服務。 這使得解決外部系統API頻繁變化的問題成為可能，並且對具有業務功能的服務幾乎沒有影響。
所有微服務都部署在OpenShift叢集中，這不僅解決了每個微服務的擴充問題，也允許我們不使用第三方服務發現工具。
任務2.需要在平台服務之間維持高負載和非常密集的資料交換： 僅在專案啟動階段，每秒執行約 600 次操作。 隨著零售店連接到我們的平台，我們預計該值將增加到 5000 次操作/秒。
透過部署Kafka叢集並幾乎完全放棄平台微服務之間的同步互動來解決這個問題。 這需要對系統需求進行非常仔細的分析，因為並非所有操作都可以是非同步的。 同時，我們不僅透過broker傳輸事件，還在訊息中傳輸所有需要的業務資訊。 因此，訊息大小可以達到數百KB。 Kafka中的訊息大小限制要求我們準確預測訊息大小，必要時我們進行劃分，但劃分是邏輯性的，與業務操作相關。
例如，我們將汽車到達的貨物分成箱子。 對於同步操作，請分配單獨的微服務並進行徹底的負載測試。 使用 Kafka 為我們帶來了另一個挑戰 - 測試我們服務的操作，同時考慮到 Kafka 整合使我們所有的單元測試都是非同步的。 我們透過使用嵌入式 Kafka Broker 編寫自己的實用方法解決了這個問題。 這並不能消除為單一方法編寫單元測試的需要，但我們更喜歡使用 Kafka 測試複雜的情況。
我們非常關注追蹤日誌，以便在服務運行過程中或使用 Kafka 批次時發生異常時，其 TraceId 不會遺失。 如果第一個沒有特殊問題，那麼在第二種情況下，我們被迫記錄該批次附帶的所有 TraceId，並選擇一個繼續追蹤。 然後，當使用者透過原始TraceId進行搜尋時，就可以輕鬆找到追蹤是從哪一個繼續進行的。
任務3.需要儲存大量資料： 每年僅菸草標籤就有超過 1 億個標籤來到 X5。 他們需要持續且快速的訪問。 總的來說，系統必須處理大約 10 億筆帶有標籤的商品的移動歷史記錄。
為了解決第三個問題，選擇了NoSQL資料庫MongoDB。 我們建立了一個包含 5 個節點的分片，每個節點都有一個包含 3 個伺服器的副本集。 這允許您水平擴展系統，向叢集添加新伺服器，並確保其容錯能力。 這裡我們遇到了另一個問題——確保mongo叢集中的事務性，同時考慮到使用水平可擴展的微服務。 例如，我們系統的任務之一是識別使用相同標籤代碼轉售產品的嘗試。 在這裡，疊加出現了錯誤的掃描或收銀員的錯誤操作。 我們發現此類重複項既可能發生在正在處理的一個 Kafka 批次內，也可能發生在並行處理的兩個批次內。 因此，透過查詢資料庫檢查重複項沒有給出任何結果。 對於每個微服務，我們根據該服務的業務邏輯分別解決問題。 例如，對於檢查，我們在批次中新增了檢查，並在插入時單獨處理重複項的出現。
為了確保使用者對營運歷史的處理不會以任何方式影響最重要的事情 - 我們的業務流程的運行，我們將所有歷史資料分離到具有單獨資料庫的單獨服務中，該服務也透過 Kafka 接收資訊。 這樣，使用者可以使用獨立的服務，而不會影響處理正在進行的作業的資料的服務。
任務4：隊列重新處理和監控：
在分散式系統中，資料庫、佇列和外部資料來源的可用性不可避免地會出現問題和錯誤。 就 Marcus 而言，此類錯誤的根源在於與外部系統的整合。 有必要找到一種解決方案，允許在指定的逾時時間內重複請求錯誤回應，但同時不停止在主佇列中處理成功的請求。 為此，選擇了所謂的「基於主題的重試」概念。 對於每個主要主題，建立一個或多個重試主題，將錯誤訊息傳送到這些重試主題，同時消除處理來自主要主題的訊息的延遲。 互動方案-
為了實現這樣的方案，我們需要：將這個解決方案與Spring整合並避免程式碼重複。 在網路上衝浪時，我們遇到了一個基於 Spring BeanPostProccessor 的類似解決方案，但它對我們來說似乎不必要的麻煩。 我們的團隊制定了一個更簡單的解決方案，使我們能夠整合到 Spring 週期中來創建消費者，並另外添加重試消費者。 我們向 Spring 團隊提供了我們解決方案的原型，您可以看到它 。 重試消費者的數量和每個消費者的嘗試次數是透過參數配置的，取決於業務流程的需求，要讓一切正常工作，剩下的就是添加註解 org.springframework.kafka.annotation.KafkaListener ，這是所有Spring 開發人員都熟悉的。
如果在所有重試嘗試後仍無法處理訊息，則會使用 Spring DeadLetterPublishingRecoverer 前往 DLT（死信主題）。 應支援請求，我們擴展了此功能並建立了一個單獨的服務，讓您可以查看 DLT、stackTrace、traceId 中包含的訊息以及有關它們的其他有用資訊。 此外，所有 DLT 主題都添加了監控和警報，事實上，現在 DLT 主題中出現訊息是分析和修復缺陷的原因。 這非常方便——透過主題的名稱，我們立即了解問題是在流程的哪一步出現的，這顯著加快了尋找其根本原因的速度。
最近，我們實作了一個接口，讓我們在消除訊息原因（例如，恢復外部系統的功能）後使用我們的支援重新發送訊息，當然，還可以建立相應的缺陷進行分析。 這就是我們的自我主題派上用場的地方：為了不重新啟動長處理鏈，您可以從所需的步驟重新啟動它。
平台營運
該平台已經投入生產運營，我們每天都進行送貨和裝運，連接新的配送中心和商店。 作為試點的一部分，該系統與「菸草」和「鞋子」產品組合作。
我們的整個團隊參與試點，分析新出現的問題，並提出改進我們產品的建議，從改進日誌到改變流程。
為了不重蹈覆轍，試點期間發現的所有案例都反映在自動化測試中。 大量自動測試和單元測試的存在使您可以在幾個小時內進行回歸測試並安裝修補程式。
現在我們不斷開發和完善我們的平台，不斷面對新的挑戰。 如果您有興趣，我們將在接下來的文章中討論我們的解決方案。
來源： www.habr.com