有效的溝通非常重要
下面將描述一下今天發生的案例。
這些日子客戶端開發和測試人員反饋，APP程序經常跳轉到登錄頁面。從他們的描述中我一直以爲都是Session Token過期造成。
服務器是這樣設計的：
服務器提供維護Token和websocket之間的關係。
token 生成和 websoket連接建立不區分先後順序。
但websocket一旦斷開，就會清空session和token
這裏存在一個問題，每次打開APP，APP會記住上次打開頁面，並實現自動登錄。如果這個頁面有好多API請求返回的數據組成，那麼同一時刻，可能發起好多HTTP請求,這些API都會返回Token無效。 就會發起HTTP登錄請求。這樣就會返回多個token,其實這裏完全可以忽略，因爲websocket只建立一次，只管把每次的返回token通過websocket發送到服務器即可。
(client) (server)
| |
|-------http request -------------------> |
| | 生成token並返回給客戶端，
| | 以後客戶需要用此token表示身份
|-------http request2-------------------> | 並通過websocket發送到服務器來建立關聯
| |
| |
|<------- response1--------------------- |
| |
| |
|<------- response2--------------------- |
| ｜
|
按照以上原則是沒有問題的。
事實客戶端請求時沒有遵循以上原則，比如建立了多次websocket連接。
客戶端曾反饋過，說請求死循環，我一直以爲是這裏的http請求出現死循環。當時也許是他們沒有說清楚，也許是我自己以爲，但我應該繼續追問（在實際工作中，繼續追問常常會惹人厭煩的）。
仔細覈對客戶端提供的日誌，發現日誌中出現大量relogin信息，並且都是1s後又繼續嘗試登錄。登錄超過規定次數後，客戶端會把原先緩存在手機中的密碼和用戶名清空的。這時候就會出現類手動似註銷效果，跳轉到登錄頁面。
這裏的重複登錄其實就應該是客戶端人員反饋的死循環請求問題。
同樣的問題，測試人員反饋的是應用程序總是自動註銷。
看到relogin日誌後，很明顯是因爲第一次自動登錄API，請求後一直沒有返回數據造成的應用程序自動註銷的假象。
分析到這裏，問題定位在登錄API上了。
要麼客戶端的請求服務器沒有收到，例如斷網的情況下（相信客戶端人員會處理過此情況），
要麼服務起相應客戶端的時間超過了服務器的等待時間，如果是這樣，這個API存在大缺陷。
問題到這裏大家該幹嘛的幹嘛了，看來我先前說在下個版本分離token和websocket 說的過早了，惹禍上身。
眼看快下班了，討論的那些方案個人感覺不靠普。在各方壓力之下，我只好放棄先前的設計，取消了斷開websocket清空session token功能。這樣當然會引起其他問題的。比如：無用的token是否越來越多，一個用戶多個設備登錄問題等等，怎麼去實現等等。 之前都已經考慮過，才採取斷開websocket清空的。當下沒那麼多時間去考慮了，什麼樣的要求，就有什麼樣的結果。再說了架構馬上又要變了，重構後自然就沒這問題了。 只是......
該洗洗睡了。