组织机构认证服务

项目需求：用户和组织机构服务平台。

1.单点登录

2.用户和组织机构层级管理

初步不成熟设计（手动画了一图，字太丑，不好意思呈现，等周末有空补上）：

大致是这样的：

1.整体分三部分：

1）外部单位（也就是单点登录白名单里的单位）

2）组织机构分很多单位，有层级划分，比如市，区县，校等

3）各个单位下的用户

2.三者之间关系：外部单位通过关联组织机构单位中的id实现二者之间用户的通用性。

3.技术关键点：

1）数据库方面的设计。

因为该系统作为服务存在，用户数据会被很多其他平台请求获取，平台中的数据也会不断的增加，因此用户数据量会很庞大，怎么设计数据库成为该项目的重点之一。此处考虑了三点改进方案：

a.读写分离，配置主从数据库，主数据库负责增删改，从数据库承担读压力。（此处，数据库之间数据同步是重点，待研究）

b.用户表的拆分。用户表可数据量会比较多，表查询速度会相当慢了，因此考虑把用户表拆分成几个表。

拆分分为横向拆分和垂直拆分。单条用户数据的字段之间不便于拆分，而且数据量是个限制，横向拆分并不能解决这个问题，因此此处暂不考虑横向拆分（即把用户的字段拆分成几个表）。

垂直拆分是把用户数据量分散开来，考虑三种垂直拆分方式：i）按照单位节点拆分。优点：符合业务逻辑，方便查询，后期可扩展性大，拿到用户能够直接知道用户在哪个表，不用建立用户id和表的对应关系表，因此不会增加查询数据次数；缺点：拆分的表不便于控制，表之间压力分配不均。ii）按照id来拆分，比如1-1000放a表，10001-2000放b表，依次类推。优点：不会增加查询次数，拆分简单；缺点：扩展性差，压力可能会分配不均。iii）按照余数（不知道叫啥，假设叫余数）方式拆分，将用户id/10（也可以是2，3，5……）后的余数来分表，比如余1放到a表，余2放到b表，依次类推，这样分成十个表（分成十个表，分法简单，也基本能满足业务需求，如果数据量再大的话，就要考虑数据迁移了）。优点：能够均匀分担压力；缺点：查询不便。目前尚在i和ii之间犹豫选择哪种方式。

c.缓存（memcache），还没考虑怎么用。

2）完全跨域单点登录。

大致过程如上图，实际就是产生ticket，验证ticket的一个过程，但ticket如何能作为不同应用和不同浏览器的凭证呢。（暂时有一点不成熟的想法，待验证中）。应用a去认证系统时，认证系统检测有没有比如是ticket的cookie存在，如果没有，则需要a登录，a通过认证系统登录时，认证系统在自己这里写一个ticket，同时返回给应用用户信息，a应用再讲用户信息处理后返回给浏览器，这样a应用就是登录状态了，并且在自己这里写入cookie，这样a应用的其他页面也都是登录状态了。b应用去认证系统时，认证系统检测名为ticket的cookie是否存在，如果存在说明是同一浏览器发送的请求，并且已经处于登录状态，认证系统验证后直接返回给b用户信息，这样b也是登录状态了，同理c。这样认证系统通过cookie能够区分不同的客户端了，再通过cookie里的信息来判断a，b，c能否允许该用户登录。

暂时选这样，继续不但完善中……