MASA Stack 1.0 實踐篇

產品智慧化

產品智慧化的改造怎麼做？

我們以採用運營商網路場景的物聯網架構舉例，如圖從左到右，在裝置端我們研發了一款淨水行業通用的物聯網盒子，它帶有各種感測器，如TDS、溫度、流量、漏水檢測、水壓等感測器，通過移動的蜂窩網路實現資料通訊，並有一定的邊緣計算能力，能實時收集資料並監測濾芯壽命，保障使用者用水安全。之後資料通過OneNET閘道器對接公用雲上的MASA IoT，也就是我們的 IoT中臺，它負責打通前臺小程式、裝置，以及MES、CRM等後臺業務系統，資料最終匯聚到數倉進行分析使用。

通過對家庭末端水質實時檢測、使用者用水習慣採集，不斷增強公司產品研發及售後服務能力；通過對大資料分析，建立濾芯壽命演算法模型，為每個使用者量身優化濾芯壽命，大大提升了使用者體驗；通過使用者畫像，為後續精準營銷，助力公司持續利潤增長。

功能架構圖

我們通過裝置接入>裝置安裝>裝置監控>耗材購買>訂單履約，5個環節完成了整個業務閉環

物聯網平臺

裝置接入主要通過我們的物聯網平臺，物聯網平臺有9大功能模組

首先裝置主控板在PCBA工廠家生產時需要先註冊到我們的IoT平臺上，然後通過檢測工裝完成各種線路板的可靠性的檢測，平臺通過裝置中心來管理所有註冊到IoT平臺的裝置，告警中心配置針對不同裝置和場景的分級告警，OTA模組可以管理裝置軟硬體版本，下發對裝置進行強制OTA或者使用者手動OTA等操作

產品中心可以管理各種產品型別和耗材，配置產品的使用者名單，產品各種韌體的繫結關係等

通訊協議定義了裝置與平臺的通訊資料結構，可以解析不同產品的協議欄位，平臺可針對特定欄位設定自定義的告警規則

SIM卡中心用來管理所有裝置的物聯網絡卡，監控流量消耗，監控賬單餘額等

模擬器就是用來協助軟硬體開發，在裝置沒有開發出來之前進行測試和驗證的工具。

業務端APP

裝置安裝是通過業務端App完成，技工使用裝置安裝模組提供的功能，通過藍芽或者4G等方式給裝置啟用，更換濾芯等操作

代理商可以在裝置管理模組下檢視他名下銷售的裝置

租賃業務管理租賃的合同，管理賬單和租賃的裝置等。通過客戶管理模組來管理終端使用者，維護使用者檔案

商機報備可以登記潛在客戶，並鎖定客戶

員工管理模組可以管理代理商的人力資源，包括技工，助理、業務員等角色

訂單管理就是檢視訂單的狀態，發貨收貨的跟蹤，退換貨等

產品中心就是檢視我們所有在售產品的宣傳資料，安裝視訊，產品手冊等

客戶端小程式

面向終端使用者的應用，採用無需安裝，開發成本更低的微信小程式實現

首先需要把裝置和微信使用者繫結，繫結之後就可以通過小程式的各種功能監控和控制自己的裝置，如果是商用機的租賃使用者，還可以通過租賃模組檢視租賃合同，檢視付款計劃

當然還有通用的一鍵報修和裝置維保的功能。針對雲商城的微信小程式，還有目前比較流行的直播電商和社交電商運營模式支撐

運營後臺

除了常規的完成耗材和商品的購買，完成出庫發貨，退貨，售後等訂單履約的行為之外，還有跟前端小程式配合的營銷運營管理和直播管理，後臺可以管理所有的會員，及財務管理功能。

MASA Stack 支撐場景

MC 訊息推送

從業務場景來講可以大體分兩類：

1、 配合告警的推送

因為告警支援分級處理，一般級別的告警，比如濾芯壽命即將到期，會以簡訊或者訊息推送的形式通知使用者，流量卡流量即將耗盡，會通知具體後臺業務人員，對於級別較高的告警，比如漏水告警，會觸發人工處理，水質異常也會通知後臺業務人員，可能還會通知客服人員聯絡客戶，收到水質異常的告警，後臺業務人員會通知負責該區域的技工上門維修檢測等等

2、業務訊息

例如工單任務分配，安裝派工，維修派工等就具體通知到負責對應區域的技工。例如商用機代理商買斷業務中，代理商在App進行安裝派工，技工將會收到App的通知和站內信。對外租賃業務中，當租賃繳費日期距離預設規定時間範圍內，自動給客戶傳送一條租賃繳費提醒簡訊等等

從開發角度來講 MC推送支援郵件，簡訊，站內信，App的訊息推送，在MC中配置好對應渠道的訊息模板和標題，然後就可以在業務程式碼填充模板並直接觸發推送，或者結合排程任務進行推送，和我們很熟悉的使用各大平臺簡訊模板的流程是一樣的

Scheduler任務排程

我們IoT平臺的淨水裝置包含很多型別，對於淨水器裝置排程各種壽命的計算和處理任務非常複雜，因為不同種類的濾芯，不同種類的裝置計算方式不同，對濾芯壽命到期或者剩餘壽命過低的處理策略也不一樣，租賃裝置需要鎖機，C端裝置需要上午10點定時提醒使用者。還有裝置的強制OTA升級任務，以及各個業務系統資料的同步。在雲商城專案中，還需要定時的去關閉超時的訂單等業務。

定期風控檢查場景，在雲商城專案中，我們經常會搞一些促銷的活動，有些使用者會利用我們各種優惠福利的漏洞，或者利用系統Bug，來薅平臺的羊毛，所以需要制定一系列的風控檢查規則，定期去檢查使用者的資料，發現異常及時通知業務人員。在IoT專案中，我們也會制定針對於裝置狀態的風控檢查，防止有人破解我們的裝置，或者裝置本身異常導致的頻繁上下線，大量消耗流量等情況。

我們對於任務排程的需求是非常多的，所以我們需要一種很直觀的方式觀測各種任務的執行情況，防止遺漏一些關鍵任務的執行，或者重複執行了一些任務。傳統的定時任務系統是缺乏除錯和驗證的手段，可能過了很長時間才發現某個任務並沒有按照當時設計的週期或者順序正確執行。

MASA Stack的 Scheduler可以靈活的配置各種執行策略比如任務的序列、並行，以及失敗後的處理方式等，任務的成功失敗我們不需要再看日誌，各種任務的進度和狀態都可以一目瞭然，可以很清楚的看到任務上一次執行的時間和結果以及下一次計劃執行的時間。並且Scheduler支援叢集的彈性擴充套件，如果資源壓力過大，只需要新增節點就可以了。所以無論你採用哪種開發語言和架構，現在無需在程式碼中編寫任務程式，在對應的業務場景中只需要通過HTTP或者Dapr的方式觸發即可，而且也不用擔心業務複雜問題，因為Scheduler支援上傳程式碼或者壓縮包的方式執行。

Auth許可權

我們的業務後臺頁面採用MASA Blazor實現，可以很容易的通過新增標籤的方式控制選單或者按鈕的許可權，將需要許可權保護的元素外層套上標籤即可。對於WebApi場景只需在介面新增特性並配置對應的使用者組或者角色即可。IoT後臺各種角色許可權的分配，只需要業務人員在Auth後臺進行簡單配置就可以，而且立即生效。Auth後臺配置選單許可權來控制使用者在業務平臺中可見的選單結構，也可以通過配置元素許可權來控制選單中的元素（按鈕、元件、佈局等），配置Api許可權來保護業務服務的Api。Auth可以很靈活的配置頁面的所有元素的許可權控制。

Auth對使用者的許可權配置分為擴充套件許可權、角色許可權、團隊許可權，比如可以在生產環境可以配置我們開發團隊只能看到系統的配置，但是無法看到具體的業務資訊，如果業務人員有需要，可以臨時賦予測試人員一些許可權，協助排查問題。解決問題之後可以立即關掉相關許可權。

Auth第三方平臺目前內建支援Github、LDAP，可方便對接任何實現OAuth協議的第三方平臺，支援熱更新功能，配置第三方登入後無須重啟服務。Auth還支援自定義登入註冊頁面配置功能，可以根據業務平臺的需求來配置登入/註冊視窗的元素，比如支援哪些第三方平臺登入、增加身份證號、郵箱、暱稱文字框等等，作為開發人員，只需要通過簡單的配置就可以實現功能豐富的登入和註冊頁面。

DCC業務配置

**1、****業務開關：**比如濾芯到期強提醒的方案的開關

**2、****系統配置：**比如SIM卡流量判斷閾值、指令下發重試次數，租賃到期需要提前幾天簡訊通知使用者等等。

DCC甚至可以靈活地切換環境配置，將開發環境一鍵切換到測試環境，切換到預釋出環境，節省了重新部署的時間。之前寫到配置檔案的內容現在都可以配置到DCC中，並且這些配置是立即生效的。DCC還集成了審計功能，所有配置的修改都可以進行跟蹤，我們可以查詢某個關鍵配置是哪個人在什麼時間修改的。

TSC應用故障排查

TSC我們現在社群還是預覽版，但是我們內部已經開始嘗試對接一下的業務場景，正在實施落地。之前用的是APM，現在正在嘗試對接並遷移TSC的預覽版。之前使用的場景經過驗證都是可以遷移到TSC的。

大家可能都有類似排查問題的經歷，有很多大公司尤其是外企，非常重視流程管理，這時候如果你的資料經過了多個業務系統，但又沒有使用類似TSC的平臺支撐，那麼你要調查具體的問題就很麻煩，你需要向多個系統的專案經理提出申請，讓他們安排具體的運維或者DBA甚至開發來協助你調查，如果涉及的資料存在涉密或者使用者的個人資訊，那麼還需要涉及到產品和業務人員簽字，那麼如果這個問題的優先順序不夠高，一個問題調查一兩週都是很常見的情況。下面舉兩個TSC的應用場景：

** 業務流程的跟蹤：**我們的專案採用微服務架構，有服務節點多，業務流程長的特點，TSC可以高質量的記錄每個請求和其上下文相關的內容，可以實時監控業務流程的進度和各個服務節點的效能，便於我們排查已知問題和發現未知問題。

舉個例子，比如我們發現某個裝置狀態和後臺記錄的不一致，我們可以通過TSC檢視這臺裝置的上報記錄，並篩選出這條記錄對應的整個鏈路的資料上下文，分析裝置是否正確上報了狀態，然後排查各個服務節點，通過檢視各個節點的輸入輸出分析出各個節點是否正確的處理了裝置的上報資訊，從而排查出具體的問題所在。

再舉個例子，我們發現後臺裝置狀態同步很慢，我們可以在TSC中篩選出這條記錄對應的整個鏈路的資料上下文，我們可以很直觀的看到，在哪個業務節點或者服務節點停留的時間過長，從而分析出整個系統的效能問題。

**日常巡檢：**我們可以通過定時在TSC中進行巡檢，發現各個服務的一些異常資訊並統計出發生次數和頻率，從而發現一些未知問題和風險，及時進行修復和預防，比如我們登入的圖形驗證碼或者簡訊傳送介面是否被頻繁呼叫，登入介面是否有存在被暴力破解的行為等等。另外我們還集成了Alert，一些致命錯誤和關鍵介面的錯誤會觸發告警規則。

還有，對於面向終端使用者頁面，監控對應業務介面的響應時間是很關鍵的，響應過慢會導致使用者使用體驗降低，TSC中的應用效能指標Apdex（使用者滿意度指標）。我們可以通過設定相應的閾值，然後結合實際響應時間來定義應用的效能表現，然後我們就可以分析出使用者對於不同頁面的滿意程度，如果Apdex值很高，代表就很滿意，相反就是不滿意或者完全不能接受，這樣我們可以有針對性的調整和優化我們的業務。

Alert故障告警

Alert主要是結合TSC使用，我們在IoT專案中針對裝置的告警型別比較多，大約有幾十項，比如各級濾芯的壽命告警，進水純水TDS值的告警，各種感測器故障告警，主控板、模組版、顯示板通訊故障告警等等。這些告警我們會在Alert中做分級處理，而且Alert支援告警恢復，這樣我們就可以直觀的看到哪些裝置發生了告警，並且哪些已經恢復了，哪些還沒有恢復需要人工干預處理。Alert還有一個沉默週期的配置，比如裝置缺水，裝置會週期性上報缺水的狀態，但是我們不需要關注每一條缺水的狀態，只需關心缺水告警開始和恢復的時間，這時我們可以通過設定這個沉默週期，讓裝置在觸發缺水告警之後的這個週期內不會再重複觸發告警。而且可以通過沉默週期，我們可以對裝置同一個告警設定多個告警級別。

.NET全場景開發

我想大家應該都用過IoT的產品，手機控制家裡的空氣淨化器，控制空調。IoT的開發和我們前後端開發應用是差不多的，傳統的網站開發是前端呼叫後端的介面，和裝置通訊是通過MQTT，也就是訊息佇列，一個釋出訂閱的設計模式。

產品開發流程

我們產品的整個開發流程分7個階段，首先會做產品定義，裝置長什麼樣子，有什麼功能，有什麼按鍵，螢幕顯示什麼內容。然後是軟體設計，設計我們的App、小程式、業務後臺的UI，設計我們的業務流程，最終對設計進行評審定版。下一個階段就是開發測試，按照原型和業務流程設計，開發我們的軟體和業務後臺，再測試。於此同時硬體也開發完成，就可以開始聯調，聯調不僅要和硬體進行聯調，還要聯調生產的整個流程，例如組裝過程中會有很多測試的環節，這些環節我們都需要記錄測試資料，以及對接一些返工或者維修的流程。比如某個感測器經過測試有問題，我們需要記錄並更換這個感測器。聯調測試完成後，就會進入小批試產環節，我們先試產少量裝置，這些裝置會分發給內部試用的使用者收集各種意見，收集意見之後會進行改進，然後將改進後的裝置再進行試產，分發到市場進行試用，市場試用階段完成最終進入量產。

.NET應用場景

這裡重點介紹一下.NET技術在其中4個階段起到的作用。首先我們在產品定義的最後一步會確定通訊協議。通訊協議是我們日後開發的基礎，通訊協議是與硬體裝置約定的通訊資料介面，就相當於我們前後端分離開發中的WebApi介面定義，裝置傳送指令後通過字串或者json的形式上報到MQTT，業務後臺再非同步的消費資料。有了通訊協議我們就可以在軟體設計的最後一步進行快速POC驗證，這個步驟主要驗證一些新的流程和實現方案，我們可以不依賴嵌入式工程師，完全通過.NET技術，使用nanoFramework或者.NET IoT庫通過esp32或者樹莓派來快速驗證我們的新流程或方案是否可行。關於感測器部分，國內外很多大神已經針對常用的感測器寫好了很多現成的包可以呼叫。但是如果你的感測器沒有現成的包，通過廠家的說明書、C、Python的示例，是很容易遷移到.NET平臺的，大部分都是GPIO的操作，通過配置引腳和高低電平，獲取感測器資料或者向感測器傳送指令。

在開發測試階段，我們使用.NET命令列開發一個通訊模擬器，模擬裝置接入MQTT並上報各種資料的場景，為我們後面針對IoT裝置功能的開發提供幫助，後面的硬體聯調過程也可以參照模擬器和通訊協議對裝置進行驗證，就像前後端分離的開發中的mock模式，使嵌入式開發和平臺層開發可以並行。

我們使用winform 技術開發工裝註冊工具，提供給PCBA廠家，通過串列埠將裝置資訊註冊到我們的IoT平臺和MQTT上。

開發階段會有App和業務後臺的開發，App我們使用的是MASA Blazor+Maui的方案，MASA技術團隊開展了一個實驗性專案，意在對微軟MAUI的補充和擴充套件，比如藍芽低功耗、條形碼二維碼識別、訊息推送、以及Android的自動更新等。基本覆蓋到了我們App開發常見的場景，而且驗證安卓的PDA也可用，最低支援到Android 9，iOS最低支援到15.3。業務後臺的開發使用的是MASA Blazor+MASA Framework+MASA Stack一站式解決方案，使用這套方案我們可以非常快速的搭建功能豐富的業務平臺。

檢測工裝，也是一個Winform上位機程式，主要是對裝置電控線路板進行可靠性和功能性進行半自動化檢測，同時記錄相關檢測資訊，為研發及品質人員追溯線路板故障問題提供資料支撐。比如驗證顯示屏和主控板通訊是否正常，藍芽和4G模組是否可以正常工作等。

硬體聯調階段有個步驟叫生產現場改造，由於產品的工藝有所不同，需要對產線進行不同程度的改造，比如使用PDA對裝置主控板和序列號進行繫結，通過藍芽或者4G傳送水檢，氣檢指令，藍芽改名，聯網測試等等。所有的涉及到的系統對接和PDA程式都是.NET開發的。

試產環節的資料驗證過程，主要是人工採集裝置的資料，比如水溫流速等，同PDA藍芽讀取的裝置資料或者裝置通過網路主動上報到IoT平臺的資料進行比對，驗證感測器和涉及到的演算法的準確性。

擴充套件APP MAUI

這裡列舉了一些我們App實現的功能，我發現群裡有不少從事IoT相關工作的朋友，之前是.NET 開發或者嵌入式開發，很少接觸移動端開發。如果你懂一些.NET技術，使用MAUI可以幫助你快速上手App的開發，物聯網常用的功能MASA技術團隊幫我們實現了，並有對應的示例。有興趣可以掃描下面的二維碼關注MASA公眾號，有相關的介紹文章。

案例展示

如圖是我們部分系統介面展示，包含我們的IoT後臺，使用者端小程式，雲商城小程式，和業務端App。這裡其實還有一個PDA的程式因為涉及到工藝流程，所以不方便展示。我們已經通過MASA Stack為底座全場景使用.NET技術完成了IoT平臺對數字化營銷和智慧製造的業務閉環。

如果您的企業是傳統制造型企業那麼可以參考我們的整套MASA Stack+.NET的解決方案，快速實現企業的數字化轉型。如果您是開發人員，並且現在也有類似的業務需求，那麼藉助於MASA Stack+ .NET的能力，可以快速的搭建一套IoT或者電商平臺。如果您是一位想上手App開發的愛好者或者從業人員，並且掌握一些.NET技術，與市面上其他的眼花繚亂混合開發技術相比，MASA Blazor + MAUI的方案技術門檻是最低，最容易實現。而且不要忘了您身後還有MASA技術團隊的全力支援！

掃碼觀看回放

---

如果你對我們的開源專案感興趣，無論是程式碼貢獻、使用、提 Issue，歡迎聯絡我們