一、車聯網行業特性講解
最近兩年車聯網發展受到政府部門、科研院以及各大互聯網巨頭的廣泛關注和積極推動。從應用來看，主要包括兩種模式：一是前裝模式（即車輛出廠前安裝），是乘用車廠主導或者與有相關能力的公司合作，例如上汽和阿里巴巴的合作。另一種就是後裝模式（通常是將車機設備安裝在汽車的OBD接口上例如各類汽車盒子等等。原理是利用智能終端（即車機）採集汽車OBD接口CAN總線上的所有原始數據進行診斷，數據分析，記錄行車信息，並將數據解析出其具體意義（汽車內部電控系統的各項傳感器數值）後通過串口輸出，供用戶讀取、解析、開發等使用。將讀取到的汽車內部運行數據通過手機APP軟件直觀展現。
首先大致梳理下車聯網行業的特性有哪些：
1、 月活非常高，在線時間長
車聯網行業用戶的月活是非常高的，這個很好理解，因爲汽車現在人們出行的必備交通工具，基本上只要一出門就會用車，一用車設備就上線並採集數據上報到平臺；每天3小時的平均在線時長，因城市擁堵程度不同而不同。
2、 早晚出行高峯比較固定
車聯網行業一個比較有規律的特點是早晚出行高峯比較集中。早高峯集中在早上6點至9點3個小時，晚高峯集中在17點至20點的3個小時裏。這樣會導致每天必須有6個小時左右的流量高峯。如何以較低成本應對早晚高峯是個比較現實的問題。
3、 節假日高峯流量難預測
現在國家法定節假日期間，由於高速公路在此期間免費的政策，導致越來越多的人們開始選擇駕車出行或出遊，所以每當節假日來臨時必然導致車聯網用戶暴增，這個洪峯流量來臨的時間和流量是不確定的。如何能準確做好每次節假日出行高峯預測是個問題。
4、 高併發，高容量，場景複雜
車聯網行業的用戶月活很高，早晚高峯比較集中的特性導致用戶併發非常高，每天平均長達3小時的車輛在線時長會導致採集數據量非常大，這也直接導致在數據採集場景下基本都是寫多讀少，但在羣組社交，朋友圈，用車報告等場景下是寫少讀多的。這樣複雜的應用場景對應用架構有很高要求。
5、 汽車技術更新頻率快
如今汽車技術更新越來越快，汽車廠商越來越多，廠商發佈的新車型的頻率也越來越高，車聯網企業對這汽車行業的新技術必須保持非常高度關注，必須加快版本迭代，提高研發效率才能及時應對汽車市場的變化，才能在第一時間解決和滿足市場和用戶的需求。
目前創業公司一開始就選擇了自建IDC機房，起初用戶不多，只用幾臺服務器，後來隨着產品越做越好，用戶高速增長，不到2年用戶規模達到了百萬級別，IDC機房的服務器也達到了幾百臺物理機，幾千臺虛擬機的規模。但是問題隨之也就越來越多。研究規劃下一代應用架構和基礎設施成了迫在眉睫的事情了，新的應用架構必須滿足快速增長的用戶量和爆發式的流量訪問，用戶體驗要好；並且基礎設施要做到可靠性高，穩定性高，安全性高，成本要低。傳統自建IDC方案是很難做到，即便做到成本也是非常的昂貴的。相比之下雲計算的各方面能力比較適合用來解決這些問題，所以上雲便是最佳選擇了。但是雲計算廠商有很多，國內有阿里雲，騰訊雲，金山雲等等，國外的有亞馬遜，微軟，谷歌等。如何選擇適合自己業務場景的雲計算廠家呢？ 我們做了大量的調查分析和對比，最終選擇了阿里雲。近幾年阿里雲的發展勢頭很猛，口碑也越來越好，產品功能豐富性在國內甚至是亞洲是最強的。上雲就上阿里雲，感覺很接地氣。
如果有對如何選擇雲計算廠家感興趣的朋友可以參考下面這篇文章，我覺得寫的不錯很客觀。文章鏈接：https://blog.csdn.net/mll999888/article/details/72851464#commentBox
言歸正傳公司決定選擇阿里雲作爲基礎設施，下一步就是如何將業務遷到雲上，於是有了這篇文章。該文章篇幅較長，部分引用可能忘記標出來源。
二、傳統IDC架構介紹及技術詳解
俗話說知己知彼百戰不殆，我們要上雲首先要充分了解自己業務和應用架構。然後在充分了解雲上產品的特性，看看哪些產品可以直接被我們使用，哪些是需要我們的應用或架構做出調整的。下面我們來分析下智能車聯網平臺的相關架構。
1、 業務架構
下圖爲公司業務架構圖。分爲三大業務平臺，其中核心是車聯網平臺，其次是能力資源平臺和第三方合作平臺。
車聯網核心平臺：主要包含應用層、支持層、物理層等功能，其中應用層包含功能有用戶註冊，用戶登錄，導航功能，車友功能，車輛檢測功能，軌跡查詢功能以及其他娛樂功能。這些是APP的核心功能。其次是支持層的功能，例如運營管理系統，用戶管理系統，車輛管理系統等輔助運營和運維的系統和工具。
能力資源平臺：是指的公司具備向外界提供的資源和能力，可以利用開放平臺將我們的能力提供給外部需要客戶和合作伙伴。例如車隊服務，數據應用，位置服務等等。
第三方合作平臺：是指通過調用第三方平臺接口來完成爲用戶提供部分功能，例如保險服務，違章查詢功能，停車位查找功能，4S店服務等功能。
2、應用架構
下圖爲應用架構，主要分爲客戶端接入層，負載均衡集羣，應用服務器集羣，緩存集羣，消息隊列集羣，分佈式服務集羣，數據存儲集羣，運維管控集羣等。
1.1 數據流介紹
數據採集：
首先通過車載智能終端設備收集汽車相關行駛數據，然後通過物聯網卡（即sim卡）上報到平臺，平臺經過協議解析服務將數據轉換成可讀的數據並進行存儲下來，並且需要把原始數據也保存一份。
數據處理：
將解析後的數據放到消息隊列中，後端的各種應用服務開始處理不同的數據，例如軌跡服務會去消息隊列中取出軌跡數據進行分析和處理。從而生成用戶的行駛軌跡等功能；再例如故障檢測服務，通過訂閱消息隊列中有關汽車傳感器數值進行分析和判斷該車輛是否存在故障。
數據分析：
部分行車數據經過各個模塊的處理最終保存在數據庫中，通過利用大數據分析進行特定場景的離線分析，例如駕駛行爲分析服務通過分析用戶每天駕駛行爲（例如急加速，急減速，急轉彎等行爲）來判斷用戶的駕駛行爲是否良好,等等。
數據展示：
用戶通過下載並安裝手機APP，註冊登錄App後用戶可以在APP 上查看自己車輛的位置，軌跡查詢，油耗，車輛故障以及交友，娛樂等功能。
1.2 應用架構介紹
防火牆：
當前在傳統IDC機房中應用的最前端是一臺防火牆，用來防禦一些常見的攻擊和訪問控制的操作。因爲防火牆並不是什麼高端防火牆所以防禦能力有限。因公司業務快速發展，期間已經更換過2次防火牆，分別是用戶規模在10萬和100萬的時候。每次更換防火牆對業務都會造成不同程度的停服時間。用戶體驗很不好，但是沒辦法因爲業務剛開始的時候用戶不多，系統設計之初爲10萬級別，用戶從0到10萬規模用了1年左右時間。但是從10萬到100萬用戶規模只有了7個月時間，用戶增非常快，無奈又更換防火牆到能支撐到500萬用戶規模。再這麼發展下去就不敢想象了。一是硬件設備成本越來越貴，往往投入幾十萬但是因爲業務發展超出預期，剛買來的設備使用不到1年，又面臨瓶頸又得換，真是費錢又費力。二是防火牆是所有業務的入口，如果防火牆出問題業務必然會掛，更換會導致業務停服，不更換防火牆會掛還是會停服。
負載均衡集羣：
四層負載均衡集羣採用LVS服務器，主要爲後端的協議解析和數據處理服務提供負載均衡功能，因爲單臺協議解析服務最大每秒只能處理10000臺車，所以lvs下掛了很多臺數據採集服務器。這樣可以滿足每秒海量車輛同時在線。
七層負載均衡集羣採用Nginx服務器，主要爲後端web應用服務器提供負載均衡和反向代理功能，此外Nginx支持正則表達式和其他功能。
這一塊我們目前遇到瓶頸是在IDC網絡帶寬擴容上，目前我們IDC機房如果對需要對網絡帶寬擴容需要提申請報備，內部走流程做完在到運營商那裏走流程，時間往往比較長，最快也要1-2天，無法及對網絡帶寬做到快速擴容，當然也就無法應對突發流量增長。如果長期購買大量閒置帶寬，本身是一種資源的浪費。畢竟目前國內優質的網絡帶寬資源成本還是相當高的。作爲公司的運維同學，如何爲公司開源節流，把每一分錢用在刀刃上是責任是義務更是一種能力。
應用服務器集羣:
應用服務器操作系統統一採用Centos7，運行環境主要爲JAVA環境和PHP環境，還有少部分Node.js環境
Java環境：採用Centos7 + JDK1.7 + Tomcat7
PHP環境:採用Centos7 + PHP5.6.11
Node.js環境：採用Centos7 + Node8.9.3
目前我們的應用開發語言有java 有php 有Python，web環境有tomcat，nginx，Node.js等環境，應用發佈自動化程度不夠高，大多還是腳本方式進行應用升級發佈。通常應用發佈升級工作都在半夜進行，加班非常嚴重。運維重複工作量非常大，導致運維成就感很低。大部分時間不是在解決問題就是在升級發佈過程中。沒有時間提升自身能力。運維人員開始陷入迷茫找不到方向，運維人員流失率逐漸增高，如果不得到有效解決，必將陷入惡性循環。
分佈式服務集羣：
分佈式服務集羣，採用Dubbo + ZooKeeper搭建的分佈式服務框架。其中zookeeper的服務器需要保持奇數目的是便於選舉。
Dubbo也是比較流行的JAVA應用的分佈式服務框架，它是阿里開源的分佈式服務框架。但是在使用過程中也發現由於沒有一個比較好用的Dubbo監控軟件，導致應用出現故障時排查故障很費力，如果有一套比較強大的鏈路跟蹤監控系統對於那分佈式應用來說是錦上添花了。
緩存集羣：
緩存集羣採用的Redis3.0 Cluster集羣模式，該架構中有10套Redis緩存集羣，每個集羣的內存從60G-300G不等。緩存服務器是典型的內存型主機，對CPU開銷不大，如果要做持久化，對磁盤IO要求較高，磁盤建議使用SSD。
對於緩存最大痛點在於運維，經常出現因磁盤IO瓶頸導致的redis集羣故障，以及因用戶快速增長需要經常對Redis集羣進行在線擴容等。而且Redis運維都是隻能是手動運維，工作量大，且容易誤操作。因Redis集羣而導致的故障不計其數。當然也跟當時的應用強依賴相關，Redis集羣故障就導致整個應用也掛了，這是應用系統設計的缺陷。
消息隊列集羣：
由於在高併發環境下，系統來不及同步處理，請求往往會發生堵塞，比如說，大量的insert，update之類的請求同時到達MySQL，直接導致無數的行鎖表鎖，甚至最後請求會堆積過多，從而觸發too many connections錯誤。通過使用消息隊列，我們可以異步處理請求，從而緩解系統的壓力。該架構中採用的是開源的Kafka作爲消息隊列，它是分佈式的，基於發佈/訂閱的消息系統。具有高吞吐率，同時支持實時數據處理和離線數據處理。
這個消息隊列的痛點也是刻骨銘心，kafka是開源軟件，曾經遇到幾次故障都是跟kafka有關係，在0.8.1，遇到kafka刪除topic的功能存在bug，隨後升級到09版本，不巧又遇到09版本kafka client的BUG，這個bug導致多分區多consumer時rebalancing可能會導致某個分區阻塞。後來升級kafka10版本，但是10版本的消費方式和08版本有差別，沒辦法又對消費程序進行改造。總之在我們使用kafka過程中遇到太多kafka的bug而導致的故障了。而我們中小企業技術能力有限沒有能力第一時間修復這種開源軟件的bug，處於非常被動和無奈的局面。
流計算集羣：
流計算採用的阿里巴巴開源的Jstorm，利用流計算平臺可以對實時數據進行處理和分析。該架構中使用2套流計算集羣，每個流計算集羣規模在8臺高性能服務器。並且每個集羣中包括2個supervisor管控節點，一主一備實現流計算高可用。流計算主要用於車輛告警，行駛軌跡等一些實時計算場景。
數據存儲集羣：
數據存儲集羣包含數據庫集羣和分佈式文件系統。
數據庫集羣又包含多種數據庫，例如MySQL數據庫集羣，MongoDB集羣，Elasticsearch集羣。
MySQL集羣：公司目前擁有幾十套大大小小的數據庫集羣，有的採用一主2從的高可用架構，有的是雙主架構，這些MySQL數據庫主要用於業務數據庫。隨着公司業務快速發展以及用戶規模的快速增長，對數據庫的性能要求也越來越高，從原來的高配虛擬機到後來的高配物理機，後來物理機的本地磁盤IO也滿足不了要求，接着就開始上給數據庫服務上SSD硬盤。現在勉強能維持着，在不久的將來，即便是目前最高配置的單臺數據庫服務器性能也不能滿足的時候，我們怎麼辦？數據庫團隊需要提前掌握和了解未來的解決方案是什麼，比如說分佈式關係型數據庫？
MongoDB集羣：公司目前有3套MongoDB集羣，主要用來存儲車輛上報的原始數據，和解析後的車輛狀態、點火、告警、軌跡等數據。採用的是副本集，通常由只是3個節點組成。其中一個是主節點，負責處理客戶端請求，其餘都是從節點，負責複製主節點上的數據。
Elasticsearch集羣：ElasticSearch是一個基於Lucene的搜索服務器。它提供了一個分佈式多用戶能力的全文搜索引擎，基於RESTful web接口。Elasticsearch是用Java開發的，並作爲Apache許可條款下的開放源碼發佈，是當前流行的企業級搜索引擎。該架構中ES集羣採用3個節點，這個3個節點都是候選主節點。這裏我們主要用於軌跡查詢，信息檢索、日誌系統等場景。
NFS分佈式文件系統：
因爲有大量的各類應用圖片和用戶上傳的圖片需要保存，所有需要一個高性能的文件存儲，這裏採用自建NFS分佈式文件系統。
但是自建NFS分佈式文件系統由於公司投入硬件設備有限，導致本身的擴展性是相當差的，而且需要停機相當影響業務。訪問速度因客戶端增加而變慢。這是個很影響用戶體驗的痛點，必須改造。
運維管控集羣：
在複雜的系統架構和海量的服務器環境中，需要合適的運維管控軟件來提升運維的工作效率。
監控：採用的是Zabbix開源監控系統；
代碼管理：採用gitlab進行代碼託管；
堡壘機：採用的是Jumpserver開源堡壘機，用於運維人員的操作審計和提升用戶登錄的安全性；
日誌查詢和管理：採用ELK，開源日誌系統；
持續集成：我們採用的是Jenkins，它是一款開源持續集成工具，利用Jenkins可以實現代碼構建，自動部署，自動測試等持續部署。
配置管理系統：提供應用的集中式配置管理，是基於java開發的配置管理。
雖然當前的運維體系還算比較規範，但是大多數運維工具都是開源的產品，只能滿足部分功能需求。隨着運維管控需求的增加，需要的熟悉的開源產品也越多。運維管理不夠統一，運維人員通常需要熟悉和掌握很多運維繫統，導致新手很難入手。
1.3 傳統IDC架構痛點
隨着用戶規模與日俱增，慢慢的這套架構也暴露出很多問題來。
痛點1：運維自動化程度低，運維工作繁重且無意義
我們公司運維大部分時間還是處於人肉運維，腳本運維時代，運維自動化程度低，原因一是公司業務發展太快，運維人員每天大部分時間不是在處理應用升級就是在解決系統故障，根本沒有時間去做運維自動的工作。其次運維開發方向的人才比較難招，也可能是開的薪水沒有競爭力。總之各種原因導致我們公司在運維自動化進程上比較慢，有惡性循環的趨勢。
痛點2：沒有彈性擴容縮容能力，應對流量高峯代價高
因爲車聯網行業的一個特點就是早晚高峯和節假日期間車輛在線率飆升，然後進入平穩期。一天24小時有6個小時是早晚高峯，其餘18個小時是正常流量，通常高峯期流量是平常的3-5倍。傳統IDC通常需要幾天時間才能完成一次線上擴容，根本不可能應對突發性的流量暴漲的情況。我們爲了保障系統穩定性以及保障用戶體驗，只能是投入比平時多幾倍的資源，整體資源利用率不到30%，產生巨大資源浪費。
痛點3：運維工具零散、運維工作複雜繁瑣
我們公司的運維管控軟件絕大部分是以開源爲主的運維軟件，種類繁多，例如開源跳板機Jumpserver，zabbix監控系統，持續集成Jenkins，自動化運維Ansible等等，這些軟件都需要配置獨立的登錄賬號。導致賬號繁多，管理非常不方便，運維人員需要操作和熟悉很多開源軟件。例如zabbix監控在規模不大的時候基本能應付日常的監控告警，但是隨着服務器的增加導致監控項的急劇增加之後，數據庫性能跟不上，告警延遲或者誤報的情況非常多。一些定製監控需求和監控項目仍需要單獨開發。所以運維工具種類繁多也直接導致運維工作的複雜繁瑣。
痛點4： 硬件設備採購週期長，成本高，擴展性差
我們公司應用剛上線的時候系統各方面的設計比較簡單，橫向擴展能力不強，隨着業務爆發式增長，因爲我們很多資源無法及時擴展，導致系統故障，用戶體驗降低。例如文件存儲，剛開始的時候我們是自建的NFS文件存儲，用於存放用戶頭像，駕駛證，朋友圈等圖片文件。由於各方面原因當初沒有投入足夠的資源建設，導致一段時間之後存儲就不夠用，讀寫性能下降，用戶訪問延遲等等。最痛的一點是硬件設備的擴展週期長，從提出採購需求到最後的實施硬件擴展，往往需要5-10天甚至更長，因爲這期間需要經歷採購審批流程，物流發貨，到貨驗收，機房上架等。
痛點5：基礎設施可靠性差，故障頻發
傳統IDC底層基礎設施通常都是企業自己搭建的，這裏會有很多原因導致底座基礎設施不穩定的因素。例如企業一開始對硬件投入不重視，使用廉價的設備；再例如工程師技術能力有限，搭建的基礎設施架構穩定性差強人意；例如遇到運營商網絡質量不穩定，也沒有BGP接入，這個時候也只能乾瞪眼了。另外我們的IDC機房一年當中遇到過3次意外斷電，導致大面積系統癱瘓。所以說底層基礎設施不穩定會導致後續應用經常出現莫名其妙的故障，而且無法及時定位，找不到原因。隨時會出現意想不到的問題，每天都是提心吊膽的。
痛點6：安全防護能力弱，易受攻擊
隨着公司快速發展和用戶規模的增長的同時，很容易被別有用心的人盯上，記得有一天下午3點左右，突然遭受到大量DDOS攻擊，我們的防火牆一下就被打垮了，系統瞬間就癱瘓了，沒有辦法，什麼都做不了，防火牆已經跪了，登不上去了，一直持續幾個小時，業務也癱瘓了幾個小時，一點辦法沒有。我們的安全防護能力真的很弱，也跟成本有關，高端的防火牆買不起，還有運營商的帶寬也很貴。
原文鏈接https://yq.aliyun.com/articles/632518?spm=a2c4e.11155435.0.0.a5a43312pX2g7n