公司業務各方面展開，要新上多個平臺。需要不同域名的多個平臺可以共享登陸狀態。準確得說，就是需要一賬通平臺

現狀：海銀會（非標固收）與海銀財富（公募基金）兩個數據庫、海銀會平臺一套系統

1.單點登錄實現方案。

有兩種技術方案：

1）A網站和B網站，登陸都跳C網站，C網站登陸後帶著token返回A、B網站的相關頁面。A、B網站將token存放到cookie中去並建立相關session。

2）A網站登陸，B網站、C網站都通過jsonp跨域取所有相關網站的cookie值獲得token與登陸信息

結論：方案二從用戶體驗上更好，但是跨域的安全性不了解不確定。偏向於選擇方案一

2.方案一，多平臺登錄問題解決了，但是多平臺登錄後都有本地session，一個平臺登出，另一個平臺也要登出怎麽實現

有兩種技術方案：

1）每次業務請求都額外請求一次B網站的服務，檢查登錄狀態，是否為登出

2）在一個平臺登出後，B網站負責像所有其他平臺推送用戶登出消息

結論：方案二不影響業務交易的性能，但是需要額外的基礎架構建設（比如MQ等），時間緊迫。選擇實現簡單的方案一

3.一賬通是僅實現會員管理，還是包括銀行卡管理，資金管理等

一方意見：僅實現會員管理，多平臺登錄，實現簡單，沒必要把資金納入到一賬通中去。

另一方意見：將資金納入一賬通有一個好處，賬戶內金額可以跨平臺使用可以更方便實現，畢竟是在一個系統內；如果卡由業務系統自行維護，則可能同一用戶同一卡被驗證多次，將銀行卡管理納入到一賬通中的好處是，卡的鑒權驗證只需做一次，節省成本。

結論：將銀行卡管理及資金管理納入一賬通平臺。邏輯上一賬通一個整體，但其實可以切分成三個服務或三個微服務群

4.會員模型是怎麽樣的

結論：一個客戶（以身份證為唯一識別）——>(1:n)——>平臺用戶(客戶+平臺)——>(1:n)——>錢包賬戶、臨時賬戶、活動賬戶

5.銀行卡管理做到什麽程度？僅卡片信息？還是包含綁/解卡？

結論：

（1）為了同卡只驗證一次，綁卡驗證應該在一賬通處理。

（2）綁卡與業務平臺相關，一卡可以綁多個業務平臺。一個業務平臺也可以綁多個卡。

（3）需支持對業務平臺進行解綁卡操作。

（4）對一賬通平臺進行解綁卡操作的話，需要檢查該卡與所有業務平臺均已解綁才可以解綁。

（5）一賬通平臺只負責維護卡與業務員平臺的綁定關系。業務平臺內多個業務與卡的簽約關系由業務平臺自行維護

6.銀行卡管理模型是怎樣的

結論：一個客戶（以身份證為唯一識別）——>(1:n)——>銀行卡——>(n:n)——>業務平臺主簽約

7.一賬通平臺是重新搭建還是改造原用戶服務ucs-service

結論：原ucs-service除了用戶服務還有其他功能，切分麻煩。另原用戶模型為一客戶一用戶，整體控制都是以此為基礎。建議重新開發一賬通平臺會員管理服務

8.資金管理平臺是重新搭建還是改造原錢包服務wallet-service

結論：原wallet-service服務切分得比較合理，根據當前表結構及系統處理邏輯評估。改造原錢包服務，增加平臺相關字段，為所有業務平臺的統一資金服務

9.用戶數據以海銀會的庫為基準，一賬通會員管理連的也是海銀會的庫還是使用新建庫

結論：從微服務的理念上來說，應該是一個服務一個庫。且鑒於用用戶庫結構不清晰，預期將就改造，不如新建一個，大不了進行數據遷移。以舊模型強行承接新業務，不如以舊數據改造適配新模型。

10.原海銀會業務與用戶在同一個庫裏，有很多聯表操作。分庫後怎麽處理

結論：原聯表需求分為兩類：與交易相關的以及報表相關的

與交易相關的如用戶角色，用戶權限等，有個特征，僅與用戶個人相關，可通過服務調用直接獲取單個用戶相關信息。

而報表可能同時需要大量用戶的信息，不管是多次調用單個用戶信息服務還是批量調用，都不是很合適。從修改的工作量來看，也是非常大。所有聯表的SQL語句及處理代碼都要改動。代價太大。選擇原庫存放冗余數據，數據定時從一賬通數據庫同步至原庫。

11.如果采用數據延遲同步的方式。在延遲階段會有什麽問題嗎。

結論：只有查詢報表類，會存在數據延遲的問題。如果有業務數據存在用戶id，但用戶相關信息沒有同步過來時。如果連接方式采用LEFT JOIN，則結果可以查到相關交易數據，但是用戶名等信息為空。如果連接方式采用INNER JOIN方式，則無法查到交易數據。這點需與業務方確認

12.如果業務方要求有些業務查詢，必須準實時，不能有延遲，怎麽實現

結論：大部分查詢報表需求都應該可以接受十分鐘，半小時甚至更長時間的延遲。可以采用定時增量同步的方式進行同步。如果實在有準實時查詢需求，可以采用用戶註冊時同時推送的設計，準實時將新增用戶信息推送到業務系統

13.會員庫為新建庫。那資金庫是否需要新建？

結論：新建會員庫的一大原因是，新建的會員庫與原用戶庫相差巨大。所以選擇新建。而改造後的資金庫與新模型資金庫是一樣的。改造完原庫，即為最終目標狀態。現在遷移及將來遷移的成本是一樣的。在當前項目時間緊迫的前提下，選擇不遷移。直接使用原庫，來減少wallet-service的改造量。等將來有時間再改造遷移

14.移動端是否要和PC打通，實現單點登錄？

結論：比如PC登錄了A網站，然後B網站的APP就自動登錄了。總感覺用戶體驗怪怪的。而且貌似沒有簡單的解決方案，所以不實現該功能

15.那移動端的登錄狀態是由一賬通處理還是業務系統自行處理

一方意見：移動端登錄狀態與一賬通登錄狀態不共享，且失效時間不同。PC端一般為15分鐘，移動端為60天。應由業務系統自行處理維護

另一方意見：同樣是會員登陸，PC選擇一賬通，而移動端由業務系統維護。對於業務系統來說，業務切割不幹凈。要麽就由業務系統統一維護，要麽由一賬通統一管理。一半一半不合理

結論：如果移動端登陸管理由各個業務系統自行維護，其代碼其實是可以復用的，只是配置時間不同。既然代碼可以復用不如抽出來作用一賬通服務的一部分，提供給所有業務系統。所以需要在原設計基礎上添加終端字段

16.現在有兩個庫的用戶，進行數據合並的時候，如果同一個用戶（同一個身份證號）在兩個平臺的用戶名，密碼不同，怎麽處理

方案一：通通以一個平臺為準，用戶名、密碼、手機號。出現沖突則以一個平臺為準。等提供手機號，身份證，用戶名，郵箱等多種登陸方式。一賬通平臺上線後，提示使用海銀會的用戶名密碼登陸。海銀財富的用戶名密碼將失效。如果不記得海銀會用戶名，可用身份證號或手機號登陸

方案二：表中建四列相關字段。平臺1用戶名、平臺1密碼、平臺2用戶名、平臺2密碼。一賬通上線後新用戶用戶名密碼記錄在“平臺1用戶名”及“平臺1密碼”。原老用戶可以用兩種平臺用戶名密碼組登陸。如 select …… from …… where (平臺1用戶名 = ‘AAA‘ and 平臺1密碼 = ‘BBB’) OR (平臺2用戶名 = ‘AAA‘ and 平臺2密碼 = ‘CCC’)

結論：鑒於平臺2現在只有密文，需要額外的工作去了解平臺2密碼的加密方式。並且每一次登陸都要將收到的密碼明文按照兩種不同方式加密，浪費性能。且方案一提供多種方式登陸，應該可以覆蓋所有用戶

17.海銀會目前調用采用的是hessian直連方式。新項目想使用SpringCloud，采用怎麽的方案？

方案一：原系統移植為SpringBoot應用。采用feign的方式進行調用

方案二：新項目繼續使用原本的框架，采用原來的hessian直連的調用方式

結論：鑒於SpringCloud大行其道，轉型意願強烈。一賬通平臺為新建重造的應用，非常適合直接使用SpringBoot及Springcloud。則采用如下方案：

當前系統架構：

過渡SpringCloud系統架構

僅改動原core包中提供遠程調用的方法sendRemoteRequest。方法中對調用的目的進行判斷，一賬通相關業務路由至SpringCloud的Zuul網關，由Zuul來做負載均衡分發。其他調用走原本Hessian直連方式。這樣所有業務系統都可以不作代碼變更，只需重新編譯部署就可以了。等將來將原有系統一點點往SpringBoot移植

工作小記——一賬通平臺設計分析及結果