首页 体育 教育 财经 社会 娱乐 军事 国内 科技 互联网 房产 国际 女人 汽车 游戏

HelloTalk 基于 OpenResty 的全球化探索之路

2020-01-20

2019 年 12 月 14 日,又拍云联合 Apache APISIX 社区举行 API 网关与高功能服务最佳实践丨Open Talk 广州站活动,HelloTalk, Inc. 后台技能负责人李凌做了题为《HelloTalk 依据 OpenResty 的全球化探究之路》的共享。

李凌,HelloTalk,Inc. 后端技能负责人,专心在服务出海和依据 Golang/CPP 的 IM 服务及相关技能渠道的架构,5 年依据 OpenResty 服务办理和运用经历。

以下是共享全文:

大家好,我是来自 HelloTalk 的李凌,本次首要介绍 HelloTalk 做什么事务以及依据怎样的场景运用 OpenResty 和 Apache APISIX。

HelloTalk: 技能上看是依据全球的 Tiny 版微信

HelloTalk 是全球最大的外语学习交际社区,全球 1600 万用户经过 HelloTalk 和全球语伴学习 150 门外语、进行跨文化沟通及结交。用户广泛散布我国、日本、韩国、美、欧、巴西等国家,其间海外用户占 80%,从技能视点来看 HelloTalk 是一个依据全球的 Tiny 版微信。

HelloTalk 海外有许多 KOL 用户在 YouTube、Instagram、Twitter等渠道帮忙做推行,知名度较高,产品统筹谈天、改错、翻译等功用,用户能够边聊边语音改文字。其间语音改文字和翻译支撑 100 多种言语。

从运营层面看,许多企业出海时不知道怎样去做第一步,技能上也相同面对这个问题——怎样做到出海,并且为全球用户供给优质的服务。为了让每个国家的用户都能具有更好的运用体会,这儿就要不得不说到 OpenResty 给咱们带来的协助了。

如上图所示,HelloTalk 的用户散布很散,咱们需求找到最佳的平衡点,以性价比最优的方法布置衔接节点。亚太区域如韩国、日本,我国长三角和珠三角等地用户散布比较会集,比较好处理,但是在用户高度涣散的其他区域,对供给安稳牢靠的服务提出了较高的应战。

为什么运用 OpenResty

前期 HelloTalk 运用 C++ 写 IM 服务,其时是用到某大厂的高功能网络结构,协议都是内部拟定的,HTTP 协议都很少用。这对小公司而言本钱很高,假定内部写服务要曝露给外部运用,还需求自己开发 Proxy Server,而最新加的命令字要做适配,这就十分费事了。

所以从 2015 年开端,HelloTalk 开端引入 OpenResty,依据 OpenResty 在前面做署理,直接进行协议转化传到内部服务,减少了许多的本钱。

此外,服务简略露出给外部运用,会需求 WAF 的功用。咱们前期有些API 是依据 PHP 完结的,常常会由于结构原因被发现一些缝隙,导致一些黑客做各种注入和进犯,其间首要的方法便是 POST 各种 PHP 的关键字,或许在 URL 里边带着 PHP 关键字。

其时咱们在 OpenResty 里增加很少的代码后处理了这个问题,后来发现即便增加 WAF 功用,功能上也不会有太大的丢失。

TLV: 0x09+Header+Body+0x0A

前期咱们做 IM 开发都期望协议言简意赅,HelloTalk 的协议头也比较精简,悉数是 TCP 的协议体。比较有意思的是经过前后加两个特别的字节符号,界说中心的内容,即 0x09+Header+Body+0x0A,根本上能够确保数据包不会出乱。假如没有前后 0x09 和 0x0A 两个包,其实仍是有必定概率会发生错包的。

前期 HelloTalk 选用 TLV+PB 的协议方式,其时事务正快速开展,需求改成对外的reastful+JSON,第一步要做的是 PB 转 JSON。

而做协议解析遇到一个问题:OpenResty 运用的是云风写的 PBC 解析器,解析写起来十分费事,有必要要知道里层的结构。假定结构有三层,你得写三层判别代码,一层一层地把它抛出来。但后来发现 Apache APISIX 是依据 lua-protobuf,所以咱们也改成了用 lua-protobuf 库,它能够直接把一个 PB 目标直接转成了 JSON,十分便利。

协议的解析进程根本上是不断地读 socket,读到上图中的包头里的 Length 字段,再去读 body 段,这儿能够看出自己要完结协议解析比较费事,由于要对每个协议做适配。

咱们其时做完 C++ 的 IM 通讯服务后,看到干流的 IM App 如 WhatsApp、微信都有 Web IM,咱们很快的依据 OpenResty 对他们的协议进行兼容和改造,大约两周时刻,咱们就从服务端快速完结了一个 WebIM 版别的 HelloTalk。

和微信网页版别相同扫描登录谈天,根本不对协议做改动,只在中心增加一层 OpenResty 做 WebSocket 协议转化。

公共服务假如露出出去,会有人频频地给一切的人发音讯,因而咱们需求做音讯限流,这是直接依据 resty.limit.req 做的,当然 API 频率操控也是如此进行的。

做过 PHP 开发应该知道,一切的侵略其实是各种注入 PHP 的函数姓名、关键字。但当我把一切的 PHP 的函数名全放在 WAF 后,我再也没发现过被进犯,但在日志里发现许多,这说明悉数被阻拦了,到不了 PHP 那儿。

三步走:

1、纯 TCP 协议快速完结;

2、依据 Openresty 的 HTTP 服务露出;

3、API网关 加 Golang 微服务开发和办理。

国际化进程中的应战和问题

HelloTalk 用户散布区域十分涣散,需求想办法处理用户散布区域涣散的问题;

HelloTalk 国内大约有 20% 的用户,面对防火墙的问题;

海外言语环境和网络环境相同杂乱,言语适配问题难以处理。

怎样进步用户的全球接入质量

我比较过市面上许多服务商供给的计划:

1、阿里云全球加快,直接便是 4 层加快。

2、阿里云 DCDN 全站加快。

3、AWS的 Global Accelerator 计划。

4、Ucloud的 XPath计划 。

5、专线服务

6、Zenlayer。

但咱们需求考虑两个问题:本钱,实在的服务质量。

在处理跨境问题时,由于要考虑到国内 20% 的用户和公司总部地理位置,所以咱们是依据阿里云全站加快打开,原本是悉数用公网署理到香港阿里云,选用两头是 VPC、中心专线的方式,但有时分会遇到专线网络颤动导致延时进步的问题,所以在深圳做了依据 OpenResty 的网关署理。而实践情况是:假如专线不通就挑选走公网,公网延时大约 14ms,专线是 4ms。

这儿会涉及到上游检测,线路不通时需求快速的切换到别的一条线路,这部分问题是依据又拍云供给的 Resty 库在处理。

香港阿里机房到香港机房感觉其实是在同一个区域,由于咱们测验延时大约在 0.3ms~0.4ms。

关于海外其他用户,根本悉数是直接加快回到香港阿里,但直接加快会导致客户端的网络质量受地域问题影响严峻,所以咱们设置了一些 failover 的机制来确保用户的运用体会。

接入线路操控和流量办理

专线网络的带来的安稳性,例如欧洲到香港,延时:244 ms - 150 ms;

动态 upstream 操控 ,多服务商线路之间灵敏切换,确保服务的牢靠性;   

部分逻辑能够直接在边际处理,serverless ,serverless 这块咱们现在正则将其改形成 Apsche APISIX     + ETCD。

接入节点和质量把控

现在 HelloTalk 的接入节点首要散布在:美国东部,法兰克福,新加坡,东京,香港。美国直接到香港有可能会不通,此时会依照既定机制经转德国再回到香港,日本和韩国也是回到香港。巴西也有许多用户,但巴西云厂商只要 AWS 在做,根本上悉数是连到美国,假如连不通也会多个线路之间做挑选。这个环节其实是云厂商或许是 CDN 厂商完结,但实践发现总有一些区域做的并不好,所以为了确保用户体会不受损,咱们得有些 failover 机制确保多个服务商之间切换,确保用户的服务是牢靠的。

7 层和 4 层加快的挑选

许多服务商会供给 7 层加快和 4 层加快,但也会有一些问题需求处理。

4层加快: SSL握手时刻过长,简略失利,得不到客户端的 IP,不便利做节点质量计算。

4 层加快得不到客户端的 IP,,它在 TCP 的包里供给了此功用,也不是很友爱,假如打补丁出了问题,谁来负这个职责呢?

此外,监控质量也成了问题,咱们需求知道哪条线路行、哪条线路不可,虽然有切换机制,但咱们要知道它实在的通讯道路。事实上咱们在每个流量层署理时都会把实在 IP 带着跑,假如选用阿里云,那阿里云会帮咱们填到一个头里边去,不断地把客户端的实在 IP 带给下一个节点。

7 层加快: 不能确保 IM 服务需求长衔接坚持音讯的牢靠抵达

7 层加快的问题在于使得 IM 服务机制变成了 long polling 或许是短衔接轮循机制,但在实践进程中咱们发现它比较耗流量,并且 IM 服务需求长衔接坚持音讯的牢靠和及时抵达,但大部分 7 层加快厂商不支撑 WebSocket,单个支撑 WebSocket 的厂商边际卸载 HTTPS 又很贵的,尤其是国外的像 AWS 挺贵的。此外,假如云厂商边际节点宕机,会对用户形成比较差的影响,因而咱们就在多个云厂商之间的客户端做了许多 failover 逻辑设计,一旦毛病能够实在确保切换到别的一个节点,确保衔接质量。

多云环境下的全球接入的办理计划

支撑 websocket 的 7 层加快。

自建低速率的 VPC+专线通道。(性价比考虑,IM 本身流量并不多,只做告诉音讯下发)

长短衔接混合收发音讯:websocket+long     polling+httpdns + 内置 IP failover 机制

当然内置哪个 IP 到客户端也是一个问题,比方关于欧洲用户,其实肯定是要分配欧洲的 IP,那么首要咱们服务端要把欧洲的服务端 IP 存起来,怎样存?什么时分存?这儿咱们是经过云的 httpdns + openresty timer 机制分配、缓存、更新的,上图中的 IP 便是用户的实在 IP,这个时分 httpdns 服务商就会依据 IP 参数做域名的 IP 解析。

从自建 API Gateway 到深化体会 Apache APISIX

自建 API Gateway 完结假装动态化

咱们前期是直接改 nginx.conf,我自己觉得裸的 nginx 功能肯定是最高的。但问题是许多人不必定记住 Location 制造的优先级次序规矩,咱们也常常会改错。并且咱们的需求比较固定:动态更新 SSL 证书、Location、upstream,其时的做法相似现在的 K8S 的 ingress 更新机制,即经过模本生成:nginx_template.conf+JSON - PHP - nginx.conf - PHP-cli Reload 来完结动态化。但这个计划在遇到 Apache APISIX 之后能够考虑替换掉了。

Apache APISIX 成为 HelloTalk 的挑选:

本身需求比较简略,依靠 RDMS 觉得太重,带来额定的保护本钱;

代码极致简略易懂,在个人能力范围内,能够了解;

依据 ETCD,节约保护本钱;

项目首要保护者简直实时在线支撑,QQ 群、邮件呼应及时。

热门文章

随机推荐

推荐文章