Singleton之我见（一）
不知大家是否还记得两年前笔者曾贴出的一张照片（图片拍摄于Unicode Conference），期间列举了国际化前端生态圈中比较主流的框架，Globalize和Moment系数在列，笔者也曾花费不少笔墨对他们进行剖析。
本文开始，我准备和大家分享另外一个相对小众的国际化框架Singleton，相比于Globalize（GitHub 4.4k颗星）和Moment（GitHub 44.4k颗星），Singleton在GitHub上的星星目前仍不足百（https://github.com/vmware/singleton），在几位前辈大哥面前，绝对是咿呀学语级别。不过千万不要小瞧这位襁褓中的小兄弟，他有着“小娃撑小艇，独采白莲回”的雄心壮志。用GitHub上的原话说——Singleton is a service that provides support for Software Internationalization and Localization。可以看到这位小兄弟首先将自己定位在了service的角色上，并且可以提供i18n跟l10n这两个全球化服务，这下可是将自己的定位和国际化前端library的大哥们划出了清晰的楚河汉界。
理想很丰满，而现实是否会略显骨感呢？首先看Singleton是如何演绎他的全球化service角色，官微如是说——“Singleton的国际化功能使得开发人员不再需要学习各种技术和编程语言各自不同的国际化API。它充当抽象层，为用不同编程语言编写的各种软件产品提供了一致的国际化格式（例如日期、时间、数字和货币等）……提供了一个Web服务，通过API收集软件界面字符串以进行翻译。这些字符串在外部翻译完毕后会再次嵌入到Singleton 服务中。本地化资源与核心应用程序的解耦使得我们可以独立于软件产品的发布周期之外对翻译进行更新或添加新的语言支持……当应用程序被拆分为一组较小的互连服务时，每一个服务都会公开自己的API并使用其他服务提供的API……每个微服务独立运行……Singleton为这些微服务提供统一和抽象的全球化组件”。
开始划重点！首先可以明确的是Singleton基于微服务技术架构；其次他最大的特色在于解耦合，开发人员不再需要关注国际化二层的细枝末节；最后Singleton将本地化资源文件和过程与产品彻底分开，这的确是全球化领域内一个所谓“端到端”的解决方案，同时也是其他国际化框架没有涵盖的地方（大多都只是专注于某一方面，例如Moment就是在日期时区方面的翘楚，其余方面并未涉及，而涉及本地化的内容就需要引入另外的框架，例如ngx-translate，在同时引入多个国际化库时，通常会引发标准冲突）。
对于Singleton的优势和定位我们已经有了大概的了解，然后他的劣势何在呢？考虑到其微服务的架构，在实现过程中性能如何？安全性是否考虑周全？该框架在client端和server端分别作了实现，是否会让产品团队在引入Singleton时感觉繁复和量级过重？有喧宾夺主之嫌？另外既然Singleton将自己定位于一个大而全的全球化一体自动解决方案，是否又会带来新的问题，好似摊大饼，看上去覆盖面积很广，但每一处又都不够细致和深入呢？
怀揣着这些问题，让我们在未来的小文中一起细细研究并逐级展开吧。
以上是 Singleton之我见（一） 的全部内容， 来源链接： utcz.com/a/54087.html
