公司业务各方面展开，要新上多个平台。需要不同域名的多个平台可以共享登陆状态。准确得说，就是需要一账通平台

现状：海银会（非标固收）与海银财富（公募基金）两个数据库、海银会平台一套系统

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移植