版本升级
大约 5 分钟
版本升级
- 第一代Sekiro从2019年开发,自2021年4月终止开发,并在2021年整年推进用户下线替换升级。
- 第二代Sekiro自2021年开发。由于第一代Sekiro代码有太多底层架构方面的问题,故第二代Sekiro相对于第一代是一次完全不兼容的重构
- 第三代Sekiro发布与2023年初。相比于第二代,其底层协议兼容第二代(部分javaSDK存在过度设计嫌疑,故做了部分改动)。第三代继续在产品架构概念演进、更多关注多语言、分布式、工程化等完善闭环产品打造
第一代(2019)VS 第二代(2021)
从用户使用层面来说,有如下差异,用户可以根据下表直观了解相关功能如何切换到新版
名称 | 老版 | 新版 |
---|---|---|
构建工具 | gradle,核心从Android平台开发,使用AndroidStudio | maven,作为一个标准java工程开发,构建工具链以maven为主,但是demo项目也支持用as打开(AndroidDemo部分) |
端口 | 使用5601、5602、5603三个端口,提供三种协议的功能,对于三个端口的使用,用户容易理解困难,经常发生端口设定错误的情况 | 开源版只使用5612一个端口,不在需要纠结那个功能使用那个端口 |
url | business 修改为business-demo | |
部署方式 | 使用独立jar包 | zip文件夹 |
保留关键字 | ||
包路径 | com.virjar.sekiro | com.virjar.sekiro.business |
handler注册 | SekiroClient sekiroClient = | SekiroClient sekiroClient = |
代码质量 | 最开始了解netty的时候写的,对netty驾驭不够,各种模块拼凑嫌疑很大,也导致出现多个端口问题 | 三年中实现过多个netty的项目,对netty本身的机制了解更加深入,基本不再出现使用不规范、业务流中断、一致性无法保证等问题 |
底层协议 | 从netty demo改造的协议,存在容易被攻击(DDOS)、扩展困难等问题 | 全新协议,解决扩展和安全性问题 |
日志 | 作为java后端出身的同学,本人极度迷信logback,但是netty项目纯异步,使用logback导致同一个业务流出现在多个线程(终端),无法通过日志看出串联业务流 | 从底层SDK设计的时候考虑日志设计,新版日志都会有相关的traceID,且日志经过了良好的文件夹和文件切割。可以方便查看业务和系统的详细日志,且能够从业务流层面追踪一个调用的全部日志 |
压缩 | 完全不支持压缩,即使http调用入口可以压缩,sekiro端也没有压缩机制,高流量调用情况下,极其容易把带宽打满(云服务器带宽一旦超过10M,基本上就是特别贵的成本了) | 多端提供压缩机制,且支持用户自定义压缩算法和压缩规则。帮你减少服务器带宽使用 |
json反序列化 | 为了将服务器的失败状态和客户端的失败状态同步,以及实现失败状态监控,旧版sekiro将会对报文进行JSON解析,在高并发情况下极其容易引起资源CPU使用率高 | 在协议层面支持独立的json传输通道,服务器将会避免JSON反序列化,新版服务器在面临几千qps的时候CPU使用率都不会超过10% |
第二代(2021)VS 第三代(2023)
名称 | 老版 | 新版 |
---|---|---|
包路径 | com.virjar.sekiro.business | cn.iinti.sekiro3.business |
代码质量 | 基本达到良好可用 | 再次重构,在服务端和SDK再次重构核心代码,关注代码结构、流程trace、异步可靠性、实体抽象等。代码质量已经达到商品级 |
多语言 | 官方只支持java、浏览器websocket,其他语言都是用户自行实现(如社区对于python和frida的支持) | 支持非常多的语言,如:Java、JsWeb、python、Frida、go等 |
快速部署 | 只支持手动编译和部署 | 支持docker |
分布式 | 简单支持,但是用户使用不良好 | 分布式支持非常完善,并且推荐分布式的方式使用sekiro |
监控报表 | 少量的、不准确的计数 | 完善的监控报表 |
文档 | 少量的、基本的文档,大量使用材料依靠社区文章解释 | 完善的丰富文档,并且吸收社区经验,彻底解决一些理解困难和操作困难的操作方式(如ssl) |