导读

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

厂家选择：

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

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

国际化考虑

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

存储、计算、CDN

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

实测各大区的大致网络延迟：

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 .

在此输入正文