多系统架构设计思考

第一个考虑的情况是下游有很多应用系统。

这种方式假定用户在平台里拥有一个唯一的id，其在各个系统中的访问权限需要进行配置，权限是在什么时候分配的？
用户第一次注册平台的时候，需要生产其默认权限(全平台默认权限)，当其注册完成首次登录某个平台A的时候可能需要获取一些个人的信息，这时候平台A应该如何获取这些必要的个人信息？当某些信息被更新了，平台A可能也需要获得更新的信息，这时候他该如何获得这些信息？所以仅仅是用户登录更新信息就可能引发并发问题。所以应该采用主动通知的方式，当某个用户注册/中心系统更新个人信息则将该用户的信息往其他系统进行推送更新，当所有系统需要对用户主信息更新的时候统一调用某个中心端信息更新接口。
可以用rabitMq来叙述这些思想：

为了避免修改服务器的压力，可以考虑对于中心信息的修改设置修改时间限定或者修改频率限制，目前看微信、豆瓣、csdn之类的重要信息的修改他们都有时限限制或者次数限制，不知道他们是出于什么考虑的。
当用户登录的时候，不仅仅涉及到登录密码的验证，同时还涉及到登录权限的返回，以方便前端根据不同的权限显示界面模块。
假设某个用户试图访问平台A，但是该用户在平台A上没有登录过，则会跳转至登录页面，跳转的时候我们可以将某个隐藏参数param1带往登录页面，当用户登录的时候在查询权限的时候根据param1来返回用户在平台A上的权限列表，然后通过重定向定位到对应的页面，这样平台A的登录功能就完成了。

因为该系统的权限中心是一个中心，所以可以实现类似于sso的单点登录功能。
从这个设计架构来看，从单体往多系统演化的时候需要在设计初期就将用户权限数据库和业务数据库相分离，目前系统还没有引入日志的功能，可以考虑如下方式引入。

可以将日志数据表都设置为一类数据表，这种方式可以通过引入日志模块来实现代码的复用，同时对于日志的查询系统也可以采用代码复用的方式来查看操作日志。也许还可以换一种方式来生成和处理日志。

所有系统的日志操作都按照一定的格式发送到某个队列中，然后由日志处理系统统一将日志信息记录到某类数据库中，日志处理系统可以根据不同的系统来区分查询日志。
我认为前期单体架构设计数据库日志的时候可以多参考一些日志平台收集日志的必备字段来进行设计，这样为以后往日志平台的转换提供方便。

以上为低并发多系统架构的思考，接下来思考多并发多系统架构。
顾名思义就是说，应用本身还要进行应用拆分，鉴权前移也可以算是应用拆分。
单从架构上来看，鉴权中心也会成为系统瓶颈，这时候可以从访问不同系统的角度入手，不同的系统有一个与之对应的鉴权中心，架构图可以演变为如下的样子。

如果仍然有瓶颈，则可以考虑根据不同的用户id映射到不同的数据表中，即对表进行横向拆分。
通过以上我有这样的一个想法，可以将用户信息表、权限相关表、业务相关表、日志相关表进行拆分，这样完整的权限模块的代码在以后的所有项目中均可以实现完全复用(因为用户权限完全可以只通过用户id和其他关联表进行定位)，如果能够足够的抽象，用户信息表实际上也可以做到完全抽象，例如只存放用户id、用户姓名、用户身份证号、用户电话、用户邮箱之类的信息。
这样鉴权压力可以缓解掉，接下来是下游系统如果高并发应该怎么处理？
如果访问量比较低的情况下，我们可以通过数据表加乐观锁的方式来解决数据一致性的问题，但是在并发情况下，mysql因为事务的原因会成为系统瓶颈，这时候应该如何处理？
1)使用redis锁机制，具体流程如下所示

我的构想是有两个字段，一个用于存放在销售出的数量变量A，另一个用于存放实际数量B。两个字段分别加锁，在用户下单情况下，只观察变量A，确保变量A的原子性，在消减数据时，需要修改数据B和消减数据A。
1)a业务调用了b业务，但是他并不关心b业务做了什么，例如日志系统，就属于这种方式，可以将日志系统拆分出来；
2)a业务调用了b业务，用户关心最终结果，但是a和b不会涉及数据一致性问题，这时候也可以采用消息队列的方式来进行；
架构图和一些总结明天补上，今天来不及了。