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

1、車聯網行業特性講解
最近兩年車聯網發展受到政府部門、科研院以及各大互聯網巨頭的普遍關注和積極推進。從應用來看，主要包括兩種模式：一是前裝模式（即車輛出廠前安裝），是乘用車廠主導或者與有相關能力的公司合做，例如上汽和阿里巴巴的合做。另外一種就是後裝模式（一般是將車機設備安裝在汽車的OBD接口上例如各種汽車盒子等等。原理是利用智能終端（即車機）採集汽車OBD接口CAN總線上的全部原始數據進行診斷，數據分析，記錄行車信息，並將數據解析出其具體意義（汽車內部電控系統的各項傳感器數值）後經過串口輸出，供用戶讀取、解析、開發等使用。將讀取到的汽車內部運行數據經過手機APP軟件直觀展示。

首先大體梳理下車聯網行業的特性有哪些：

一、 月活很是高，在線時間長
車聯網行業用戶的月活是很是高的，這個很好理解，由於汽車如今人們出行的必備交通工具，基本上只要一出門就會用車，一用車設備就上線並採集數據上報到平臺；天天3小時的平均在線時長，因城市擁堵程度不一樣而不一樣。

二、 遲早出行高峯比較固定
車聯網行業一個比較有規律的特色是遲早出行高峯比較集中。早高峯集中在早上6點至9點3個小時，晚高峯集中在17點至20點的3個小時裏。這樣會致使天天必須有6個小時左右的流量高峯。如何以較低成本應對遲早高峯是個比較現實的問題。

三、 節假日高峯流量難預測
如今國家法定節假日期間，因爲高速公路在此期間免費的政策，致使愈來愈多的人們開始選擇駕車出行或出遊，因此每當節假日來臨時必然致使車聯網用戶暴增，這個洪峯流量來臨的時間和流量是不肯定的。如何能準確作好每次節假日出行高峯預測是個問題。

四、 高併發，高容量，場景複雜
車聯網行業的用戶月活很高，遲早高峯比較集中的特性致使用戶併發很是高，天天平均長達3小時的車輛在線時長會致使採集數據量很是大，這也直接致使在數據採集場景下基本都是寫多讀少，但在羣組社交，朋友圈，用車報告等場景下是寫少讀多的。這樣複雜的應用場景對應用架構有很高要求。

五、 汽車技術更新頻率快
現在汽車技術更新愈來愈快，汽車廠商愈來愈多，廠商發佈的新車型的頻率也愈來愈高，車聯網企業對這汽車行業的新技術必須保持很是高度關注，必須加快版本迭代，提升研發效率才能及時應對汽車市場的變化，才能在第一時間解決和知足市場和用戶的需求。

目前創業公司一開始就選擇了自建IDC機房，起初用戶很少，只用幾臺服務器，後來隨着產品越作越好，用戶高速增加，不到2年用戶規模達到了百萬級別，IDC機房的服務器也達到了幾百臺物理機，幾千臺虛擬機的規模。可是問題隨之也就愈來愈多。研究規劃下一代應用架構和基礎設施成了迫在眉睫的事情了，新的應用架構必須知足快速增加的用戶量和爆發式的流量訪問，用戶體驗要好；而且基礎設施要作到可靠性高，穩定性高，安全性高，成本要低。傳統自建IDC方案是很難作到，即使作到成本也是很是的昂貴的。相比之下雲計算的各方面能力比較適合用來解決這些問題，因此上雲即是最佳選擇了。可是雲計算廠商有不少，國內有阿里雲，騰訊雲，金山雲等等，國外的有亞馬遜，微軟，谷歌等。如何選擇適合本身業務場景的雲計算廠家呢？ 咱們作了大量的調查分析和對比，最終選擇了阿里雲。近幾年阿里雲的發展勢頭很猛，口碑也愈來愈好，產品功能豐富性在國內甚至是亞洲是最強的。上雲就上阿里雲，感受很接地氣。
若是有對如何選擇雲計算廠家感興趣的朋友能夠參考下面這篇文章，我以爲寫的不錯很客觀。文章連接：http://www.javashuo.com/article/p-awewfgna-w.html

言歸正傳公司決定選擇阿里雲做爲基礎設施，下一步就是如何將業務遷到雲上，因而有了這篇文章。該文章篇幅較長，部分引用可能忘記標出來源。

2、傳統IDC架構介紹及技術詳解
俗話說知己知彼百戰不殆，咱們要上雲首先要充分了解本身業務和應用架構。而後在充分了解雲上產品的特性，看看哪些產品能夠直接被咱們使用，哪些是須要咱們的應用或架構作出調整的。下面咱們來分析下智能車聯網平臺的相關架構。

一、 業務架構
下圖爲公司業務架構圖。分爲三大業務平臺，其中核心是車聯網平臺，其次是能力資源平臺和第三方合做平臺。

車聯網核心平臺：主要包含應用層、支持層、物理層等功能，其中應用層包含功能有用戶註冊，用戶登陸，導航功能，車友功能，車輛檢測功能，軌跡查詢功能以及其餘娛樂功能。這些是APP的核心功能。其次是支持層的功能，例如運營管理系統，用戶管理系統，車輛管理系統等輔助運營和運維的系統和工具。

能力資源平臺：是指的公司具有向外界提供的資源和能力，能夠利用開放平臺將咱們的能力提供給外部須要客戶和合做夥伴。例如車隊服務，數據應用，位置服務等等。

第三方合做平臺：是指經過調用第三方平臺接口來完成爲用戶提供部分功能，例如保險服務，違章查詢功能，停車位查找功能，4S店服務等功能。

二、應用架構
下圖爲應用架構，主要分爲客戶端接入層，負載均衡集羣，應用服務器集羣，緩存集羣，消息隊列集羣，分佈式服務集羣，數據存儲集羣，運維管控集羣等。

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攻擊，咱們的防火牆一下就被打垮了，系統瞬間就癱瘓了，沒有辦法，什麼都作不了，防火牆已經跪了，登不上去了，一直持續幾個小時，業務也癱瘓了幾個小時，一點辦法沒有。咱們的安全防禦能力真的很弱，也跟成本有關，高端的防火牆買不起，還有運營商的帶寬也很貴。