說到資料上報，很多人第一印象是直接點對點的上報資料，優點是簡單直接省事，但是缺點很明顯，侵入性太強，業務中會摻雜很多非業務的事情，當然這里的簡單省事是短暫的，如果業務以及開發完了，后面追加資料上報功能，再按照這個模式，將帶來空前的壓力，代碼基本上要重新寫、測驗，這個任務量也許會很大，因為一時的省事為以后埋下大坑，這個是做研發要極力避免的、不能容忍的，此時我們要做的事是如何解耦，將非業務性功能提取出來，做成一個統一的資料上報平臺，因此我們就有了下文的技術方案，
系統設計架構圖：
圖示：關于技術選型，a、b、c都是基于springcloud，資料存盤我們選擇Elasticsearch，訊息中間件使用kafka，
上圖的業務是將a服務的資料上報到d服務，按照一般的流程我們可以直接將a服務的資料直接發送到d服務，這樣的好處是簡單，但是缺點顯而易見，侵入性、耦合性太強，這不是我們想要的，我們要將與業務無關的服務剝離出來，做成一個統一的資料上報中心也就是上圖中的b服務，在這個服務中只做一件事，那就是業務資料上報，而此時的a服務只管專心的做業務，無需關心其它，二者各司其職，互不影響，做到真正的業務分離，
此時b服務的上報資料從哪兒來，a服務直接發給b服務？很明顯不是，如果這樣做和a服務點對點發送到d服務有什么區別呢，反而增加了一個中間環節，增加了不穩定因素，那我們該怎么做？想一想，多個程式如何進行訊息傳遞？此時我們會想到訊息中間件這個很神奇的一個東西，網上搜索一大堆訊息中間件，那么我們該如何選擇呢？我們這里選擇的是kafka，原因是我們這里的資料量大、生態環境非常好，實時資料處理比較好，而且我們之前已經在使用它了，在滿足業務的情況下，沒有必要再額外的維護一個中間件，我們要本著業務、經濟的原則去技術選型，不要為了技術而技術，
在上報資料的時候我們還得考慮很多問題：
1.上報資料日志監控
我們這里的日志量很大，而且需要各種維度的日志分析這個功能，因此日志存盤我們采用Elasticsearch，
它是一個分布式搜索引擎，支持海量資料存盤，檢索查詢，在這里使用它再適合不過，
2.資料丟失，比如服務d宕機、網路堵塞原因會導致上報資料丟失（在a、b服務正常的情況下），那么如何解決這個？由于我們做了日志監控，所以會很簡單的解決這個問題，將上報例外的資料重新發送就好了，
使用場景：
本架構使用在互聯網醫院專案中，業務是衛健委要求醫院上報在線看病患者產生的資料,且上報資料不允許丟失，如果對方平臺無法使用，則要求補發丟失資料，
a對應醫院在線看病服務，d對應衛健委資料接收服務，b、c就是內部非業務服務，
最后總結核心點，我們要將業務和非業務相關的東西剝離開來，各司其職，互不影響，這正符合現在流行的微服務理念，
推薦閱讀：
【大廠】基于rabbitMQ訊息中心技術方案
【干貨】一篇文章講透資料挖掘
【干貨】微服務設計的基礎知識【對話老王】聊聊那資料
【輕松話題】閑話程式員
【劃劃重點】論大資料中主資料的重要性
【談大資料】CDH6.x學習筆記（角色簡介）
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/19659.html
標籤：設計模式
上一篇：編程思想：巧用位運算重構代碼
下一篇：圖解Java設計模式之組合模式