車聯網上雲最佳實踐（二）

時間 2019-11-09

標籤聯網最佳實踐简体版

原文原文鏈接

摘要：咱們對傳統IDC應用架構進行分析以後，咱們發現以前的系統架構存在一些不合理的地方致使了不少的痛點，爲了解決這些痛點咱們最終考慮上雲。開始思考怎樣利用雲上產品來解決目前遇到的痛點。例如html

雲上對標架構及技術詳解
咱們對傳統IDC應用架構進行分析以後，咱們發現以前的系統架構存在一些不合理的地方致使了不少的痛點，爲了解決這些痛點咱們最終考慮上雲。開始思考怎樣利用雲上產品來解決目前遇到的痛點。例如前端

 爲了解決咱們自建IDC底層基礎設施可靠性差的問題，咱們改用雲計算服務，基礎設施可靠性，異地容災，數據備份，數據安全等問題不再用擔憂；web

 爲了解決存儲性能瓶頸以及用戶訪問體驗問題，咱們改用雲上對象存儲OSS服務+CDN；docker

 爲了解決單臺數據庫性能擴展瓶頸，咱們改用雲上的DRDS分佈式關係數據庫；數據庫

 爲了解決大規模的車機上報而致使數據寫入延遲問題咱們改用雲上IOT套件+HiTSDB；後端

 爲了解決平常以及節假日流量高峯的問題，咱們改用雲上彈性伸縮服務+按量付費，以最低的成本完美解決平常及節假日流量高峯；緩存

 爲了解決大數據存儲瓶頸以及下降大數據開發分析工做難度，咱們改用雲上MaxCompute + HBase；安全

 爲了解決運維自動化問題以及提升運維工做效率，咱們改用雲上codepipeine+雲監控+日誌服務+容器服務；服務器

 爲了解決安全防護瓶頸，咱們改用雲上雲盾+DDOS高防IP + web應用防火牆+堡壘機；網絡

 爲了解決負載均衡以及網絡擴容瓶頸，咱們改用雲上SLB；

 爲了下降上雲遷移複雜性，咱們改用雲上VPC虛擬專用網絡，IP地址能夠和原來保持不變；

 爲了解決數據遷移的穩定性和便捷性，咱們採用阿里雲數據遷移工具DTS；

咱們雲上新的應用架構即會兼容部分老應用架構的特性，同時會採用雲上新技術和雲上產品來解決咱們曾經的痛點和瓶頸。而且雲上新架構須要知足將來2-3年的業務發展規劃，可以支撐千萬級用戶規模的應用系統架構。下圖爲雲上應用架構圖。

一、雲上對標架構介紹

1.1安全：
安全這塊之前IDC機房的時候防範能力比較弱。爲了解決安全防護瓶頸，咱們改用雲上雲盾+DDOS高防IP + web應用防火牆+堡壘機；

能夠經過配置DDoS高防IP，將攻擊流量引流到高防IP，確保源站的穩定可靠。DDoS攻擊防禦峯值帶寬 20 Gbps ~ 300 Gbps 。同時，提供按天彈性付費方案，按當天攻擊規模靈活付費。
雲盾Web應用防火牆能夠防護SQL注入、XSS跨站腳本、常見Web服務器插件漏洞、木立刻傳、非受權核心資源訪問等OWASP常見攻擊，並過濾海量惡意CC攻擊，避免網站資產數據泄露，保障網站的安全與可用性。

關於DDOS高防IP和web應用防火牆產品介紹請詳見文章附錄第7.1&第7.2小結。

另外選擇用堡壘機來替換原來的開源堡壘機，相比開源的產品，阿里雲堡壘機多了一些審計合規，高效易用，多協議支持，追溯回放等功能。

1.2負載均衡集羣：
爲了解決負載均衡以及網絡擴容瓶頸，咱們改用雲上SLB負載均衡。阿里雲的SLB負責均衡提供四層（TCP協議和UDP協議）和七層（HTTP和HTTPS協議）的負載均衡服務。四層採用開源軟件LVS實現負載均衡，並根據雲計算需求對其進行了個性化定製。七層採用Tengine實現負載均衡。Tengine是由淘寶網發起的Web服務器項目，它在Nginx的基礎上，針對有大訪問量的網站需求，添加了不少高級功能。更多關於阿里雲負載均衡介紹請詳見文章附錄第2.2小結。

負載均衡實例規格選型：
根據當前業務量來看五百萬用戶，最高峯期間併發最大鏈接爲50萬，推薦使用
性能保障型規格5（slb.s3.medium）最大鏈接數50w，每秒新建鏈接數5w，QPS支持3w。徹底知足當下的企業需求，若是後續業務和用戶規模繼續增加，仍然能夠在線擴容到更高級別規格的SLB實例。若是將來達到千萬級用戶規模，須要大於100萬規格的實例能夠聯繫阿里雲客戶經理開通。

1.3應用服務器集羣:
應用服務器採用阿里雲ECS雲服務器，來部署應用環境。以前提到運行環境主要爲JAVA環境和PHP環境，還有少部分Node.js環境。
Java環境：採用Centos7 + JDK1.7 + Tomcat7
PHP環境:採用Centos7 + PHP5.6.11
Node.js環境：採用Centos7 + Node8.9.3
有2種方式快速構建應用運行環境：
1) 購買ECS服務器後安裝操做系統，而後手動部署應用環境，最後將應用環境構建成新的系統鏡像。
2) 購買ECS雲服務器後直接選擇雲市場的已經封裝好的應用環境鏡像便可。

產品選型
ECS產品根據業務場景和使用場景，ECS實例能夠分爲多種規格族。同一業務場景下，還能夠選擇新舊多種規格族。同一個規格族裏，根據CPU和內存的配置，能夠分爲多種不一樣的規格。ECS實例規格定義了實例的CPU和內存的配置（包括CPU型號、主頻等）這兩個基本屬性。根據此前車聯網行業特性來看，前端web應用推薦ecs.c5.xlarge（4核8G）規格實例，然後端應用推薦ecs.g5.xlarge（4核16G）規格實例。

1.4分佈式服務集羣：
分佈式服務集羣，延用Dubbo + ZooKeeper分佈式服務框架。採用7臺8核16G SSD磁盤200G ecs.c5.2xlarge規格ECS實例用於構建zookeeper集羣。Zookeeper集羣節點必須是奇數，由於在zookeeper集羣中只要有超過一半的機器是正常工做的，那麼整個集羣對外就是可用的。

1.5緩存集羣：
緩存集羣採用阿里雲數據庫Redis版，傳統自建Redis數據庫一般存在集羣節點擴容複雜，管理維護難等問題。因此咱們改用雲上數據庫 Redis 版來替代，它具備性能卓越，彈性擴容，數據安全性高，可用性高，秒級監控，簡單易用等優點。雲數據庫Redis版支持按量付費和包年包月兩種模式，按量付費可轉爲包年包月模式，反之則不能夠。可根據本身的需求自主選擇更多關於雲數據庫Redis介紹請詳見文章附錄第3.2小結。

1.6消息隊列集羣：
消息隊列採用阿里雲的消息隊列kafka服務，由於以前開源的kafka消息隊列也常常遇到各類問題，也沒有相應的能力去修復bug，選擇阿里雲的消息隊列服務以後就不用擔憂這些問題，由於阿里雲有一支專家團隊在維護它的平常穩定運行，如出現官方bug他們有能力第一時間修復bug。更多關於阿里雲消息隊列kafka介紹請詳見文章附錄第8.2小結。

1.7流計算集羣：
雲上流計算採用阿里雲的流計算服務，相較於其餘流計算產品，阿里雲流計算提供一些極具競爭力的產品優點，用戶能夠充分利用阿里雲流計算提供的產品優點，方便快捷的解決自身業務實時化大數據分析的問題。產品優點，例如強大的實時處理能力、託管的實時計算服務、良好的流式開發體驗、低廉的人力和集羣成本。更多關於阿里雲流計算介紹請詳見文章附錄第6.1小結。

1.8數據存儲集羣：
MySQL集羣:採用的是阿里雲數據庫RDS之MySQL版
阿里雲數據庫 MySQL 版是基於 Alibaba 的 MySQL 源碼分支，通過雙 11 高併發、大數據量的考驗，擁有優良的性能和吞吐量。除此以外，阿里雲數據庫 MySQL 版還擁有通過優化的讀寫分離、數據壓縮、智能調優等高級功能。當前 RDS for MySQL 支持 5.五、5.6 和 5.7 版本。請詳見文章附錄第3.1小結。
RDS與自建數據庫對比優點：
綜合性能對比

成本對比

HBase集羣:採用的是阿里雲數據庫HBase版
傳統架構中的MongoDBS用來存儲車輛上報的原始數據的，這些數據一般狀況下寫多讀少，原始數據的保存能夠有利於特殊狀況對問題的追溯。或者是數據丟失的狀況下能夠用原始數據來進行彌補。原來MongoDB集羣在達到必定規模以後性能出現斷崖降低，由於對MongoDB掌握不夠深，沒有正確使MongoDB致使。這裏改用雲上數據庫HBase版來替換原來的MongoDB集羣。HBase的高併發大數據量等特性很是適合海量數據存儲，業務大屏，安全風控，搜索等場景。

HBase主要優點有兩點：1）擴展性要強，HBase是專門的列式數據庫，具備高併發，低時延的處理能力，支持數據從200G~10PB都適合。數據存儲在HDFS，默認具有多副本可靠性和自動擴展能力。2）HBase是天生的hadoop生態系統中的組件，選擇HBase,就是選擇整個Hadoop生態。雲HBase自帶的Phoneix組件，支持SQL能力，二級索引等，很是適合IoT實時業務，而且支持帶少許更新的TP操做。HBase和MapReduce，spark自然的結合，同一份數據，支持實時業務的同時，能夠完成大數據的分析，以及還有時序組件OpenTSDB等。更多關於雲數據庫HBase介紹請詳見文章附錄第3.4小結。

爲何咱們不自建HBase而選擇雲數據庫HBase呢？雲HBase和自建

自建和服務更多的對比，能夠參考如下文章：
https://yq.aliyun.com/article...

Elasticsearch集羣：採用阿里雲的Elasticsearch
傳統自建Elasticsearch集羣存在性能不足，集羣節點擴容複雜，管理維護難度大等問題，所以咱們改用雲上Elasticsearch服務，它具備豐富的預置插件（IK Analyzer,pinyin Analyzer,smart Chinese Analysis Plugin,Mapper Attachments Type plugin等等），還包括集成X-pack插件提供企業級權限管控，實時監控等強大功能。它的特色和優點以下：
 分佈式的實時文件存儲，每一個字段都被索引並可被搜索
 分佈式的實時分析搜索引擎
 商業版X-pack插件，提供企業級權限管控、實時系統監控等強大服務
 可彈性擴展到上百臺服務器規模，處理PB級結構化或非結構化數據
 支持IK analyzer插件
 Elastic官方技術支持團隊7*24小時技術支持

1.9文件存儲集羣：
文件存儲：採用阿里雲對象存儲OSS
原來自建的NFS文件系統，在擴展和訪問速度方面隨着文件數量的增長響應也愈來愈慢，這一塊採用阿里雲的OSS+CDN解決方案，應用也須要進行小小的改造。
文件系統遷移改造方案請看2.2章節。
阿里雲對象存儲服務（Object Storage Service，簡稱 OSS），是阿里雲提供的海量、安全、低成本、高可靠的雲存儲服務。它具備與平臺無關的RESTful API接口，可以提供99.999999999%（11個9）的數據可靠性和99.99%的服務可用性。可使用阿里雲提供的API/SDK接口或者OSS遷移工具輕鬆地將海量數據移入或移出阿里雲OSS。數據存儲到阿里雲OSS之後，推薦選擇標準類型（Standard）的阿里雲OSS服務做爲移動應用、大型網站、圖片分享或熱點音視頻的主要存儲方式，也能夠選擇成本更低、存儲期限更長的低頻訪問類型（Infrequent Access）和歸檔類型（Archive）的阿里雲OSS服務做爲不常常訪問數據的備份和歸檔。更多關於阿里雲對象存儲服務OSS介紹請詳見文章附錄第4小結。

1.10 大數據計算平臺

大數據計算平臺：採用阿里雲大數據計算服務
智能車聯網平臺天天會採集海量車行駛數據，例如車輛發動機狀態，駕駛行爲，油耗，千米數，行駛軌跡等等，咱們須要對這些海量數據進行加工和分析。例如用戶天天行駛里程統計，油耗統計，用戶駕駛行爲月報告等等。因初期數據量相對較小，使用Kettle進行抽取數據等工做，ETL的工做大部分在MySQL數據倉庫中完成。多種數據源使用Presto（集羣）做爲查詢中間鍵進行相應的數據分析。但隨着業務的瘋狂增加，數據表單表達到數億後，磁盤容量達幾百GB時，數據要求的複雜度逐步提高，使用MySQL做爲基礎數據倉庫的基石已經不足以應付，常出現查詢響應時間等待過長，甚至內存崩潰致使執行失敗的狀況，極大的影響了工做效率。因此雲上咱們改用阿里雲MaxCompute大數據計算服務來構建咱們公司大數據開發和分析平臺。MaxCompute可以爲咱們提供了完善的數據導入方案以及多種經典的分佈式計算模型，可以更快速的解決海量數據計算問題，有效幫助咱們公司下降成本，並保障數據安全。Dataworks則提供了一站式的數據同步，數據開發，數據管理和數據運維等功能。更多關於阿里雲大數據計算服務介紹請詳見文章附錄第6.2小結。

1.11運維管控集羣：
以前的傳統運維，基本都是靠人肉運維，腳本運維，運維自動化程度很低，致使故障頻發，故障定位難，咱們的運維同窗大量時間花在了重複的升級發佈工做上，花在了填坑以及解決故障上，久而久之運維同窗自身發展受限，信心受挫，人員流失比例高的惡性循環的結果。咱們迫切但願這種情況能夠獲得較好的解決。對比以前大量採用開源的監控工具相比，大部分阿里雲的產品自己就自帶web控制檯，也有一些比較實用的運維管控產品，例如雲監控，堡壘機，數據管理，數據遷移，容器服務，域名等等。之前的運維痛點能夠經過阿里雲的運維產品能夠很好的獲得解決。
日誌管理：採用阿里雲日誌服務解決日誌收集，日誌分析，日誌搜索等問題。
阿里雲日誌服務是針對日誌類數據的一站式服務，在阿里巴巴集團經歷大量大數據場景錘鍊而成。無需開發就能快捷完成日誌數據採集、消費、投遞以及查詢分析等功能，提高運維、運營效率，創建 DT 時代海量日誌處理能力。具備全託管，實時性強，生態豐富，完整API等特色。更多關於阿里雲日誌服務介紹請詳見文章附錄第5.7小結。

彈性擴容：採用阿里雲彈性伸縮ESS，低成本解決平常以及節假日流量高峯問題。
在車聯網行業中有個比較明顯的行業特性就是遲早高峯是平時流量的3倍甚至更高，可是日常要應付這麼高併發的流量意味着資源投入也要3倍以上。在傳統IDC架構中，咱們一般是按照日常最高峯流量的1.2倍（1.2倍是爲應對特殊狀況預留的buffer）來準備相應的服務器資源，在平時資源閒置比較明顯，資源利用率不到30%，意味着日常可能100臺應用服務器就足夠了，可是爲了應對高峯流量不出問題咱們須要準備360臺服務器應對6個小時的高峯流量，其他18小時可能只須要100臺服務器。爲了確保系統穩定，提高用戶體驗，當時咱們只能投入比平時多幾倍的服務器資源。因此在雲上咱們採用阿里雲彈性伸縮服務，它是一種根據業務需求和策略，自動調整其彈性計算資源的管理服務。在知足業務需求高峯增加時無縫地增長ECS實例，並在業務需求降低時自動減小ECS實例以節約成本。更多關於阿里雲彈性伸縮服務介紹請詳見文章附錄第1.2小結。

域名管理：採用阿里雲域名服務，一站式解決域名購買，管理，備案等問題。
之前的老萬網被阿里雲收購以後，變動爲阿里雲域名服務，它集域名註冊、交易、解析、監控和保護爲一體的綜合域名管理平臺。更多關於域名服務介紹請詳見文章附錄第5.6小結。

持續集成：傳統應用升級發佈主要靠的人肉升級或者腳本升級，後來嘗試過利用開源的Jenkins+docker方式構建一個簡單的應用發佈系統，咱們但願到雲上能夠繼續保持這種發佈方式，因此改用雲上CodePipeline，阿里雲CodePipeline是一款提供持續集成/持續交付能力，並徹底兼容Jenkins的能力和使用習慣的SAAS化產品。它無需運維，開箱即用，全量兼容Jenkins插件，支持ECS，容器服務持續部署，快速上手。更多關於codepipeline介紹請詳見文章附錄第5.9小結。

容器管理：採用阿里雲容器服務，一站式解決容器生命週期管理及集羣管理問題。
阿里雲容器服務提供高性能可伸縮的容器應用管理服務，支持用 Docker 和 Kubernetes進行容器化應用的生命週期管理，提供多種應用發佈方式和持續交付能力並支持微服務架構。容器服務簡化了容器管理集羣的搭建工做，整合了阿里雲虛擬化、存儲、網絡和安全能力，打造雲端最佳容器運行環境。阿里雲容器服務能夠提供一站式容器生命週期管理以及集羣管理。更多關於阿里雲容器管理介紹請詳見文章附錄第5.5小結。

統一配置：採用阿里雲應用配置管理，傳統IDC架構中咱們的應用由於微服務架構的須要所有采用了的統一配置管理，將配置中心化管理，保存在zookeeper當中，經過一個web前端進行配置管理。應用經過本地客戶端向服務端請求配置。這樣作的好處是應用配置能夠集中存放，統一配置，方便管理。可是咱們的web配置管理中心提供的功能比較簡單，甚至不具有權限管理，配置快照，備份和恢復等功能。在雲上咱們改用阿里雲的應用配置管理ACM產品。雲上應用配置管理是一款在分佈式架構環境中對應用配置進行集中管理和推送的應用配置中心產品。基於該應用配置中心產品，能夠在微服務、DevOps、大數據等場景下極大地減輕配置管理的工做量，加強配置管理的服務能力。阿里雲ACM 是分佈式系統的配置中心。經過提供配置變動、配置推送、歷史版本管理、灰度發佈、配置變動審計等配置管理工具，ACM 幫助集中管理全部應用環境中的配置，下降分佈式系統中管理配置的成本，並下降因錯誤的配置變動帶來可用性降低甚至發生故障的風險。更多關於阿里雲應用配置管理ACM介紹請詳見文章附錄以及官方網站。

監控系統：採用阿里雲監控服務，傳統IDC架構中咱們的監控系統是自建的zabbix監控系統，隨着公司業務快速發展，監控項也急劇增長，由最初的500個監控項增長到3w個監控項，監控系統數據庫性能跟不上，查詢很慢，告警延遲和誤報的現象逐漸增多，監控需求愈來愈多樣化，定製化。傳統監控系統已經不能知足將來業務高速發展。因此咱們雲上改用雲監控，雲監控是一項針對阿里雲資源和互聯網應用進行監控的服務。雲監控服務可用於收集獲取阿里雲資源的監控指標，探測互聯網服務可用性，以及針對指標設置警報。雲監控對用戶提供Dashboard、站點監控、雲產品監控、自定義監控和報警服務。更多關於雲監控介紹請詳見文章附錄第5.1小結。

數據可視化：採用DataV，解決了運維大屏，監控大屏沒有UI設計問題企業多多少少有些大屏，在公司接待參觀考察工做時展現企業形象，企業運營，以及系統運行狀況等。爲了提高企業形象，有必要針對數據可視化部分進行美化。阿里雲的DataV 能夠幫助非專業的工程師經過圖形化的界面輕鬆搭建具備專業水準的可視化應用，讓更多的人看到數據可視化的魅力。DataV 提供了豐富的可視化模板，極大程度知足會議展覽、業務監控、風險預警、地理信息分析等多種業務的展現需求。更多關於阿里雲DataV數據可視化介紹請詳見文章附錄第5.2小結。

數據庫運維：採用阿里雲數據管理DMS，解決數據庫運維管理問題
阿里雲數據管理支持MySQL、SQL Server、PostgreSQL、MongoDB、Redis等關係型數據庫和NoSQL的數據庫管理，同時還支持Linux服務器管理。它是一種集數據管理、結構管理、訪問安全、BI圖表、數據趨勢、數據軌跡、性能與優化和服務器管理於一體的數據管理服務。更多關於阿里雲數據管理DMS介紹請詳見文章附錄第5.8小結。

1.12 嘗試新產品解決老問題
問題1：海量車機設備的接入致使網絡延時高，設備管理困難，安全性差
解決方案：阿里雲物聯網套件（iot套件），解決大規模車機管理，數據上報問題。
物聯網套件是阿里雲專門爲物聯網領域的開發人員推出的一站式設備管理平臺。性能強大的IoT Hub方便設備和雲端穩定的進行雙向通訊；全球多節點的部署讓全球設備均可以低延時與雲端通訊；多重的防禦能力保障設備雲端安全；功能豐富的設備管理能力幫助用戶方便進行遠程維護設備；穩定可靠的數據存儲能力方便海量設備數據存儲和實時訪問。物聯網套件還提供規則引擎與阿里雲衆多雲產品打通，用戶經過規則引擎只需在web上配置規則便可實現數據採集+數據計算+數據存儲等全棧服務，靈活快速的構建物聯網應用。更多關於阿里雲IOT套件介紹請詳見文章附錄。

問題2：車聯網大多應用場景對數據實時性要求很是高，可是目前在數據採集過程當中因爲數據庫寫入性能不夠，常常出現大量數據寫入延遲狀況。

解決方案：阿里雲高性能時間序列數據庫HiTSDB，解決海量數據寫入延遲問題。
爲何說時間序列數據庫能解決呢？
據有關機構測試發現一輛聯網汽車每小時能收集25GB數據。常規數據庫在設計之初並不是處理這種規模的數據，關係型數據庫處理大數據集的效果很是糟糕；NoSQL數據庫能夠很好地處理規模數據，可是它比不上一個針對時間序列數據微調過的數據庫。相比之下，時間序列數據庫（能夠基於關係型數據庫或NoSQL數據庫）將時間視做一等公民，經過提升效率來處理這種大規模數據，並帶來性能的提高，包括：更高的容納率（Ingest Rates）、更快的大規模查詢（儘管有一些比其餘數據庫支持更多的查詢）以及更好的數據壓縮。有興趣瞭解更深層次緣由的朋友能夠參考這個連接：
http://www.infoq.com/cn/news/...
https://qz.com/344466/connect...

阿里雲高性能時間序列數據庫 (High-Performance Time Series Database , 簡稱 HiTSDB) 是一種高性能，低成本，穩定可靠的在線時序數據庫服務；提供高效讀寫，高壓縮比存儲、時序數據插值及聚合計算，普遍應用於物聯網（IoT）設備監控系統，企業能源管理系統（EMS），生產安全監控系統，電力檢測系統等行業場景。
HiTSDB 提供百萬級時序數據秒級寫入，高壓縮比低成本存儲、預降採樣、插值、多維聚合計算，查詢結果可視化功能；解決因爲設備採集點數量巨大，數據採集頻率高，形成的存儲成本高，寫入和查詢分析效率低的問題。後續文章會詳細介紹HiTSDB性能測試內容。更多關於HiTSDB介紹請詳見文章附錄第。

問題3：車聯網行業是典型的大數據行業，有大量的大數據分析應用場景需求，可是自建大數據平臺成本高，維護困難，大數據人才很差招。
解決方案： MaxCompute + Dataworks + 雲數據庫HBase版
阿里雲大數據計算服務（MaxCompute，原名 ODPS）是一種快速、徹底託管的 GB/TB/PB 級數據倉庫解決方案。MaxCompute 提供了完善的數據導入方案以及多種經典的分佈式計算模型，可以更快速的解決海量數據計算問題，有效下降企業成本，並保障數據安全。
同時，DataWorks 和 MaxCompute 關係緊密，DataWorks 爲 MaxCompute 提供了一站式的數據同步，任務開發，數據工做流開發，數據管理和數據運維等功能，幫助企業專一於數據價值的挖掘和探索。普通開發人員也能夠勝任大數據開發任務。
雲數據庫 HBase 版（ApsaraDB for HBase）是基於 Hadoop 且100%兼容HBase協議的高性能、可彈性伸縮、面向列的分佈式數據庫，輕鬆支持PB級大數據存儲，知足千萬級QPS高吞吐隨機讀寫場景。阿里集團在10年開始研究HBase並使用在生產之中，目前阿里集團有10000臺左右的HBase機器，數百個集羣，服務數百個業務。是一款久經沙場的大數據產品。

問題4：單機MySQL數據庫遇到IO性能瓶頸和容量擴容瓶頸，若是業務和用戶規模繼續增加將面臨單機數據庫擴展困難。

解決方案：阿里雲分佈式關係型數據庫服務DRDS
阿里雲分佈式關係型數據庫服務專一於解決單機關係型數據庫擴展性問題，具有輕量（無狀態）、靈活、穩定、高效等特性，是阿里巴巴集團自主研發的中間件產品。DRDS 兼容 MySQL 協議和語法，支持分庫分表、平滑擴容、服務升降配、透明讀寫分離和分佈式事務等特性，具有分佈式數據庫全生命週期的運維管控能力。DRDS 主要應用場景在大規模在線數據操做上，經過貼合業務的拆分方式，將操做效率提高到極致，有效知足用戶在線業務對關係性數據庫要求。DRDS提供了豐富的功能:

 分庫分表
支持 RDS/MySQL 的分庫分表，在建立分佈式數據庫後，只需選擇拆分鍵，DRDS 就能夠按照拆分鍵生成拆分規則，實現數據水平拆分。
 透明讀寫分離
經過使用 RDS 只讀實例或者 MySQL 備機實現讀寫分離，幫助應用解決事務、只讀實例或者備機掛掉、指定主備訪問等細節問題，對應用無侵入，在 DRDS 控制檯便可完成讀寫分離相關操做。
 數據存儲平滑擴容
當出現數據存儲容量和訪問量瓶頸時，DRDS 支持在線存儲容量擴展，擴容無需應用改造，擴容進度支持可視化跟蹤。
 服務升降配
DRDS 實例能夠經過改變資源數量實現服務能力的彈性擴展。
 分佈式運維指令集
DRDS 提供獨有分佈式數據庫運維指令集，如 SHOW SLOW、TRACE、SHOW NODE 等指令，有助於快速發現和定位問題。
 全局惟一數字序列
DRDS 支持分佈式全局惟一且有序遞增的數字序列。知足業務在使用分佈式數據庫下對主鍵或者惟一鍵以及特定場景的需求。
 數據庫帳號權限體系
DRDS 支持類單機 MySQL 帳號和權限體系，確保不一樣角色使用的帳號操做安全。
 分佈式事務
DRDS 支持分佈式柔性事務，保證分佈式數據庫數據一致性。
 監控報警
DRDS 支持對核心資源指標和數據庫實例指標的實時監控和報警，如實例 CPU、網絡 IO、活躍線程等，幫助實時發現資源和性能瓶頸。

更多關於阿里雲分佈式關係數據庫DRDS介紹請詳見文章附錄第3.5小結。

二、數據遷移策略
2.1 數據庫遷移策略
數據庫遷移是整個上雲過程當中最重要的一環，難度也最大，由於咱們在遷移的時候要儘量的減小業務自己的影響，最好是不停機不中斷現有業務。須要制定很是詳細的計劃和遷移策略：
 遷移工具：推薦阿里雲數據傳輸服務DTS
DTS 是阿里雲提供的一種支持 RDBMS（關係型數據庫）、NoSQL、OLAP 等多種數據源之間數據交互的數據流服務。它提供了數據遷移、實時數據訂閱及數據實時同步等多種數據傳輸能力。經過數據傳輸可實現不停服數據遷移、數據異地災備、異地多活(單元化)、跨境數據同步、實時數據倉庫、查詢報表分流、緩存更新、異步消息通知等多種業務應用場景，助構建高安全、可擴展、高可用的數據架構。
DTS 支持多種數據源類型，例如：

關係型數據庫：Oracle、MySQL、SQLServer、PostgreSQL 、RDS For PAAS、DRDS、PetaData、OceanBase。
NoSQL：MongoDB、Redis 。
OLAP：ODPS、ADS、流計算。
 遷移時間：推薦在業務流量最低峯時段例如天天0點至5點

 遷移方法：
通常狀況咱們的業務數據庫都是有主備的，那麼選擇從數據庫做爲源數據庫對雲上數據庫進行同步，這樣作的目的是爲了減小對主庫的影響，有條件的話選擇單獨的從數據庫專門用做對雲上數據庫進行全量同步遷移。完了以後再切換到主數據庫開啓增量數據同步（利用DTS能夠輕鬆完成數據庫的增量同步）。這樣就能夠保證線下數據庫和線上數據庫的一致性了。具體遷移步驟請參考官方文檔：
https://help.aliyun.com/docum...

2.2 文件系統遷移策略
以前採用的是自建NFS文件系統用於存儲圖片和文件。隨着文件愈來愈多，圖片訪問速度愈來愈慢，搬到雲上以後，能夠利用阿里雲的OSS和CDN服務，構建以下的web端直傳OSS存儲方案，架構以下：

用戶的請求邏輯：
1) 用戶嚮應用服務器取到上傳policy和回調設置。
2) 應用服務器返回上傳policy和回調。
3) 用戶直接向OSS發送文件上傳請求。
4) 等文件數據上傳完，OSS給用戶Response前，OSS會根據用戶的回調設置，請求用戶的服務器。
5) 若是應用服務器返回成功，那麼就返回用戶成功，若是應用服務器返回失敗，那麼OSS也返回給用戶失敗。這樣確保了用戶上傳成功的照片，應用服務器都已經收到通知了。
6) 應用服務器給OSS返回。
7) OSS將應用服務器返回的內容返回給用戶。

利用阿里雲OSS存儲代替原來的自建NFS文件系統，優點很明顯：

OSS服務配合CDN 服務一塊兒使用，則能夠加速文件存儲和訪問速度，提高用戶訪問體驗。

CDN的工做原理就是將源站的資源緩存到各地的邊緣節點服務器（CDN節點）上，用戶請求訪問和獲取資源時，就近調用CDN節點上緩存的資源。這種分佈式數據傳輸方式，使得用戶請求的資源不須要都回源站獲取，從而避免網絡擁塞、分擔源站壓力，保證用戶訪問資源的速度和體驗。
使用CDN後的http請求處理流程以下圖