設備生命週期服務平臺架構演進 二

設備生命週期服務平臺架構演進  二

一 背景與簡介

  某公司是氣體監測行業集研發，生產，銷售於一體的生產商，每一年都會生產知足不一樣需求的一些列型號設備，流往市場和安裝到客戶現場。按照每一年現場部署量10w臺爲基數，年15%增加計算，5年內設備量在100w臺之內。隨着互聯網時代到來，人類依照互聯網模式與物聯網結合產生了互聯網+，在這種背景下須要將設備有傳統的信息孤島轉爲遠程互聯，遠程採集設備生產的數據，以實際運行數據反推產品質量，擴展二次銷售，提高售後業務範圍。基於這些現狀所以迫切須要建設一個以設備爲核心的全生命週期的計算機服務平臺，該平臺涉及設備從無到有流經環節的信息採集，存儲，計算，管理，挖掘等方面業務的技術支撐。

  所謂設備生命週期是指從設備定型生產開始，庫存，訂單，物流，轉存，安裝，實際工做，維保，直到廢棄爲止的全過程，以該生命週期爲基礎展開一些列需求分析能夠得知，須要採集的信息由生產信息，庫存信息，銷售訂單信息，合同信息，物流信息，轉存信息，安裝信息，工做數據，維保數據等。在這些數據中最大最重要的數據是設備工做過程當中所生產的數據，他具備如下特色

1）數據量特別大

2）數據離散程度低

3）真實可靠

4）部分數據比較敏感

5）隨設備多樣性而呈現多樣性

  因爲設備採集具備普遍相似性，所以不該在設計上僅僅知足一類行業的設備，而應盡最大可能知足物聯網下全部設備的遠程數據採集兼容性設計，使得平臺能夠對接儘量多的不一樣的設備。

 

二 需求分析

  基於背景的分析，能夠從總體上已經明確需求的範圍和目標，所以進行加工分析得出

1）設備基礎信息管理

2）設備銷售數據管理

3）設備實時監控

4）設備維保服務

5）數據挖掘與大數據

 

三 設計

3.1 架構設計

3.1.1 早期架構

此階段採用的架構設計，存在的不足：

1）數據管理不完整，缺少設備全生命週期數據管理

2）服務層全部功能高度集成，高度耦合

3）設備接入層不可以知足高併發的數據採集

4）非分佈式架構，性能低下，難以擴展

5）設備兼容性設計丟失

6）技術老套，特別是app採用了很是不成熟的xamarin號稱跨平臺技術

3.1.2 微服務架構初期

因爲3.1.1架構因爲技術，人力，認識等歷史緣由形成的一些列問題，隨着發展而出現愈來愈多的矛盾，所以須要從新架構，其基本架構思路分佈式架構，業務垂直拆分，先後端分離技術，所以就有了如下局面

1）子系統劃分

SSO子系統，基礎數據中心子系統，銷售數據中心子系統，實時監控子系統，維保子系統，統計分析子系統

2）架構圖

SSO的引入解決了統一認證問題，其中統一認證包括了會話認證和權限認證，將這些非業務性功能點獨立出來，此時的平臺具備如下特色

1）儘量分離

2）數據庫分庫：基礎中心數據庫，銷售數據庫，實時監控數據庫，文檔數據庫，以及維保數據庫

3）先後端分離：相應的誕生了基礎數據中心前端，銷售數據中心前端，權限管理前端，實時監控前端，維保服務前端，微信公衆號

4）消息隊列：其實在第一次架構就已存在MQ，用於系統間消息流轉並進行消息依賴解耦，下降消息阻塞，提供系統響應能力

存在的不足：

1）高度分離化：這就帶來了數據庫的分佈式事務操做，這種通常在於垮庫數據讀寫時產生，前端高度分離化，其實一個子系統所涉及的前端頁面並很少，而分離化事後帶來的則是會話認證的跨域問題，固然這個已經解決，高度分離還帶來了系統交互的複雜性，好比原有一次性能夠主動獲取完成的，如今須要垮多個服務進行

2）通訊協議高度標準化：整個平臺對外統一使用http，restful風格api這在垮平臺統一性上沒有問題，可是服務之間也採用這些通訊協議，不免有點濫用，在微服務設計領域並不要求服務內部使用指定的通訊協議，而是服務內部之間採用實用簡單高效的通訊協議。

3）服務能力：並無涉及服務高併發，高可用，所以在服務集羣化，負載均衡化，緩存上徹底丟失，所以不足以支持大量設備高併發，高性能須要。在後期須要支持數據庫集羣化，採集器集羣化，監控集羣化，緩存集羣化，負載均衡化

4）不具入口統一性：爲何這麼說，第一從前端訪問webapi看，沒有統一的webapi網關來完成請求路由，負載均衡，服務發現，統一認證，限流處理，統一日誌記錄。從設備遠程接入看，沒有負載均衡器，所以當須要增長採集器時須要對遠程設備進行遠程主機地址配置

5）分層性：沒有嚴格按照分層化設計進行，缺少層次標準，缺少層次溝通，使得測試性極差，這就表現爲僅僅修改某個功能點測試須要徹底迴歸性測試

6）部署：部署不夠自動化，爲何這麼說，由於如今系統，或者說中間件比較少都採用人工拷貝，部署環境嘗試，在遇到問題後再解決問題

7）遠程採集：現有的遠程採集根本不能知足7*24小時服務，即服務不下線，且高度依賴io通訊配置等一些列粗陋，傳統，底下的設計方案。現有的io模型，經歷從協議，轉io變量模型，再轉設備數據模型，再轉前端聚合化模型

8）目標性：沒有設計目標，想固然，沒有分析過程，徹底依據我的經驗判斷，不具溝通性，每每是溝而不一樣，在認識深度，關鍵核心節點上沒法達成共識，缺少總體分析和把控能力

 3.1.3 微服務架構二次升級

因爲以上存在一些列問題，沒有設計目標等等很是多的問題，決心再次升級架構

 

 二次微服務架構升級具備如下特色

1）設計目標：知足千萬級設備同時在線遠程數據採集，知足百萬級終端用戶同時在線請求

2）服務高可用化：關係數據庫集羣化，緩存集羣化，消息隊列集羣化，api網關集羣化，監控服務集羣化，採集io集羣化，經過集羣化方式知足高併發，高可用，高度一致，高擴展能力。

3）入口高度統一化：整個平臺僅有2個入口，即終端用戶統一入口，設備端統一入口。同時對入口協議進行統一，終端用戶http協議，設備端tcp協議

4）高併發性：在統一入口的同時，進行負載均衡化

5）分離粒度合理化：前端將設備基礎數據管理，權限，銷售數據集成，減小客戶端維護。

6）嚴格分層化：用戶層，與應用層接口標準化，應用層與服務層接口多樣化且靈活適配，接入層與服務層解耦

7）服務能力：api網關，負載均衡的引入使得應用層有能力長期穩定運行，而且能夠根據開發進度合理安排服務上線，在負載均衡，消息隊列集羣可長期穩定運行，遠程採集通訊與業務分離使得在更改配置後不用服務下線便可完成更新

8）可配置化：全部運行參數均有配置中心統一管理，經過有效的消息通知和定時同步機制達到配置即時更新

9）軟件架構模式明確：明確的軟件架構模式，模型，分層式架構，其平臺類型與SAAS平臺相似

存在的不足：

1）因爲不少地方引入了新技術，集羣化，api網關，負載均衡對一些學習能力低下，理解能力差，經驗缺少的同事帶來知識，認證，理解能力等方面的巨大挑戰，特別是一些新技術處於linux環境下。

2）多租戶設計：這裏屬於徹底不考慮多租戶架構，也不是不考慮，而是現階段沒有精力，也缺少這方面的架構設計能力，所以在通過此番架構升級論證和成效基礎上引入多租戶架構設計

3）成本：因爲集羣化的引入可能會帶來必定的硬件成本投入

4）運維性：沒有太多的關注運維性，服務監控監管，運維工具方面丟失

 3.1.3.1 webapi網關

   webapi網關的由來，我的認爲他是多點服務的共性抽取，爲何這麼說？這得從他的結構和設計職能來理解。

webapi組成結構

1)路由：是將客戶端發送的http請求經過路由規則和算法，轉發到目標服務，並將結果返回給客戶端

2)負載均衡：由於後臺服務極有多是集羣發部署，天然的做爲服務統一訪問入口天然須要負載均衡，常見的負載均衡算法有6中，輪訓，加權輪訓，隨機，最小鏈接數，一致性hash算法等因具體場景而選擇

3)服務註冊與發現：因爲api網關會7*24在線化，而服務的上線是隨開發進度進行，所以須要動態上線，天然的api網關應提供服務註冊和發現接口，而且達到路由動態配置化

4)認證與權限：做爲api統一入口，他對全部接口訪問進行aop攔截，天然的能夠判斷用戶身份，權限驗證等進行集中化處理

5)緩存：對於某些靜態數據，進行緩存而避免無效的後臺服務反覆請求

6)日誌與異常：與認證，權限同樣，api網關應對訪問日誌和異常進行統一處理

7)api網關集羣機制：由於api統一了客戶端入口，天然的在知足高併發訪問時須要集羣化部署，所以須要支持集羣化機制

8)服務熔斷：api應對註冊的服務進行監控監測，同時處理一些災難性的服務對整個平臺的衝擊，好比某個服務響應緩慢，已經下線，性能低下，經過監控和熔斷等機制保障整個平臺正常運行，服務之間影響度降至最低

9)流量控制：流量控制這個就好理解了，其實這是一種自我保護機制

api網關在爲服務中起着很是重要的做用，他統一了客戶端入口，統一了交互協議，知足高性能，高可用，而且具備高度擴展性，維護性