本文會介紹一個真實的全球性的中等規模的app應用背後的技術選型與關鍵元件，涉及到高性能分布式系統、全球化網絡布局、大資料平台與資料分析等關鍵技術。
國内毫無疑問首選阿雲，國外aws當然是體量最大的，體驗也不錯，其實對ecs/ec2虛拟機、rds資料庫來說，基本功能、穩定性都相差無幾，規模優勢越來越明顯的情況下，如果沒有特殊考慮，基本木有考慮其他小廠的必要了。
aws/阿裡雲服務各有特色和短長，aws發力早，國際技術社群/第三方市場更成熟，阿裡雲也有自己的特色的、很實用的功能如drrs、截圖、轉碼、多媒體等。
主要還是對比阿裡雲和aws，aws國際化做的更早更徹底一些，布點也更多些，但以目前阿雲所覆寫的來說，也足以滿足絕大部分需求了，截止今日（2/13/2017）在巴西、印度等區域上，aws具備優勢，中東空白則是被阿雲填補（aws的土耳其也可以）。
實測各大區的大緻網絡延遲：
通常情況來說,如果不是廣告類等對延遲相當苛刻的系統，通常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
移動網絡-骨幹網延遲： 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，
絕對資料庫中間件的集大成者，不用懷疑不用猶豫，直接摸索玩去吧，不過想要把這玩意用好用到位，還是需要
此外我們還選擇了elastic search、amq 等元件，鑒于一些性能、持久化方面的考慮， 對于這類服務，選擇ssd 雲盤方式應該是更佳的方案，注意普通雲盤5~10ms的延遲、低iops，ssd雲盤或者混合方案大緻在1~2ms之間。
<a href="https://cn.aliyun.com/product/ecs?spm=5176.doc29682.416540.27.bulvxf">https://cn.aliyun.com/product/ecs?spm=5176.doc29682.416540.27.bulvxf</a>
基于以上選型與實作設計上的斟酌考慮等，在考慮擴充性的前提下，也可以達到數字化衡量每個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引擎等開發工作，目前在創業公司 小影（趣維科技）負責大後端團隊，限于技術能力、經曆與視野，不保證為最佳實踐，如有誤導，敬請諒解。
在此輸入正文