公司業務各方面展開，要新上多個平台。需要不同網域名稱的多個平台可以共享登陸狀態。準確得說，就是需要一賬通平台
現狀：海銀會（非標固收）與海銀財富（公募**）兩個資料庫、海銀會平台一套系統
1.單點登入實現方案。
有兩種技術方案：
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打通，實現單點登入？
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移植
IoT 一 物聯網平台架構設計分析
裝置管理 裝置管理定義裝置相關資訊，每個裝置必須定義其裝置型別，裝置型別有使用者屬性，裝置在完成銷售，並被使用者啟用後裝置就屬於裝置使用者了，這時候裝置使用者對裝置有完全的控制權，可以控制裝置的哪些資料可以被製造商檢視，可以被哪些使用者檢視等許可權 使用者管理 使用者是基於乙個組織下的人員構成，每個...
我的平台型產品設計分析缺了什麼
最近在策劃推進乙個平台型產品核心操作鏈路的整體設計優化，因為之前覺得pd 產品經理 提乙個需求 我補乙個場景的工作模式太過碎片化，很容易失去全域性視野 並有讓鏈路變得越來越複雜和難以擴充套件的危險。和pd不約而同地意識到這個問題之後，我們基於使用者調研反饋共同做了一次體驗地圖，發現存在大量的體驗問題...
雙向迴圈鍊錶設計分析之一
include include include typedef char d char typedef int d int typedef struct d list d list struct d list typedef struct d student 巨集定義塊開始 define d mac...