云上实践:轻松打造亿级用户的全球化高性能系统

本文涉及的产品
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云原生大数据计算服务 MaxCompute,5000CU*H 100GB 3个月
简介: 本文会介绍一个真实的全球性的中等规模的APP应用背后的技术选型与关键组件,涉及到高性能分布式系统、全球化网络布局、大数据平台与数据分析等关键技术。

导读

本文会介绍一个真实的全球性的中等规模的APP应用背后的技术选型与关键组件,涉及到高性能分布式系统、全球化网络布局、大数据平台与数据分析等关键技术。

厂家选择:

国内毫无疑问首选阿云,国外AWS当然是体量最大的,体验也不错,其实对ECS/EC2虚拟机、RDS数据库来说,基本功能、稳定性都相差无几,规模优势越来越明显的情况下,如果没有特殊考虑,基本木有考虑其他小厂的必要了。

AWS/阿里云服务各有特色和短长,AWS发力早,国际技术社区/第三方市场更成熟,阿里云也有自己的特色的、很实用的功能如DRRS、截图、转码、多媒体等。

国际化考虑

主要还是对比阿里云和AWS,AWS国际化做的更早更彻底一些,布点也更多些,但以目前阿云所覆盖的来说,也足以满足绝大部分需求了,截止今日(2/13/2017)在巴西、印度等区域上,AWS具备优势,中东空白则是被阿云填补(aws的土耳其也可以)。

存储、计算、CDN

存储和计算是云计算服务的基本配置,一些静态资源比如图片、视频等当然离用户越近越好,所以可以的话可以尽量选择所有的就近存储节点,而对于提供API服务的计算节点来说,通常需要涉及到应用服务器、数据库等的维护与构建,肯定是希望越少越好, 所以这就牵涉到一个权衡, 我们需要评估各个地域节点间的网络延迟问题, 目前国际间的网络通信主要是海底电缆: http://www.cablemap.info/
image_1b8qpe8on1qrc1iee1t1a155f14j59.png-760.8kB

实测各大区的大致网络延迟:
image_1b8qpg28jdkq48gc1jm4tuqum.png-73.8kB

digraph {

size = 7;
edge [dir = none]
node [shape = doublecircle];

cn[label = "China"];
sp[label = "Sigaphore"];
wa[label = "West Amer"];
ea[label = "East Amer"];
sa[label = "South Amer"];
gm[label = "Germeny"];

cn -> sp [label = "70~90ms" ];
cn -> wa [label = "150ms" ];
cn -> ea [label = "256ms"];
cn -> sa [label = "487ms"];
cn -> gm [label = "360~500ms"]

sp -> wa [label = "180~200ms"];
sp -> ea [label = "250ms"];
sp -> sa [label = "362ms" ];
sp -> gm [label = "203ms"]

wa -> ea [label = "70~90ms"];
wa -> sa [label = "185ms"];
wa -> gm [label = "167ms"]

ea -> sa [label = "140ms"];
ea -> gm [label = "93ms"]

sa -> gm [label = "195ms"]
}

通常情况来说,如果不是广告类等对延迟相当苛刻的系统,通常100ms左右的延迟是无感知的,
新加坡或者香港节点能够覆盖整个东方地域,美东节点则可以覆盖欧美西方地域,当然由于一些特殊限制等问题比如中国,肯定需要特殊处理的。

CDN 加速的问题, 对于图片、视频类静态资源,除了就近存储之外,为了最佳的体验性能,还需要进行CDN 加速服务,国内的网宿、阿里、高升等都是很不错的选择, 在海外的话,声势最大的当然是Akamai, 网宿
现在在海外的覆盖也是相当不错了,在大部分地区,个人测试基本无差别,国外还有家Fastly,服务和客户支持
也很不错,在海外市场,Fastly是类 AWS cloudfront、阿里云集中式数据中心CDN模式, 边缘节点覆盖上,还是不如网速、Akamai了,如果要求不是太高的话,也能满足业务需求了,另外特别点赞一下Fastly的系统管理页面和相关文档,应该算是其中做的最用心的了。

另外还有就是对于基本的普通的API请求,所谓的动态加速技术基本木卵用,自建代理长连接的方式倒是能减少一些延迟,如果是较重型的数据传输类API,动态加速类应该会有些效果。

所以基于以上考虑,大致可以形成以下全球化架构: 计算层 -》 存储层 -》CDN 加速

+++------------------------------
CDN Edge Server: 上千边缘节点
+++-------------------------------
存储层: 6~15个节点
+++------------------------------
计算层: 2~4个数据中心节点
+++------------------------------

网络性能参数

跨region:数据中心大区之间: 50~200ms
DNS 解析: 20~200ms之间,通常域名越热, TTL cache 命中率越高,延迟越低,国内通常20~40ms

       如果需要国际访问,比如dnspod是通过港美两地部署方式,基本都不是问题,阿云/AWS 也都有相关服务

移动网络-骨干网延迟: 2G> 3G> WIFI > 4G, wifi和4G通常在100~200ms, 2G/3G可能会是200~500ms

同一zone内网延迟:0.3~0.6ms
同一region不同zone网络延迟: 1~3ms

所以,以国内为例,移动APP 的最终API平均调用延迟,合理值应该在250~400ms之间,当然也会和用户群体分布,
比如一二线城市、偏远地区影响等相关。

一些APM厂家提供对终端网络体验的服务,比如tingyun就做的不错,阿里移动分析也支持此类功能,可以清楚
的分地域\国家看到最终的网络延迟体验, 甚至可细分dns解析、建联、下载等详细阶段情况。

在线服务选型

如果不是玩票或者其他方面的特殊因素,还是老实用Java吧,毕竟社区最丰富强大, 尤其牵涉到后期数据平台相关, Dubbo、spring、tomcat等也是老套选择。

MySQL RDS 当然是首选,同时阿云还提供了全球同步服务,虽然价格蛮贵,倒也的确省心省力很多。

Cassandra: 阿云没这个服务,鉴于其诸多方面的突出优势,让我们最终选择它作为MySQL 的补充来用。

扩展性是个需要深思熟虑的事情, 适合用 MySQL 单机模式解决的,肯定不做其他考虑,MySQL/PgSQL等也都提供了
分区表的功能,如果预期业务数据不大不小,可以考虑用此功能来搞定,如果单机模式真的搞不定,那就考虑用
Cassandra 或者 MySQL 分库分表模式哪个更合适,
放入Cassandra的数据具备高速读写、最佳扩展性,但也一定程度限制了查询的灵活性,一切还是得需要业务实际情况来最终权衡。

谈到MySQL 分库分表就有意思了,树新风(tree new bee)的Cobar,搞成了大杂烩的MyCat,还有360 折腾的Atlas功能也偏弱,总之没有足够靠谱的开源免费方案,直到阿云推出基于Cobar、TDDL倾力打造的DRDS,
绝对数据库中间件的集大成者,不用怀疑不用犹豫,直接摸索玩去吧,不过想要把这玩意用好用到位,还是需要
深刻的理解其原理的,cobar的文档和MyCat的pdf参考书都是很不错的资料 (http://mycat.io/ MyCat指南还是蛮有一些不严谨的地方,但总体还是很不错的)

此外我们还选择了elastic search、AMQ 等组件,鉴于一些性能、持久化方面的考虑, 对于这类服务,选择ssd 云盘方式应该是更佳的方案,注意普通云盘5~10ms的延迟、低IOPS,ssd云盘或者混合方案大致在1~2ms之间。
https://cn.aliyun.com/product/ecs?spm=5176.doc29682.416540.27.BUlvXf

基于以上选型与实作设计上的斟酌考虑等,在考虑扩展性的前提下,也可以达到数字化衡量每个API接口响应时间的目的, 通常情况下大部分MySQL请求应该在0~5ms之内,cassandra/AMQ 应该在0~2ms之内,内网调用延迟0.3~0.6ms, 外网调用30~50ms, els或复杂MySQL查询可能会有几十毫秒情况的出现,总体API 内延迟需要大部分落在50ms以内。

大数据方案

这年头大数据甚嚣尘上, 还有什么 Growth hacking等概念热炒的推泼助澜,市面上各种方案百花齐放闪花了狗眼,而数据收集肯定是第一步,
一个App 应用,其数据来源可以分两个:app 客户端日志、服务器日志。

服务端日志采集分析系统的开源标准,几乎就是flume+kafka+hadoop/hive/spark/hue 了,或者aws/阿云推出的EMR服务,阿云的 数加+maxcompute 是阿里内部呕心沥血自研并使用多年的系统, 用起来还是相当省事,基本上一个小同学花个一两周时间就把后台服务器日志等倒腾上去,可以随心所欲做各种查询、报表等等。(也可能和本人对这玩意太熟了有关。。。)

市面上也有各种基于APP埋点的数据分析产品,国内的umenggrowing-io神策等,国外的就更多了 GA/Firebase、flurry、mixpanel等等, 阿里移动分析(MAN) 也是类似产品, umeng/GA/flurry类产品的问题在于,它只能提供宏观的数据展示和分析,
但开发者无法拿到实际的真实数据做进一步的查询、分析, MAN 的伟大之处在于,"真正把数据归还给开发者"
即其通过中美两地部署采集服务的方式,再同步到到国内的 maxcompute , 借助于数加可以自由的做各种检索与分析,同时,如果你服务端日志也是同步到数加,那就非常方便的对客户端日志和服务器日志进行联合分析、join等,比如,我可以精细到对某一个userid,他在APP端做了哪些页面、版面切换,产生了哪些后台日志行为,即可以完整、全面的看到用户所有行为,一切尽在掌握!

所以单纯的 MAN 功能偏弱,但其和数加+maxcompute系统结合起来,整体上确实是一个简洁而美的解决方案,
MAN 也就是成为一个不可或缺的极重要组成部分。

在我们的实践上,基本一个web开发、一个数据开发折腾三个月,就初步捣鼓出了自己的数据平台、数据分析、业务数据报表系统。

同时数加平台上也提供各类算法、机器学习、推荐引擎等服务,基本都是阿里内部经久考验和优化的代码,有需要都可以随时开通使用。

总结

我们可以看到,在云计算的新时代,我们通过各种唾手可得的云计算服务,完全可以用最短的时间、最小的投入做到快速拓展全球性业务,
并保证高性能、低延迟、不亚于巨头公司的访问体验,同时通过开箱即用的大数据平台服务,更是能够做到对全球
用户提供高度智能化、精准化、个性化的优质服务。

利益申明

笔者曾在阿里数据团队做过高性能服务、数据库中间件、maxcomputer sql引擎等开发工作,目前在创业公司 小影(趣维科技)负责大后端团队,限于技术能力、经历与视野,不保证为最佳实践,如有误导,敬请谅解。

欢迎各类技术交流,微博: 孤独的登山人 http://weibo.com/windyrobin .

在此输入正文

相关实践学习
Serverless极速搭建Hexo博客
本场景介绍如何使用阿里云函数计算服务命令行工具快速搭建一个Hexo博客。
目录
相关文章
|
16天前
|
人工智能 安全 Cloud Native
阿里云云原生安全能力全线升级,护航百万客户云上安全
【重磅发布】9月20日,在杭州云栖大会上,阿里云宣布云原生安全能力全线升级,首次发布云原生网络检测与响应产品NDR(Network Detection Response,简称NDR)。同时,阿里云还宣布将持续增加免费的安全防护能力,帮助中小企业客户以极低投入完成基础的云上安全风险治理。
|
负载均衡
《云上社交行业技术服务白皮书》——第四章 云上社交保障与服务案例——4.2 社交流量潮汐性——4.2.3 云上成本优化(8)
《云上社交行业技术服务白皮书》——第四章 云上社交保障与服务案例——4.2 社交流量潮汐性——4.2.3 云上成本优化(8)
103 0
《云上社交行业技术服务白皮书》——第四章 云上社交保障与服务案例——4.2 社交流量潮汐性——4.2.3 云上成本优化(2)
《云上社交行业技术服务白皮书》——第四章 云上社交保障与服务案例——4.2 社交流量潮汐性——4.2.3 云上成本优化(2)
319 0
|
存储 弹性计算 运维
《云上社交行业技术服务白皮书》——第四章 云上社交保障与服务案例——4.2 社交流量潮汐性——4.2.3 云上成本优化(6)
《云上社交行业技术服务白皮书》——第四章 云上社交保障与服务案例——4.2 社交流量潮汐性——4.2.3 云上成本优化(6)
116 0
|
存储 弹性计算 运维
《云上社交行业技术服务白皮书》——第四章 云上社交保障与服务案例——4.2 社交流量潮汐性——4.2.3 云上成本优化(4)
《云上社交行业技术服务白皮书》——第四章 云上社交保障与服务案例——4.2 社交流量潮汐性——4.2.3 云上成本优化(4)
143 0
|
弹性计算 监控 Kubernetes
《云上社交行业技术服务白皮书》——第四章 云上社交保障与服务案例——4.2 社交流量潮汐性——4.2.3 云上成本优化(9)
《云上社交行业技术服务白皮书》——第四章 云上社交保障与服务案例——4.2 社交流量潮汐性——4.2.3 云上成本优化(9)
116 0
|
供应链 数据库 混合部署
《云上社交行业技术服务白皮书》——第四章 云上社交保障与服务案例——4.2 社交流量潮汐性——4.2.3 云上成本优化(5)
《云上社交行业技术服务白皮书》——第四章 云上社交保障与服务案例——4.2 社交流量潮汐性——4.2.3 云上成本优化(5)
120 0
《云上社交行业技术服务白皮书》——第四章 云上社交保障与服务案例——4.2 社交流量潮汐性——4.2.3 云上成本优化(1)
《云上社交行业技术服务白皮书》——第四章 云上社交保障与服务案例——4.2 社交流量潮汐性——4.2.3 云上成本优化(1)
378 0
|
存储 运维 算法
《云上社交行业技术服务白皮书》——第四章 云上社交保障与服务案例——4.2 社交流量潮汐性——4.2.3 云上成本优化(3)
《云上社交行业技术服务白皮书》——第四章 云上社交保障与服务案例——4.2 社交流量潮汐性——4.2.3 云上成本优化(3)
388 0
|
存储 负载均衡 监控
《云上社交行业技术服务白皮书》——第四章 云上社交保障与服务案例——4.2 社交流量潮汐性——4.2.3 云上成本优化(7)
《云上社交行业技术服务白皮书》——第四章 云上社交保障与服务案例——4.2 社交流量潮汐性——4.2.3 云上成本优化(7)
129 0
下一篇
无影云桌面