开端
随着公司层面对产品方向的调整，最近团队进入了一个找方向的阶段，虽然大家都清楚我们最终要达到的目标是什么，但怎么到达那里却不是一件显而易见的事情，于是开了几天头脑风暴的会，列出了我们近期，短期，中长期要做的事情。其中一项内容是在近期要做一个 SAAS 平台，而这个平台的构架设计工作就是我这两天的工作内容。
设计思考
架构是面向问题，而满足需求的。所以第一步的工作是识别问题。我们要做一个 IOT 领域的 SAAS 服务，那么主要的问题有以下三点：
- 大量的链接
- 超大的数据量
- 多租户之间的数据隔离
识别问题之后，就是寻找方案来解决问题，目前业界并没有一个针对 IOT 领域的 SAAS 服务的参考架构，但针对大并发，大数据的问题，我们一般采用分布式集群来解决。
- 按连接数调整应用的实例
根据每个租户的设备连接数，为租户启动1～n 份应用实例。
但这样的架构有一个问题，有些租户的设备很多，但数据上报的频率低，而有些租户设备不是很多，数据上报的频率很高。对一个应用来说，计算量是跟数据量相关的，而连接数不能完全体现数据量，所以不能根据设备连接数来决定应用实例数量。
- 使用网关来管理连接和收发数据
统一使用网关来管理连接和收发数据，连接与应用实例解偶。虽然每条连接上传输的数据量有差别，但网关集群中每个网关上的连接是随机分配的，所以每个网关上收发的数据是比较平均的。
这个架构的问题是所有的应用实例和所有的网关都要保持连接，网关在收到数据时，需要选择转给哪一个应用实例，这样的多对多关系，限制了系统的伸缩性。
- 使用消息中间件解偶网关与应用程序
网关在收到数据之后，把数据扔到消息中间件中相应租户的消息队列里，应用实例启动之后，订阅相应租户的消息队列。
到这里这个简单的架构基本就出来了，使用分布式集群网关解决大量连接和海量数据传输的问题，使用分布式集群的应用实例来解决海量数据的处理问题，使用消息的订阅发布的不同主题来解决租户间数据隔离的问题。
但这里遗留了两个问题没有解决：
- 租户对应的设备数据量和用户请求数不匹配
- 租户的设备可能所属不同的租户的用户
对于第一个问题，系统应该分离设备数据处理逻辑和用户请求处理逻辑。而第二个问题应用可以根据数据归属设备来自行处理。但考虑到我们的 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 实践来开发，然而做为架构师，则需要在一开始就划清系统的范围，知道边界在哪里，系统间的关系是怎么样的。范围清晰了，才能识别全系统的问题集，才能谈概念完整性问题。
