excerpt <!-- more --> ## 二、技术探索 1. protobuf 比 kryo 在速度上 2. CI：每当你添加一块乐高砖，你都要确保它正确地适应其他部分，不会导致房子倒塌；CD (Continuous Delivery)：确保它随时都可以上架被展示给其他人；CD (Continuous Deployment)：上架的过程（切环境），无需繁琐易错的手动操作。 3. 拼团需求中存在一个复杂对象复制的场景，代码调用手动复制的方案开发成本高，不易维护；序列化的方案面对一些无默认构造器的工具类会抛异常，即使目前 ignore，也无法保证以后的开发者在更改类的结构时注意这一点。查阅资料，通过调研整理了深拷贝的一些常用手段，发现 Kryo 工具的方式可以通过调用底层 unsafe 函数来解这个问题，并且性能优于 Json 序列化的方式，如果后期需要多处复制，可以考虑替换为这个方案。输出：复杂对象深拷贝的最佳实践 on 2023-11-06 4. 完成了 Hackathon 比赛，在这种带 DDL 的开发中，进度确实飞快。对 python 开发技能与各 AI 模型的调用，以及目前常见的大模型开发框架，前端模版，python 项目的部署都有了更多的了解。经历的很多环节也能给工作中的开发一些启发。最大的感受是编程思维在各个项目中的通用性以及信息检索，阅读理解速度对于快速掌握一门新技术的重要性。结合这次的开发经验和自己过去写的口语复盘工具，准备之后将其完整部署，并且邀请一些朋友去用，自己经营一个线上项目，培养自己项目全生命周期的思维。 5. 阅读 naos 系统中 EngineContext 的范型设计、Guava 中 Maps 的一些方法设计。 6. 学习了 protobuf 序列化工具定义数据结构，编译执行的一些细节。 7. 本需求阅读代码中，发现底层调用 NotifyToCallrtService 时，使用了 guava 的 rateLimiter 工具，据此去了解了单机限流与集群限流的不同方案，写了 guava 的 rateLimiter 的学习 demo，同时注意到我们代码中使用了两层限流，第一层是对每个 wrapper 的限流，第二层是总数限流，前者是为了避免过多的请求影响代理商服务的正常运行，后者是为了避免影响我们自己的服务以及下游 spa 那边的服务。 8. 之前在查询 redis 中的 wrapper 服务成本时看到了系统中的 redis 切片集群情况，查阅资料了解了几种主流的切片方案，和其与大内存云主机方案的优劣。 9. sirius 异常处理部分，为了避免产生大量超时日志，没有单独设置超时异常，将其放在了最后的 Exception 中，也没有 log.error，只是打了监控。