IOT PAAS 平台设计的心路历程

开端

随着公司层面对产品方向的调整,最近团队进入了一个找方向的阶段,虽然大家都清楚我们最终要达到的目标是什么,但怎么到达那里却不是一件显而易见的事情,于是开了几天头脑风暴的会,列出了我们近期,短期,中长期要做的事情。其中一项内容是在近期要做一个 SAAS 平台,而这个平台的构架设计工作就是我这两天的工作内容。

设计思考

架构是面向问题,而满足需求的。所以第一步的工作是识别问题。我们要做一个 IOT 领域的 SAAS 服务,那么主要的问题有以下三点:

  • 大量的链接
  • 超大的数据量
  • 多租户之间的数据隔离

识别问题之后,就是寻找方案来解决问题,目前业界并没有一个针对 IOT 领域的 SAAS 服务的参考架构,但针对大并发,大数据的问题,我们一般采用分布式集群来解决。

  1. 按连接数调整应用的实例
    根据每个租户的设备连接数,为租户启动1~n 份应用实例。

但这样的架构有一个问题,有些租户的设备很多,但数据上报的频率低,而有些租户设备不是很多,数据上报的频率很高。对一个应用来说,计算量是跟数据量相关的,而连接数不能完全体现数据量,所以不能根据设备连接数来决定应用实例数量。

  1. 使用网关来管理连接和收发数据
    统一使用网关来管理连接和收发数据,连接与应用实例解偶。虽然每条连接上传输的数据量有差别,但网关集群中每个网关上的连接是随机分配的,所以每个网关上收发的数据是比较平均的。

这个架构的问题是所有的应用实例和所有的网关都要保持连接,网关在收到数据时,需要选择转给哪一个应用实例,这样的多对多关系,限制了系统的伸缩性。

  1. 使用消息中间件解偶网关与应用程序
    网关在收到数据之后,把数据扔到消息中间件中相应租户的消息队列里,应用实例启动之后,订阅相应租户的消息队列。

到这里这个简单的架构基本就出来了,使用分布式集群网关解决大量连接和海量数据传输的问题,使用分布式集群的应用实例来解决海量数据的处理问题,使用消息的订阅发布的不同主题来解决租户间数据隔离的问题。

但这里遗留了两个问题没有解决:

  • 租户对应的设备数据量和用户请求数不匹配
  • 租户的设备可能所属不同的租户的用户

对于第一个问题,系统应该分离设备数据处理逻辑和用户请求处理逻辑。而第二个问题应用可以根据数据归属设备来自行处理。但考虑到我们的 SAAS 服务针对的是工厂或者企业,不面向消费品市场,所以可以不考虑用户访问量大和设备归属不同用户的问题。

架构师的格局

第二天当我把这份设计拿给我们的首席架构师时,他问了我一个问题:为什么要做一个 SAAS 服务。其实在我们的方向和规划里,我们最后会是一个 IOT 领域里的 PAAS ,而 SAAS 只是我们在这个方向上的第一步,起到技术积累的作用。我们的 PAAS 也可以通过多个 SAAS 间相同功能模块下沉而不断丰满起来。

首席架构师说道:路线没什么问题,但做为架构师,眼界不能只放在眼前。既然你们决定要做一个 PAAS 平台,那么一开始你就要划清楚 PAAS 的范围,哪些是 PAAS 的职责,哪些是 SAAS 的职责。所以你应该先出一个 PAAS 平台的架构图。

PAAS 平台架构设计

根据 Gartner 的定义, PAAS 分为 aPAAS 和 iPAAS 两类。对于 aPAAS,开源世界现在已经有比较成熟的解决方案了。基于 kubernetes 和 deis 完全可以定制出一个满足以下需求的 aPAAS 。

  • 应用的隔离,每个应用独立的运行环境(基于容器技术: docker)
  • 易于更新应用程序,部署友好(基于 deis)
  • 应用的高可用,应用故障后自动重启(基于 kubernetes)
  • 应用的在线伸缩性,不停机下增加或减少应用的实例(基于 kubernetes)
  • 应用的监控,报警 (基于 Heapster)

接下来是 iPAAS 的部分了。做为 IOT 领域,首先要解决的就是应用与设备的通讯问题。这个部分在前面 SAAS 部分已经说过了,接下来要思考的是还有哪些服务是 PAAS 应该包含的。

  • 会员服务
  • 鉴权服务
  • 存储服务
  • 消息中间件
  • 消息推送服务

以上五种服务是一个通用应用程序会需要用到的服务,而跟 IOT 关系的体现则是在具体设计这些服务时要重点考虑的问题。

领悟

产品或者项目可以按照敏捷的思路推进,程序也可以按照 TDD 实践来开发,然而做为架构师,则需要在一开始就划清系统的范围,知道边界在哪里,系统间的关系是怎么样的。范围清晰了,才能识别全系统的问题集,才能谈概念完整性问题。

推荐阅读更多精彩内容