一个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服务构建的思考】了解下i18n服务背景以及针对性的提出相关模块设计的思路
推荐阅读
- 一个人的旅行，三亚
- 一个小故事，我的思考。
- 一个人的碎碎念
- 七年之痒之后
- 我从来不做坏事
- 异地恋中，逐渐适应一个人到底意味着什么（）
- 迷失的世界（二十七）
- live|live to inspire 一个普通上班族的流水账0723
- 遗憾是生活的常态，但孝顺这件事，我希望每一个人都不留遗憾
- NO.38|NO.38 我不是嫁不出去，而是不想嫁