多节点接口开发经验分享

作者自述

纯接口系列开发四年经验，有些想法目前无法实现，比如涉及到反馈，涉及到国际化协议的缺陷功能会者说自定义模式设计之初敲定版本时无法考量到的后期变更，或者新功能无法要求第三方进行变更，造成故障无法处理的安全隐患。
新接口开发对接可能是毫无经验的或者力求快可测试样例，比如前期需要敲定接口一对一，多对一，多对多等。一开始说一对一，结果后期直接来调测多对多，造成接口重大变更，该变更如果接口固化转发将无多大问题，但是接口涉及路由时，该方案变更将隐藏无数可能的后期故障点，如结点故障等。有些是旧项目就有的功能，当开发新项目的时候，也必须引入。

接口处理鉴权或者和鉴权系统通讯处理:单点登入联合登入，多设备登入 ，可扩展登入系统。

接口编号，以遍多接口识别。

接口处理上限设定，防止空间无限暴涨可能造成运行异常(线程栈默认过大，无法正常处理，需要反馈-例如王者荣耀玩游戏的大区角色注册数量有上限)

接口负责鉴权和建立连接分发token。并向内部处理传递全局唯一用户标识。接口负责限制连接数:数据库层级限制-数据库或链路故障无法，用户分区鉴权管理主备双节点协商限制。

接口从数据库同步数据后，重要数据备份到硬盘，如接口以保障性通讯为主，不涉及强一致性要求时，满足数据库故障时，接口依旧可以平稳运行，当数据库和硬盘备份全故障时，将认为接口不可用。

发送tcp缓冲区，用户状态包提取缓冲区，用户状态直接发送缓冲区。瞬间量大缓冲区满 TCP超过限定值后断开，或者用户状态发送超时无法发送自动断开_网络异常时可能造成单边缓冲区积压-断开操作正确，量大无法处理-若有反馈机制可以阻塞并限制上游发送效率-反馈，若一对第一应答将造成双向数据量都增大，反馈若定时每秒反馈空闲空间，应当配合被反馈最终选择发送方应当调整为缓慢发送。

接口负责禁用断开连接。

接口长连接必须有链路检测，或者超时无数据断开，最好协议支持链路检测，设想可以链路检测中满足队列空间情况。

接口负责入口数据路由。

接口双向服务多对多

两端的地位均等，例如支付宝和微信支付互联互通，若单个传输通道比较麻烦。，向处理模块汇报连接全局用户存在与否的情况-正常存在，间隔时间汇报-断开连接汇报但有可能丢失，因此设置一个清空存储占用空间，在此空间内进行断开汇报-极限异常情况下，占用空间期间汇报全部丢失。汇报采用正常-异常-超时无汇报作为异常处理。(接口若是多结点，而客户只单边连接，汇报丢失将造成疑似客户两边通路的情况，可能有数据走向丢弃路线)

接口服务端-接口客户端

假设该接口实现客户端和服务端满足发起者主要控制。例如支付宝和微信支付互联互通。(假设举例，并无支付宝和微信的相关开发经验)
多节点接口传输模式比对:

1 TX RX模式

微信传数据给支付宝，采用支付宝作为服务端，可以在架构上单节点故障点时候，多接口可以选择正常提供服务的。

2 TR 模式

若单一微信最为服务端或者支付宝作为服务端。若存在某一节点接口与客户端的异常，与服务端正常，服务端 负载发往异常接口，若协议没有反馈异常，那么故障时间越长，数据发往异常接口丢弃数据将增加-或解决方案-接口发现客户端全链路异常，把连接服务端的全部断开，在链路检测间隔期间内数据异常丢弃。故障时间越长，客户端无法连接到接口。当前接口将空跑。