- VisualStudio2022插件的安装及使用-编程手把手系列文章
- pprof-在现网场景怎么用
- C#实现的下拉多选框,下拉多选树,多级节点
- 【学习笔记】基础数据结构:猫树
专题目录 。
一文搞懂国际化(一)背景概览 。
一文搞懂国际化(二)架构设计 。
一文搞懂国际化(三)落地实践 。
一文搞懂国际化(四)总结提升 。
第一章,我们分析了国际化项目的背景和基础知识,本章我们来分析一下要实现国际化的功能,有哪些设计点。本章只讲设计,不讲落地实践(见第三章).
回顾笔者主导的这一年的国际化改造项目过程,可归纳出三大块设计难点:
相信大部分做国际化改造的项目都会遇到上面所说的设计场景,下面我们针对这三大块进行初步分析.
要实现用户多语言切换,可拆解成2部分:
不管是前端静态资源包还是后端的动态翻译,都有3种实现逻辑,即设备跟随、账号跟随、系统跟随.
纯系统跟随策略的产品很少(不够灵活),使用另外两种策略的产品市面上很多,看哪种适合你。(一般来说,账号跟随适合强B端的重企业偏向的产品,设备跟随适合强C端的重个人体验的产品。) 。
前端逻辑很简单:就是根据当前语言,获取静态资源包中的翻译.
现代前端工程框架 react、vaue等都是有自己支持一套国际化方案的,在前端工程中的保存有i18n翻译资源包(例如VUE的i18n框架),随着项目打包发布。例如zh_CN.json 这样的json格式.
前端的语言,生命周期应该是登录态持有的(不管用的是设备跟随还是账号跟随策略)。即如果语言被改了,不会立即生效,登出后再登入,刷新登录态,此时获取到最新语言,才会生效.
后端的翻译跟前端最大的不同是复用。比如某个微服务中的一个字典翻译,可能会被上层多个不同业务层服务接口用到。如何设计一个可复用,高性能,易维护的后端翻译架构,还是有点难度的。下买呢我们从业务模型、具体设计两个步骤来进行设计拆解.
思考到大部分翻译是通过接口定义的返回字段上做的翻译,比如某个resultDTO。这个DTO(或者是其中某些字段)又会被多个上层应用引用。当某个底层服务的接口resultDTO中的翻译字段更新时,上层引用的缓存需要同步更新。这种缓存依赖关系,需要配置在各自的apollo中。这样当依赖的缓存更新时,上层引用方也会刷新缓存.
1.前置操作 。
1)设置好用户的语言:不管是客户端跟随,还是账户跟随.
2)后端服务:用到翻译的后端服务启动时,根据配置的服务依赖关系,读取翻译库,生成内存缓存.
2.请求流程 。
1)前端请求:前端请求头header传过来。前端登录态持有语言的生命周期(不管语言策略是客户端跟随还是账户跟随).
2)后端框架:读取请求头中的语言+服务名+翻译key,从缓存中获取翻译值.
1)能力封装 。
后端翻译,统一存储在配置中心(微服务)的翻译表中。配置中心对外提供翻译的增删改查接口,作为一种翻译能力提供。根据第一节业务分析得知,翻译拆解为服务级维护,翻译表设计核心业务模型:服务名-翻译key-语言类型-翻译值value. 。
2) 翻译性能3)框架升级 。
后端的底层框架包(一般叫base/core包)升级:要能够解析请求头中的语言+接口返回序列化时增强做翻译。接口返回DTO上加注解,注解分两类:整个类上,字段上。字段上的注解需要填写key。框架层在返回DTO序列化时,读取翻译注解:根据key+语言从缓存中读取对应的翻译值,塞入序列化返回值.
。
多时区改造是国际化改造中的重头戏,如非必须改造,不建议轻易动。特别是业务链路长、微服务特别多、软硬件一体化的系统。笔者项目设计了2个月,改造花了3个月最后才上线.
。
我们以最简单的前后端接口通信为例,讲解多时区的问题以及改造方案.
一般我们未支持过国际化的系统特性:
一开始业务在国内跑,一般系统的运行环境都是UTC8时区的,所以不会出现上述的2点时区偏移问题。但在国际化多时区场景下,同一个时间字符串 “yyyy-mm-dd HH:mm:ss”,在美国和在韩国,代表的肯定不是一个时间点。第二点,当一般业务量不是特别巨大时,业务发展初期,也不会根据地域时区去拆库。所以数据库一般就一个时区,即国内的UTC8。有点设计经验的小伙肯定想到了,时区转换的方案:即前端数据到后端后开始,统一使用一种时区,包括存储。最后接口返回给前端时,再转换前端不同的时区时间即可。问题来了,我们是继续使用UTC8做后端底座,还是全部改造成UTC0呢?两种方案的对比如下:
。
方案一:使用UTC8环境(后端服务、组件、数据库)不变。步骤如下:
方案二:重新部署一套UTC0环境(后端服务、组件、数据库、洗数据).
建议:
笔者的团队在纠结了多轮博弈后,最终还是选择了UTC0时区,一步到位,耗时三个月呕心沥血才改造完毕。这两种方案都可行。看哪种适合你的团队即可!!!。如果系统链路长,涉及各种云、边、端服务,保守起见可以使用UTC8方案一.
分析了国际化翻译业务场景中,在运营平台中新增多语言管理菜单,进行可视化运维。可拆分为3步骤:
。
关于如何提高翻译精准度问题,这里提供一些思路,大家可选择适合自己项目的:
1.人工校对 。
由于翻译场景不同,翻译值可能变化较大,如需要极度精准翻译,一定是找专业翻译人员,一个一个页面去校对.
2.AI翻译 。
1)由于中文的复杂度可能导致翻译的不精准。可以先中文->英文,再用英文做key,调用AI去翻译 韩语、俄语等外语。精准度会有较大提升.
2)如有专业领域的大模型直接选择更佳.
3.打标收敛 。
打标已矫正过的翻译,逐步收敛不精准翻译.
。
最后此篇关于一文搞懂国际化(二)架构设计的文章就讲到这里了,如果你想了解更多关于一文搞懂国际化(二)架构设计的内容请搜索CFSDN的文章或继续浏览相关文章,希望大家以后支持我的博客! 。
HTTP缓存相关的问题好像是前端面试中比较常见的问题了,上来就会问什么cache-control字段有哪些,有啥区别啥的。嗯……说实话,我觉得至少在本篇来说,HTTP缓存还算不上复杂,只是字段稍
代理,其实全称应该叫做代理服务器,它是客户端与服务器之间得中间层,本质上来说代理就是一个服务器,在HTTP的链路中插入的一个中间环节,就是代理服务器啦。所谓的代理服务就是指:服务本身不生产内容,
我们在前两篇的内容中分别学习了缓存和代理,大致了解了缓存有哪些头字段,代理是如何服务于服务器和客户端的,那么把两者结合起来,代理缓存,也就是说代理服务器也可以缓存,当客户端请求数据的时候,未必一
在前面的章节,我们把HTTP/1.1的大部分核心内容都过了一遍,并且给出了基于Node环境的一部分示例代码,想必大家对HTTP/1.1已经不再陌生,那么HTTP/1.1的学习基本上就结束了。这两
我们前一篇学习了HTTP/2,相比于HTTP/1,HTTP/2在性能上有了大幅的改进,但是HTTP/2因为底层还是基于TCP协议的,虽然HTTP/2在应用层引入了流的概念,利用多路复用解决了队头
前面我们花了很大的篇幅来讲HTTP在性能上的改进,从1.0到1.1,再到2.0、3.0,HTTP通过替换底层协议,解决了一直阻塞性能提升的队头阻塞问题,在性能上达到了极致。 那么,接下
上一篇噢,我们搞明白了什么是安全的通信,这个很重要,特别重要,敲黑板!! 然后,我们还学了HTTPS到底是什么,以及HTTPS真正的核心SSL/TLS是什么。最后我们还聊了聊TLS的实
经过前两章的学习,我们知道了通信安全的定义以及TLS对其的实现~有了这些知识作为基础,我们现在可以正式的开始研究HTTPS和TLS协议了。嗯……现在才真正开始。 我记得之前大概聊过,当
这一篇文章,我们核心要聊的事情就是HTTP的对头阻塞问题,因为HTTP的核心改进其实就是在解决HTTP的队头阻塞。所以,我们会讲的理论多一些,而实践其实很少,要学习的头字段也只有一个,我会在最开始
我们在之前的文章中介绍HTTP特性的时候聊过,HTTP是无状态的,每次聊起HTTP特性的时候,我都会回忆一下从前辉煌的日子,也就是互联网变革的初期,那时候其实HTTP不需要有状态,就是个浏览页面
前面几篇文章,我从纵向的空间到横向的时间,再到一个具体的小栗子,可以说是全方位,无死角的覆盖了HTTP的大部分基本框架,但是我聊的都太宽泛了,很多内容都是一笔带过,再加上一句后面再说就草草结束了。
大家好,我是煎鱼。 在 Go 语言中总是有一些看上去奇奇怪怪的东西,咋一眼一看感觉很熟悉,但又不理解其在 Go 代码中的实际意义,面试官却爱问... 今天要给大家介绍的是 SliceHead
我是一名优秀的程序员,十分优秀!