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，欢迎联系我们