對於生活中的計算機系統進行分析 --- 1. 卡拉OK系統

系統表現：

通過掃描一個二維碼進行點歌，通過微信進行登錄，進行搜索點歌。

結構猜測：

通過掃描二維碼打開一個http鏈接 https://www.999inandon.com/ktv/weixinpl/common_shop/jiushop/forward.php?type=soundKingIndex&customer_id=41&batch=090910322635_1632223383&mark=1&version=1&connCode=c0a8008f 該鏈接要求必須通過微信打開，打開后進行點歌。

通過搜索可知，微信打開的判斷方法來自微信內置UserAgent字段的設置。

通過分析HTTP請求可知1632223383是當前時間戳，所以這個信息是一個有時效性的信息.

第二次掃描其內容為: https://www.999inandon.com/ktv/weixinpl/common_shop/jiushop/forward.php?type=soundKingIndex&customer_id=41&batch=090910322635_1632223383&mark=1&version=1&connCode=c0a8008f 發現內容並沒有發生改變, 考慮到該系統在該段時間並沒有進行關機(只是關閉了顯示), 所以該二維碼可能是每次開機時進行刷新

分析其可能的結構:

1. 以中央服務器的方式搜集用戶的點歌信息，將其下發到各個點歌客戶端，對於用戶端的配對方式應該通過客戶端的主動通知。由於已知url中的batch字段中有一個內容是用戶點歌端開機的時間戳。所以可以認為這個是主要的客戶端定位信息。由於想到如果客戶端使用靜態batch地址可以導致用戶在不在場的情況之下連入選歌客戶端，導致選歌功能錯誤。所以這里有幾種方式進行動態定位
   1. 通過用戶端發送聯網請求給中央服務器，服務器返回注冊成功消息，並返回一個對應id
   2. 通過預定義的隨機生成算法，根據實際的時間生成對應的batch id。進行服務器通信的時候只進行通知以及告知當前地址。 -- 仔細思考這個相關設計有問題。因為如果通知了中心服務器則服務器就開始服務雖然可以減少服務器進行授權的消耗，但是如果有人冒充客戶端發送對應的請求授權信息，會導致服務器為無權限對象進行服務。導致服務被冒用的風險
   3. 關於這里的設計邏輯,應該是需要結合上面的兩個技術 -- 需要能夠通過batchid獲取終端id因為需要通過終端id才能知道對應id節點使用的曲庫是否為最新曲庫 -- 關於這一點可以通過曲目庫的更新版本號進行同步. 同步當前系統中運行的曲庫的最后更新版本. 客戶端通過自動將后續增量更新進行推送進行終端曲目的更新.
   4. 這里的兩個服務請求(服務端注冊和曲庫推送)有沒有可能是分開的 -- 可能,因為這樣可以較為方便的進行失敗重試 -- 例如接受曲目更新失效的時候不需要進行重新登記

通過以上的通信方案使得在中心服務器端可以生成一個batch id和客戶端地址的對應表，每個使用某個batch_id訪問的http請求都被處理為對應客戶端的點歌請求。

2. 關於點歌服務的方案：

   1. 在客戶端開機的時候進行全局歌曲列表的同步（可以通過增量同步而不是全量同步來減少需要傳輸的信息量）--- 歌曲列表的形象是歌曲網絡資源鏈接和歌曲名的對應關系，需要兼顧通過終端不通過在線的方式進行點歌(所以對於熱門歌曲等內容有硬盤存儲架構)，每次有人點歌之后都通過中央服務器下傳一個點歌id和用戶id的對應關系。
   2. 本來我有想法是關於使用局域網的形式進行通訊 -- 但是這會導致一個問題：雖然在大多數環境下都是通過wifi進行連接的，但是在很多時候尤其是在公開場合更多的使用流量進行通信。這種情況下進行局域網的通信會導致服務端無法連接。 所以在更加一般的場景中使用局域網的服務器的應用是受到了限制的

3. 推測的服務端的接口功能:

   1. 進行終端回調登記的接口 -- 將batch_id與用戶選歌信息的回調接口進行綁定
   2. 根據終端上傳的最終曲庫版本號進行曲庫更新推送的接口 -- 進行增量更新減少對於網絡的依賴.
   3. 歌曲文件下載服務接口 -- 可能通過某種形式進行加密,然后進行歌曲的下載. 將加載服務器和授權服務器分離, 減少授權服務的性能消耗