思维导图

思维导图.png

---

系列总目录

• 业务场景实战汇总

---

背景

1. 提供文本内容统一管理、文本内容下发功能、APP/WEB等弹框提醒内容的维护等，减少各业务系统后期维护诸如下拉框、Code Message等内容的工作。
2. 为将来的多语言国际化提前规划部署。
3. 随着公司业务的快速发展，针对文本内容的管理维护成本越来越大，规范越来越不好定义，硬编码随处可见。为了更好的长期发展需要以及对未来国际化多语言版本的更好支持，需要一个独立的字典服务系统来统一维护

---

业务特点

1. 近实时：字典服务区别于其他的业务服务，是一个数据下发服务，对实时性没有严格要求，能接受几分钟内的数据延迟，而且大部分数据是业务功能上线之前提前录入。
2. 读多写少：内容管理和下发服务，本质上是一个读多写少的服务。当业务方业务稳定后，对内容的修改较少。此外提供给业务方的sdk主要是通过轮询的方式获取最新的信息，则读的请求量会很大。
3. 请求重复性：对业务方应用集群而言，同一时间段内发起的后端查询往往是重复的。如在发布过程中数据初始化，每台机器执行的操作都是一致的，因此服务端缓存能够有效解决这种重复请求。
4. 缓存方式：较大部分查询场景为多维度数据匹配的范围查询，服务端难以全面预知客户端的具体请求条件，因此难以通过异步方式提前建立缓存，可以选择被动式缓冲。
5. 数据实时性处理：被动式缓存主要是通过设置过期时间来自动过期的，因此为了保证数据的实时性和保证缓存的命中率，缓存时间应保持和sdk轮询周期大致一致。服务端也可以通过监听数据变化来主动过期缓存，保证数据实时性

---

字典服务端

• 对于服务端来说，希望拥有一个冗余的数据拉取通道来分摊服务端的压力。对于客户端来说，希望能拥有一份冗余的本地多语言资源，来降低对服务端的强依赖提高客户端的可用性。一般情况下业务方业务迭代完成后，不会频繁的变更多语言内容，所以对于冗余的资源文件，无需非常频繁的刷新内容。即便文件内容不是最新的，对客户端来说仍然能通过增量接口进行数据修正。最终方案如下

  
  字典服务端.png
• 一期设计可以考虑先不做文件系统，因为字典SDK有做客户端缓存初期量不大也可以考虑服务端不做redis缓存

---

字典SDK

背景

1. 目前公司国际化流程，多语言的需求呼之欲出
2. 现如今，前端错误信息展示是根据后端返回code做映射，由于app端有版本问题，旧版本不能同步新的错误码
3. 后端做错误信息展示统一管理，前端只需要直接展示即可

设计

1. 获取翻译信息

   
   uml.png
   流程图.png

2. 启动时冒烟初始化，定时全量更新

   
   uml.png
   流程图.png

• 增量更新逻辑同全量更新，区别在于服务端返回结果数量不同，会有version乐观锁做增量数据获取

---

参考文章

• 干货 | 携程多语言平台-Shark系统的高可用演进之路