【前戲】
最近遇到客戶需要建設#數據中臺#，
#數據倉庫#也缺少維護，需要我們構建一個方案來對原有系統的結構做梳理。改成完成後需要接入到我們的互聯網數據系統中，打造內外數據輿情繫統，形成對行業、競爭對手、國家政策、內部經營的全方位監測的#競爭情報#大數據##。
大數據系統架構
一、建設目標
1、使用技術的手段快速對系統的業務流做出整理
2、通過技術手段整理的業務流，協助開發人員對業務系統的瞭解，達到節省時間和人力的投入的目標
3、為後期微服務化的改造提供條件
4、輸出一份系統業務流向的接口文檔和系統使用情況分析
二、概述
依據建設目標，本設計方案將會實現兩個具體的原系統分析結果：
1、將原系統作為一大的“邏輯處理器”，原有系統不做更改，只提取業務流向的數據接口，將提取的若干接口可以再次組裝，形成一個單獨的服務，為微服務化提供的實現提供基礎。
2、在第一個分析結果的基礎上更進一步，分析源代碼後，形成完整的系統設計文檔，在此基礎上可以對業務需求更進一步的瞭解，不管是對現有系統的改造還是抽取原系統業務功能後微服務化都將提供便利。
三、解耦思路
從軟件設計和開發的角度上來說，一個完整的系統包含若干子系統，一個子系統又是由若干功能點組成，同時子系統和子系統直之間有交集，交集是通過功能點來實現。系統和功能點在數據結構上體現是每個功能點對應的數據表來實現存儲和交互，功能點與功能點之間是通過數據庫直接的關聯關係來實現關聯。
通過數據流來體現業務流程，從用戶點擊開始，中間業務邏輯處理以及最終的結果展現。也就是說，業務流程的開始和終結我們在頁面上能直接看到，中間業務邏輯處理需要對代碼的技術上手段來實現瞭解。
總結，通過數據流瞭解業務功能點的開始和總結，通過功能點的代碼模塊瞭解具體的處理邏輯。具體步驟如下：
1）業務流向探測
1、建立流量流向沙盒
為減少侵入性，不影響用戶的使用，通過中間人代理的方式攔截用戶操作的數據量，截取調用的接口、傳入的參數以及返回的結果，存儲業務流向監測的數據表中。這種方式，普通用戶無感知，也不會影響其日常的工作，也能夠獲得真實的使用數據和業務使用熱度。在對業務分析也能有所重點。
2、沙盒輸出
輸出接口名稱(英文)、參數、業務名稱、功能點以及人工完善具體的業務功能和系統的名稱，如下：
接口清單
此階段，可以將系統的業務邏輯流向，監測完成後形成系統的接口文檔。也能解決在不瞭解具體業務邏輯的情況下，實現一定程度上的解耦，也就是說原有系統只做一個超大的業務處理邏輯系統。我們可以再次對產出的接口形成再組合為一個小系統，為解耦提供支持。
2）業務邏輯分析
業務邏輯分析在沒有設計文檔的情況下只能通過先了解業務流程，重點梳理流程中處理環節。在沒有源代碼的情況下，對業務瞭解機器也很難做到，所以業務邏輯的分析讓機器能夠做一些瞭解，需要源代碼。從代碼層面對業務系統的瞭解分三步走：
第一步：定位接口業務實現代碼塊
通過接口定位源代碼中的代碼塊。目前系統主流開發語言是java、php、asp.net，每一種方式通過接口定位代碼塊的方式不同，如java，通過在方法體上加入註解即可定位代碼塊。針對具體系統採用的開發語言需要有不同的策略。
此階段將會輸出具體的源代碼文件名稱、路徑以及具體的方法名稱，補充到接口文檔中。
第二步：解析代碼並生成類繼承關係圖
1、識別其他項目的接口調用
這類可以通過代碼分析得到，技術上是可以實現，判斷的依據是調用的請求是http請求還是代碼內部請求。
2、內部調用關係
不管java、asp.net還是php，都具備面向對象，方法體內基本上是與數據庫交互和邏輯判斷兩個過程。邏輯判斷的過程最好的方式是用人工來判斷。數據庫的交互是可以用機器的方式來實現識別，並且延伸到對具體哪些數據庫表。
輸出：數據表結構以及數據樣例
第三步：檢驗分析的業務邏輯是否正確
1、將系統和數據庫複製一份到新的運行環境。
2、根據接口文檔建立測試用例庫，模擬真實用戶日常的業務操作和數據。
3、用自動化測試工具來實現測試用戶，觀測測試結果是否和正式運行系統處理過的數據是一致。
4、輸出每個測試用例以及接口調用是否正確的文檔
四、最終輸出樣例
業務數據流向系統運行自動執行分析，完整分析後，系統形成初步的接口文檔word和業務系統使用情況的兩份文檔，可以由人工來完善。業務系統使用情況可以為業務遷移或者升級提供參考，可以有重點、有順序的計劃執行。如下使用“互聯網+大客流數據應用平臺”舉例：
業務系統使用狀態分析：
PV：每天/周打開系統次數
UV：每天/周有多少實際操作的用戶數量
此文檔可以提供對現有系統的使用情況做了解，如果原有系統有10個子系統，我們分析出來後只有2-3個系統經常和平凡的使用，那麼就針對這2-3個的系統做業務需求的瞭解和微服務化的改造，可以做到有的放矢，省時省力。
接口文檔舉例：
1、區域熱力
1.1接口描述
【人工填寫】
1.2請求說明
1.3參數說明
系統羅列參數名稱，參數是否必填有系統來檢測，系統會迭代參數，如請求需要5個參數，那麼系統就會請求25次，來判斷哪些參數是必填，以及每次請求出現的問題做記錄。人工補充參數說明。
1.4返回值說明
返回結果在機器無法識別的情況下，由人工識別填充。
1.5對應代碼位置
輸出點所在的路徑，如
路徑：com/szga/buz/getPoiCategoryList.php
位置：123行
1.6調用外部接口
系統判斷如果存在外部調用接口則會羅列出
接口地址
http://192.168.1.xxx/szga/abc
http://192.168.1.xxxx/szga/def
1.7數據結構關係圖
功能點涉及到的數據表以及抽取數據表中若干數據作為樣本，不足之處可以由人工滿足，如圖：
