在验证 BCS（对应Redis）时，因为宝兰德不支持原生的Go 客户端，所以极光必须自行开发一个中间服务做Redis 协议转发，通过把Go 的协议转发给Java 的 SDK来实现。我们先调用 Java SDK 客户端对 Redis的几种数据类型（string、set、hash、list、zset）做了兼容性验证，发现数据读写都是正常的。
另外，也写了一个简单的协议转发服务proxysrv，用于将umsserver 对 Redis的操作转发给 BCS的原生SDK，在对基本场景验证后确认方案可行，但是由于协议转发存在性能损耗，同时由于proxy 与 ums server 之间是一个长连接，涉及连接保活的机制，要完美实现可能会有点复杂，因此决定放弃适配宝兰德，选用东方通RDS。
在验证 BESMQ时，同样遇到了没有 Go SDK的问题，我们自研开发了一个代理服务用于协议转发，但在自测过程中遇到了连接无法保活的问题，如果要保活则需要实现心跳机制，心跳机制相对比较复杂，因此决定放弃适配，选用东方通TongHtp。
1、RocketMQ替换为东方通TongHtp2.0
在获得相关文档后，极光开发对东方通提供的十来个资料进行了查阅调研。
一开始，我们选择基于异步接口进行系统改造，一般来说，异步接口在每次请求后都会收到一个对应的回调，是适用于UMS 业务需要的，但在实际调试时，我们发现只有第一条才会有回调返回，这样的逻辑让UMS系统无法判断消息是否已发送。而东方通表示该异步接口的设计现状就是如此，不得已，我们只好对同步接口进行封装后再集成到UMS 中使用，浪费了一些时间。
在对「文件上传功能」进行适配时，发现TongHtp2.0 出现字符流数据读取乱码的问题，分析发现是因为TongHtp2.0 不支持gzip格式。在这个情况下，我们需要对业务涉及字符流的地方进行特殊编码处理才能完成兼容适配，最后通过修改成十六进制的编码解决了这个问题。
由于 TongHtp2.0 依赖.so动态库，无法在本地的开发环境进行调试，必须在部署脚本中指定依赖的动态库，然后打包放到服务器上，通过打日志的方式来进行调试。因为调试方式复杂使得适配工期拉长。
经过反复的调试、沟通讨论，最终我们在8 月末顺利完成东方通TongHtp2.0 的开发、自测。
2、Redis替换为东方通TongRDS2.2.1.2
9 月，我们在测试环境中安装了TongRDS ，编写了一个测试Client 与测试Server 测试其对Redis 协议的兼容性，其中Client 用于实现数据的写，Server用于实现数据的查询，我们测试验证了string、list、set、hash、zset等几种常见的数据类型，同时验证了ttl 以及数据持久化。
在 Redis兼容性验证之后，由于东方通TongRDS 有原生的Go sdk，因此我们用TongRDS 替换Redis，部署在我们的UMS 测试环境中，验证UMS 的业务功能是否正常。
3、Nginx替换为东方通TongHttpServer
9 月，我们在测试环境中安装了TonghttpServer，替换UMS 系统使用的Nginx 后验证 UMS Portal 基本功能，可以正常运行。
在验证高级功能时，因为在频率限制、黑白名单等功能中用到了Nginx Lua，所以需要验证TonghttpServer 对Nginx lua 的支持和兼容性。我们编写了Nginx lua 脚本，将其放到TonghttpServer 的对应目录并更新配置文件，重启后验证api limit 以及路由转发功能是否正常。
本文作者可以追加内容哦 !
