共计 4029 个字符，预计需要花费 11 分钟才能阅读完成。
在工作中，云产品之间天然少不了各种零碎的对接，零碎对接天然会波及到各种鉴权，以及须要将对方零碎的组织构造同步到己方外部零碎中来
当然，有的产品可能会去对接理论的第三方认证源和同步源，然而老本绝对比拟高，因为对接一个不同的源就须要去实现一套接口和逻辑，尽管流程大同小异，可理论工作量可不小
因而，大多数产品为了不便和节俭人力，是会抉择对接 IDaaS，让 IDaaS 去对接各种第三方认证源和同步源
此处的 IDaaS 解释一下：
IDaaS 即 Identity as a Service，直译为身份即服务，是一个构建在云上的身份服务
接下来是对于上篇文章谈到的组织构造同步优化的思考，心愿可能给 xdm 带来不一样的思考
- 坑爹，线上同步近 3w 个用户导致链路阻塞引入发的线上问题，你经验过吗？
根本介绍同步流程
之前是本身的零碎去和企微，钉钉这样的第三方认证源 / 同步源进行对接，耗时耗力
当初是将这些工作全副由一个叫做 IDaaS 的模块来实现 ，能够说他也是一个第三方零碎，只是集成了罕用的一些第三方平台的认证源和同步源， 专门的人做专门的事效率是最高的
根本交互如下：
过来做的很 low 的同步做法
一个音讯近 3 w 用户，数据量 6 M 左右
明天次要是分享对于同步的做法，看了上一篇文章，有一点任何和教训的 xdm 就晓得，一个音讯外面放近 3w 个用户，这种形式解决真的是几乎了，不靠谱，危险十分高，对性能也影响很大
平时数据量小的时候没啥感觉，起量了，劫难就来了，因而咱们做需要做性能，要思考在后面，预防这样灾难性的问题以及对真的呈现这种问题的时候，要有预案
第三方组织构造同步性能优化须要思考哪些点
那么经验了上次事变，天然下来要认真思考如何解决这种组织构造同步的问题，并且反对的用户量要30 W 起步（此处指的是 一个租户能够承载 30W，而不是整个平台 30W）
那么咱们须要思考如下几个问题：
- 从 IDaaS 获取数据的程序，形式如何解决？
<!—->
- 服务 A 与 服务 B 的通信形式，提供多少个 RPC 接口来实现一次顺利的组织构造同步？
<!—->
- 在同步数据过程中呈现了问题，异常中断了咱们须要如何复原 ， 之前曾经同步了的数据须要如何去解决？
<!—->
- 如何能力达到同步 30 w 用户无异样，且能顺利同步胜利
<!—->
- 同步的数据如果不合乎平台的规定，须要筛选进去，并注明抵触起因，返回给前端页面
其实将上述问题思考分明，残缺的答复结束，基本上这个优化计划就能够落地了，那么咱们开始吧
从 IDaaS 获取数据的程序，形式如何解决？
服务 A 去找 IDaaS 进行数据同步的时候，咱们能够分成四个阶段
- 第一阶段，创立工作，保障同一个工夫同一个租户只有一个同步工作在执行
<!—->
- 第二个阶段，从 IDaaS 处罚页获取组 ， 再分批次给到 服务 B
在这个阶段的时候，可能会思考到一次性将组获取过去不就好了吗？一个租户上面也不会有多少用户组吧？
实际上大一点的客户，光组的数据就有 2-3 w 个，甚至很多的，因而还是须要分页去获取，而后分批次推送给服务 B，服务 B 将数据给到长期用户组表中
- 第三个阶段 ，从 IDaaS 处罚页获取用户，并批次给到服务 B，服务 B 将数据给到长期用户表中
<!—->
- 第四个阶段，触发并告诉能够正式将数据写入到正式表
服务 A 与 服务 B 的通信形式，提供多少个 RPC 接口来实现一次顺利的组织构造同步？
目前来服务 A 作为调用者，那么 服务 B 天然是提供 4 个接口，别离为
- 创立同步工作
<!—->
- 同步组
<!—->
- 同步用户
<!—->
- 写入正式表
在同步数据过程中呈现了问题，异常中断了咱们须要如何复原，之前曾经同步了的数据须要如何去解决？
那这个时候，对于组织构造同步的话咱们须要这样来设计，首先会思考咱们本次的数据同步是属于全量同步，还是属于增量同步
例如，咱们同步过用户数据，则在咱们本人的平台上会有一个 /IDaaS 的组 ，同步之前校验平台中是否有这个组， 若有，则为增量同步，反之，则是全量同步
对于减少每一个阶段的可靠性，以及程序的健壮性，并且受到异常中断之后，还可能进行断点续传，咱们针对每一个阶段设计了这样的流程：
总体阐明
总体来说，咱们设计 3 张表，4 个同步状态，以及 14 个同步步骤
3 张表
其中蕴含 一张同步记录表，一张长期用户表，一张长期用户组表
同步记录表 寄存这些关键字段
- 根本的租户 id
<!—->
- 记录重试次数
<!—->
- 同步类型
<!—->
- 以后的同步状态
<!—->
- 以后的同步步骤
长期用户组表 寄存这些 关键字段
- 根本的租户 id
<!—->
- 组 id
<!—->
- 组名
<!—->
- 父组 id
<!—->
- 是否非法
<!—->
- 非法起因
长期用户表 中寄存这些关键字段
- 根本的租户 id
<!—->
- 用户 id
<!—->
- 用户名
<!—->
- 组 id
<!—->
- 是否非法
<!—->
- 非法起因
能够看出，3 张表次要都是通过租户 id 来进行匹配的
4 个同步状态
| – sync_in | 同步中 |
|---|---|
| – sync_interrupt | 同步中断 |
| – sync_fail | 同步失败 |
| – sync_success | 同步胜利 |
14 个同步步骤（全量 + 增量）
同步长期数据步骤
| 1 | sync_begin | 同步开始 |
|---|---|---|
| 2 | sync_temp_group | 同步组信息到长期组 |
| 3 | sync_temp_user | 同步用户到长期表 |
全量步骤
| 4 | full_sync_group | 全量同步长期表中的组到正式表 |
|---|---|---|
| 5 | full_sync_user | 全量同步长期表中的用户到正式表 |
增量步骤
| 6 | incr_sync_markup_group | 标记组步骤 |
|---|---|---|
| 7 | incr_sync_markup_user | 标记用户步骤 |
| 8 | incr_sync_delete_user | 从正式表中删除用户步骤 |
| 9 | incr_sync_add_group | 将长期表中的组写入到正式表中 |
| 10 | incr_sync_move_user | 解决正式表中移动用户 |
| 11 | incr_sync_add_user | 将长期表中的用户增加到正式表中 |
| 12 | incr_sync_edit_user | 编辑正式表中的用户 |
| 13 | incr_sync_delete_group | 删除正式表中的组 |
| 14 | sync_end | 增量同步完结 |
接下来咱们能够依照上述 提供的四个接口来进行论述 上述同步状态和同步步骤都是如何应用的，本次先写前 3 个接口，后果是将第三方的数据全副同步到 服务 B 得了长期表中，且标记好数据是否非法，也是为下一篇留下一个伏笔
创立同步工作
本接口旨在管制一个租户同一时间只能有一个同步工作
- 校验申请是否有同步记录，如果有，则校验 同步状态 是 同步中（sync_in） 或者是 同步中断（sync_interrupt），则本次不进行同步
<!—->
- 校验平台中是否有 /IDaaS 组，若有则记录同步类型为 全量同步（full），若没有则记录同步类型为 增量同步（incr）
<!—->
-
将同步记录写入到同步记录表中，同步状态为 同步中（sync_in），同步步骤为 同步开始（sync_begin）
起因如下
此处校验 同步状态 是 同步中（sync_in） 或者是 同步中断（sync_interrupt），则本次不进行同步，起因如下：
- 若触发以后接口，发现租户同步记录中 同步状态为 sync_in，则阐明曾经有工作在解决同步工作了，无需再次执行
<!—->
- 若 同步状态为 sync_interrupt，阐明这条同步记录之前异常中断，那么本次工作也无需再次执行，另外一边会有一个定时工作去扫同步记录表中的 sync_interrupt 同步状态的数据，轮训去读取后，进行组织构造同步
同步组数据到长期表
本接口旨在将第三方用户组数据全副同步到长期用户组表中，并标记非法与非法数据
- 校验以后同步记录的状态是 sync_in，否则不进行解决
<!—->
-
开启事务
- 校验以后数据若是第一页数据，若是，则清空长期用户组表，且在同步记录表中记录 同步步骤为 sync_temp_group
-
若不是第一页数据，则校验同步记录表中的同步步骤是否是 sync_temp_group
- 若是，则持续，将第三方的数据逐页进行根本校验后，将数据逐页写入到长期用户组表中，且标记每一条数据非法和非法
- 若不是，则返回错误信息，让调用者完结整个流程，此处的调用者即 服务 A
同步用户数据到长期表
本接口旨在将第三方用户数据全副同步到长期用户表中，并标记非法与非法数据
- 校验以后同步记录的状态是 sync_in，否则不进行解决
<!—->
-
开启事务
- 校验以后数据若是第一页数据 ，若是，则清空长期用户表，且在同步记录表中记录 同步步骤为 sync_temp_user
-
若不是第一页数据，则校验同步记录表中的 同步步骤 是否是 sync_temp_user
- 若是，则持续，将第三方的数据逐页进行根本校验后，将数据逐页写入到长期用户表中，且标记每一条数据非法和非法
- 若不是，则返回错误信息，让调用者完结整个流程，此处的调用者即 服务 A
总结
通过上述 3 个接口，配合应用上述说到的同步状态和同步步骤，目前为止，就能够将第三方组织构造的所有数据疾速高效的放到 服务 B 的长期表中
对于这些长期数据，如果呈现了异常中断，那么若再次触发同步工作，咱们清空长期数据，写入本次第三方组织构造数据即可
那么对于如何将长期表数据，写入到正式表中，才是真正的大头
不过也不简单，对于写入数据到正式表的时候，分成全量同步和增量同步来进行解决 ，并依照每一个步骤进行校验和解决， 就能够达到断点续传的成果，且效率比之前的计划快了不止一点点，详情能够查看下一篇文章
感激浏览，欢送交换，点个赞，关注一波 再走吧
欢送点赞，关注，珍藏
敌人们，你的反对和激励，是我保持分享，提高质量的能源
好了，本次就到这里
技术是凋谢的，咱们的心态，更应是凋谢的。拥抱变动，背阴而生，致力向前行。
我是 阿兵云原生，欢送点赞关注珍藏，下次见~
对于线上问题的状况，能够查看如下文章：
- 坑爹，线上同步近 3w 个用户导致链路阻塞引入发的线上问题，你经验过吗？
- 【性能优化下】组织构造同步优化二，全量同步 / 增量同步，断点续传
对于认证的相干内容能够查看文章：
- OAUTH 之钉钉第三方受权
<!—->
- JWT 身份认证(附带源码解说)