一个i18n服务构建的思考

背景

服务需要国际化资源，比如国内叫“你好”，国外需要翻译为“hello”

要求

灵活，可配置:
希望配置是热更新的，即不能加一个文案，后端代码资源文件就加几行，再上线部署。

尽量减少服务本身的请求次数，让上游把i18n的配置拿走，异步更新，定时的像i18n请求最新的资源。

设计

导入模块

导入模块，比如excel，txt，csv等格式文件

metrics模块

比如各种key被用到的次数，监控

数据结构

appId，标识业务方
key，比如“hello”
value，比如“hello”，“你好”
Locale，见下面定义，如“en-GB”等

备注：可以学习下Locale的定义
https://en.wikipedia.org/wiki/Locale_(computer_software)

Locale 是一套用于定义用户希望在其用户界面上看到的各种可以改变的选择的参数集合。通常一个区域设置标识符至少包括一个语言标识符和一个区域标识符。
- en-GB for English as spoken in the United Kingdom
- es-AR for Spanish as spoken in Argentina

存储模块

读：db即可，redis都不用，服务启动加载全量资源文件，缓存到localCache用AppResource表示
写：提供前端页面以及对应写的rpc接口

上游交互接口

可以看出这个服务接口本身稍微占用点内存，不耗费CPU

举例： 1024个key，1000个Locale，每个key，value平均占用10b，那也就是10Mb内存

那么如果让上游频繁调用rpc接口来获取这一套资源配置，rpc通信时间相对耗时较久，没必要，不如让上游也采取类似逻辑，即

上游client:
异步：定时如5分钟调用rpc请求，缓存到本地资源缓存
同步：利用本地资源缓存服务
i18n server:
异步：定时如5分钟去db拉数据，缓存到本地资源缓存
同步：利用本地资源给上有服务

总结

了解下i18n服务背景以及针对性的提出相关模块设计的思路