說到數據上報，很多人第一印象是直接點對點的上報數據，優點是簡單直接省事，但是缺點很明顯，侵入性太強，業務中會摻雜很多非業務的事情。當然這里的簡單省事是短暫的，如果業務以及開發完了，后面追加數據上報功能，再按照這個模式，將帶來空前的壓力，代碼基本上要重新寫、測試。這個任務量也許會很大，因為一時的省事為以后埋下大坑，這個是做研發要極力避免的、不能容忍的。此時我們要做的事是如何解耦，將非業務性功能提取出來，做成一個統一的數據上報平台。因此我們就有了下文的技術方案。
系統設計架構圖：
圖示：關於技術選型，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學習筆記（角色簡介）