前阵子写了sdk聚合SDK，今天想梳理下流程，记录一下。本文主要是梳理下流程，有错误忘斧正。
首先，一套聚合sdk，无论是对于需要我们接入的发行渠道还是准备接入我们聚合sdk的研发，所对接的接口无非就是一套登陆验签逻辑和一套下单发货逻辑。
登陆验签
站在游戏用户的角度，首次登录用户只是打开了游戏，然后在拉起的渠道登陆页面注册成功，从而进入游戏。
而SDK聚合，则相当于是研发和发行渠道之间的桥接，让两者的流程走通，详见下图。
1、研发客户端初始化成功，调用了FUSE聚合客户端提供的login方法；
2、FUSE客户端调用了发行渠道的login方法，发行渠道客户端拉出了用户的注册页面（新用户进游戏的注册页面）；
用户在拉起的注册页面进行注册；
3、发行渠道用户注册成功，生成发行渠道的唯一用户标识ch_uid、ch_token（token用来做登陆验证），返回给到了FUSE客户端；
4、FUSE客户端获取到了渠道用户信息（ch_uid和ch_token），FUSE客户端请求FUSE服务端，验证渠道用户；
5、FUSE服务端请求渠道服务端提供的用户验签接口，验证用户信息；
6、渠道的用户验签接口返回验证成功，FUSE服务端生成FUSE聚合的唯一用户标识fuse_uid、fuse_token，和ch_uid一一对应；
7、FUSE服务端返回fuse_id、fuse_token给FUSE客户端；
8、FUSE客户端返回fuse_id、fuse_token给研发客户端；
9、研发客户端获取到了FUSE聚合用户信息（fuse_uid和fuse_token），研发客户端请求研发服务端，验证渠道用户；
10、研发客户端请求FUSE服务端提供的用户验签接口，验证用户信息；
11、FUSE的用户验签接口返回验证成功，研发服务端生成研发的唯一用户标识cp_uid，和fuse_uid一一对应；
12、研发服务端返回cp_uid给研发客户端；
13、客户端收到用户注册成功回应，进入游戏界面。
总的来说，关于登陆验签，新用户标识首先在发行渠道产生，然后到FUSE聚合SDK，最后到研发。每一端都会有自己的一个uid，一一对应，fuse_uid会对应到一个ch_uid，cp_uid会对应到一个fuse_uid。
对于研发端，它所有逻辑都是跟FUSE聚合SDK对接，不会跟渠道端有任何联系，而FUSE聚合SDK充当了两者的桥梁角色。
下单
1、用户点击下单，研发客户端捕捉到，请求研发服务端下单接口；
2、研发服务端生成一个订单信息，研发唯一订单号cp_order_id，并把唯一订单号cp_order_id返回研发客户端；
3、研发客户端拿到cp_order_id，调用FUSE客户端提供的下单方法，请求下单；
4、FUSE客户端拿到cp_order_id，请求FUSE服务端下单接口；
5、FUSE服务端生成一个订单信息，FUSE聚合唯一订单号fuse_order_id，与cp_order_id一一对应，并把唯一订单号fuse_order_id返回FUSE客户端；
6、FUSE客户端拿到fuse_order_id，调用发行渠道客户端提供的下单方法，请求下单；
7、发行渠道客户端拿到fuse_order_id，请求发行渠道服务端下单接口；
8、发行渠道服务端生成一个订单信息，发行渠道唯一订单号ch_order_id，与fuse_order_id一一对应，经过支付逻辑处理，返回一个支付链接给发行渠道客户端；
9、发行渠道客户端拿到订单的支付链接，拉起支付页面；
10、用户支付成功后，支付渠道会 带上透析参数 请求其配置的回调地址（发行渠道服务端提供的支付回调接口）；
11、发行渠道服务端验证支付订单成功，带上透析参数请求FUSE聚合服务端提供的支付回调接口；
12、FUSE聚合服务端验证支付订单成功，带上透析参数请求研发服务端；
13、研发服务端收到订单支付成功回调，验证成功，配合研发客户端处理发货逻辑。
总的来说，关于下单，订单号是先在研发产生，，然后到FUSE聚合SDK，最后到发行渠道。每一端都会有自己的一个order_id，一一对应，fuse_order_id会对应到一个cp_order_id，ch_order_id会对应到一个fuse_order_id。
对于研发端，它所有逻辑都是跟FUSE聚合SDK对接，不会跟渠道端有任何联系，而FUSE聚合SDK充当了两者的桥梁角色。
