背景
PaaS平台支撑的设备数至少是千万级别的。相对于PaaS平台，单SaaS在设备数量上会少几个数量级，一般来说能支撑百万设备就是一个相当了不起的应用。今天我们就和大家分享一下，如何基于PaaS平台，构建一个百万设备支撑能力SaaS应用。主要从：用户账户体系、事件接收服务、统计分析服务、数据查询服务等几个方面进行说明。
SaaS的整体架构
、
SaaS系统离不开PaaS。规则引擎作为PaaS和SaaS的衔接者，起到了承上启下的作用。一个典型的SaaS系统，相对于PaaS，一般包括如下几个主要部分：事件接收服务、业务管理模块、Web Portal。其中，事件接收服务，主要负责接收来自PaaS系统的设备信息，包括基于物模型定义的：事件消息、上下线消息、属性上报消息以及业务层面的：设备生命周期消息等。涉及到开源中间件主要包括：OLTP数据库MySQL、OLAP数据库ClickHouse、消息中间件Kafka等。中间件选择这块，还是建议大家遵循一个原则：够用即可，SaaS系统不同于PaaS系统，我们必须保持系统的简洁及轻量级，无须引入过多的中间件。
用户账户体系
首先介绍下业务管理模块中的最基础也是最重要的功能，用户账户体系。良好的用户账户模型设计，易于扩展，能非常大的提升开发效率。这块可以参考下我之前写的文章，此处只有如下一句话做下总结：秉承租户间是隔离的和轻租户重组织两个原则进行模型设计。
事件接收服务
PaaS平台的规则引擎单机TPS能达到3000+，吞吐10万+。所以相应的SaaS系统的接收服务，性能也需要做相应的匹配。这块有几点需要注意的：
1、尽量避免OLTP数据的操作，如果真的是必须的，比如：状态更新，则更新操作必须走主键索引。
2、考虑增加中间层，将相关信息先放到消息队列中，然后通过消费者进行异步处理。
3、基于Nginx路由到后端微服务，别走微服务网关。
通过以上我们可以做到事件接收服务的独立性，通过消息中间件于后端服务的完全解耦，方便后续的维护和升级操作。
统计分析服务
人们都说，宇宙的尽头就是数据分析，所有系统建设的后期，尤其是生产类型的系统，最后都会去挖掘数据的价值，以支持商业决策。这这也是BI的使命。目前提的很多的概念：数字孪生、低代码、数据湖等，透过现象看其本质，你就会发现：对于数据处理的理论一直是没有变过。统计分析服务，主要包括：任务调度、数据计算、数据存储。对于SaaS平台，Clickhouse作为分析引擎，兼顾计算和存储的功能，绝对是你最优的选择。直接采用单分片多副本的部署方式，简单轻便。
对象存储或者文件服务建议采用Minio，支持s3存储协议。调度系统使用小海豚。消息中间件根据实际业务情况进行选择，日志存储相关的采用kafka。
数据查询服务
我们先看看业务上，查询的几个有代表性的场景。
1、点查询
最简单的一个场景，比如：我们通过用户唯一标识查询用户的详情信息。即使在MySQL中，如果走了主键索引，性能也是很高的，500+TPS还是很容易达到的。在MySQL等OLTP数据库中，需要重点关注锁场景，一般来说我们借助NOSQL数据库Redis，能大大提升点查的整体性能，减少对后端数据库的压力，基于内存的操作单机性能能达到10000+。
2、范围查询
范围查询，包括两部分：小范围、大范围。小范围类似查询最近10条告警这样的需求，大范围类似实时聚合分析，吞吐要求极高，io消费巨大。这个还是结合业务场景来选择实现方案。有时候也会从业务层面做相应的折中。比如：我们之前做SaaS应用的时候，有个印象很深刻的场景：我们想查询一批设备的最近1个月的设备告警信息，分页展示，每页10条左右。没有多余的查询条件，只是按照告警上报的时间进行降序排列取前10条。世界上没有银弹，不存在通过一种数据存储格式，来解决所有的业务场景。尤其是在开源世界里，我们只能结合场景选择不同的实现方式。最终，我们通过如下两点优化，来提升整个数据范围查询的整体TPS：
a)利用B+树的特性，使用MySQL来实现最近告警信息高并发的查询。
b)对于OLAP场景，可以通过增加CH副本的方式来进行提升整体查询QPS能力。
具体可以看下，我前端时间写的：告警查询及处理的优化之路，这篇文章。
网友评论