PaaS千百种，不要傻傻分不清

PaaS（Platform as a Service）是指云计算领域的平台即服务。

根据Gartner，截至2019年整个PaaS市场蓬勃发展，已经有360多家厂商，在21个品类下提供550多种云平台服务。Gartner将PaaS平台分为两类：一类是应用部署和运行平台APaaS（applicationplatform as a service)，另一类是集成平台IPaaS（integrationas a service）。

海比研究则将PaaS分为六大类，一是应用开发、部署和运行平台APaaS；二是集成平台IPaaS；三是IaaS延伸性PaaS基础服务平台IaaS ；四是物联网服务平台IoTPaaS；五是人工智能服务平台AIPaaS；六是其它类PaaS。

按笔者的理解，既然PaaS是为SaaS服务的底层平台，PaaS的类别应该以为SaaS提供不同的服务来划分。笔者把PaaS分为三大类：第一类，为SaaS提供全套云端的开发、部署、运行工具，这一类叫APaaS(application platform as a service)。第二类，为SaaS提供运行、维护和营运环境，这一类叫IPaaS（integration platform as a service）。第三类，为SaaS提供一些特殊功能接口服务，这一类叫FPaaS（function platform as a service）。

1、APaaS

早期的SaaS开发都使用很传统方式，一般分为以下几步：

第一步：选择系统架构及技术框架。根据项目的规模以及团队的能力选用一种系统架构，例如：单体架构、分层架构、总线架构、微服务架构等。再根据系统架构选用一些流行框架，比较流行的如：JAVA语言框架spring boot、spring cloud；PHP语言框架ThinkPHP、YII、CodeIgniter；NODEJS语言框架express等。也有几种框架同时混合使用的案例。

第二步：选择编程语言及开发工具。开发一款SaaS，一般根据模块的功能和层级可能选用不同的语言开发，底层模块更重视运行效率，一般选用例如：C、C 、RUST、GOLANG等，业务层模块更重视开发效率，一般选用例如：JAVA、PHP、NODEJS、PYTHON等。具体选哪种语言还与选择的框架，以及团队以往的偏好有关系。

使用的也是传统流行的开发工具，根据使用的编程语言不同稍有差异，最流行的开发工具有：Eclipse IDE、MyEclipse、Intellij IDEA、NetBeans等。

第三步：选择中间件以及开源模块。不同的系统架构，选择中间件也大不一样。中间件是整个技术架构中最复杂的部分，包含以下几种类型：关系型数据库、持久层框架、缓存数据库、非关系型数据库、搜索、反向代理、消息中间件、监控、日志收集、分布式、配置中心、容器化、容器编排、链路跟踪。

中间件使用最多的是微服务架构，最多可超过30到40个中间件。组织、使用、部署、维护这些中间件是个非常大的工作量，特别是业务升级后如何保证中间件的同步升级存在很大不确定性。

SaaS应用传统开发模式的复杂性，促使互联网公司推出第一代APaaS，这一类APaaS是仍然采用传统计算机编程语言进行开发、部署和运行，并提供更集成化的在线开发工具，以及大量中间件的调用接口，开发效率得到了一定的提升。典型代表有：微软的Azure App Service、亚马逊的Amazon Web Service、阿里的云效、腾讯应用开放平台、华为软件开发平台(DevCloud)等。

近两年，第二代APaaS（低代码开发平台）开始出现，这类开发平台通常采用表单、流程或模型加少量代码就可以应用开发，替代了原先代码式编程语言的模式，开发效率比第一代有明显提升。这类平台由于采用技术方式差异很大，面向的使用人群，以及使用范围也有很大差异。根据采用技术的差异笔者把低代码开发平台再细分为三大类。

第一类是纯表格和流程驱动，无需编写任何代码的无代码模式。这类APaaS通过建立多张表单，使用流程串联，定义报表输出方式，构建表单类轻应用。该类模式的技术壁垒不高，主要支持开发表单类应用，场景有一定局限性。更适合简单短期项目，不适合长期的循环迭代产品的开发，尤其产品要面对多样性需求，必须具备高配置属性的时候。比如表格展示，同一个流程不同职位看到的表格都是一样，涉及到敏感信息不能区别展示，无法实现千人千面。这类平台有：轻流、云表、简道云、搭搭云、阿里的宜搭、宜创科技等。

第二类是贫血模型驱动的低代码模式。底层技术涉及云原生、元数据、多租户等。该类模式的技术壁垒较高，颗粒度更细，复杂度、灵活度更高，能够支持广泛场景的复杂应用开发，具备服务大客户和中小客户的能力。这类模式在面对复杂场景时，仍然需要编写逻辑代码。特别是在面向高并发应用场景，需要投入大量的后端软件开发。这类平台有：OutSystems、Mendix、奥哲网络（氚云）、ClickPaaS、炎黄盈动、数式科技、黑帕云等。

第三类是领域驱动的图形码模式。这类平台完全由模型驱动，可不用编写任何代码实现各种复杂场景的应用开发。无论前端组件还是后端业务逻辑都能细粒度搭建，实现高度复杂、高度灵活的应用场景。这类平台的后端部分属于领域驱动的设计模式，其核心概念：域、子域、领域实体、值对象、领域服务、领域事件等是天然的图形化解决复杂问题的表达模式，面对任何复杂应用场景都能支撑APaaS的可视化搭建，并能可视化集成各种业务应用，适用任何高并发的应用场景。这类平台有：瓴码APaaS。

2、IPaaS

IPaaS是SaaS运行的底座，就像Android是APP的底座一样，在云计算领域扮演非常重要的角色。

IPaaS可运行在一个跨区域的服务器大集群上，调度千百万台电脑就像一台巨型电脑，提供给不同企业的千百万个SaaS在其上运行。各企业只需要在IPaaS上注册一个账号，即可通过APaaS在IPaaS上安装各种SaaS应用，例如：B端应用ERP、CRM、OA、MES等等，以及C端应用电子商城、会员管理、新闻论坛等等。

IPaaS是云计算中技术含量最高的部分，负责解决以下技术的基础架构：

1、 资源编排和调度。

主要负责给各企业以及SaaS应用分配云计算资源，包括计算资源、内存资源、存储资源、网络资源等。

首先，在SaaS部署时，通过APaaS的部署工具为SaaS指定的配置，IPaaS负责提供对应资源，并激活该SaaS应用。

其次，在SaaS运行过程中，根据访问情况动态调整资源的分配。避免资源溢出，及时释放已闲置资源。

再有，SaaS可以根据需要实现资源迁移、扩充或者缩小等操作。

最后，当SaaS卸载时，把云计算资源及时回收。

传统资源调度组件有：K8S、Docker、mesos、yarn、swarm

2、 分布式实时流计算。

云端计算被触发时，可能涉及多个微服务之间串行或并行的互相调用，形成实时的流计算。流计算的最大特点是必须快速响应；必须有序执行；数据必须保持原子性，该次计算如果失败则关联微服务的数据必须全部还原；

传统流计算组件有：MapReduce、Spark、Storm、Flink、

3、 分布式业务流管理(BPM)。

业务流管理是企业应用软件不可缺少的重要组成部分。业务流程是通过多个职位或角色的有序操作，以完成某项独立的业务为目标。BPM负责启动业务流，向每个角色展示相关信息并记录和处理该角色输入的的数据，并根据业务顺序推动流程的执行，流程结束后及时归档流程数据。

完整的BPM一般具备以下特点：1、不同角色可设定不同的界面；2、根据业务需求可设定变量、访问数据库并嵌入任意逻辑计算，从而实现业务流的分叉；3、业务流可并行执行，且可汇合；4、业务流可支持循环执行的需要；5、业务流可回滚或撤回到指定节点，且被回滚的节点数据必须自动恢复到之前状态；6、业务流可撤销和归档。

传统开源BPM组件有：Activiti

4、 分布式数据存储、检索和传输。

云计算中，数据类型有结构化数据、非结构化数据等。负责存储结构化数据的叫关系型数据库，例如：mySQL、Oracle、SQL server等。存储非结构化数据的叫NOSQL数据库，例如：Redis、Mongodb等。非结构化数据搜索一般使用elesticsearch。

为了简化数据库的访问，会使用一下持久化框架，例如：mybatis、Hibernate等。

不同微服务之间需要数据交换，涉及到数据库之间的数据传输操作。大部分贫血型IPaaS平台未能提供相应组件，一般是由工程师自行编码完成。基于领域驱动的IPaaS平台，在实现域、子域、兄弟域之间的数据交换时，都会定义相关接口函数，保证域与域之间的数据有序传输和数据版本更新操作，例如：瓴码PaaS系统。

5、 异地多活的备灾机制。

对于高可用的IPaaS系统，必须解决部分服务器故障的场景下，保证系统能够继续提供服务。在一些极端场景下，有可能所有服务器都出现故障。即使有其他地区的备份，把备份业务系统全部恢复到能够正常提供业务，花费的时间也比较长，可能是半小时，也可能是12小时。如果业务期望达到即使在此类灾难性故障的情况下，业务也不受影响，或者在几分钟内就能够很快恢复，那么就需要设计异地多活架构。

异地多活架构的关键点就是异地、多活，就是指不同地理位置上的系统都能够同时提供业务服务，当一个地区出现灾难性故障，系统运行不会受到任何影响。

部分IPaaS系统提供了存储架构的异地多活服务，这种IPaaS在一个地区出现灾难故障时，只能保证数据不会丢失。正在运行的业务计算会立即报错，出现一定时间的服务中断，直到运算系统切换到其它地区恢复正常。最完善的IPaaS应该提供计算和存储都能实现异地多活。基于领域驱动的IPaaS架构，由于计算和存储集成在一个领域内作为一个整体，是领域层的异地多活架构，当一个地区的领域实体故障，其备份领域实体仍然无缝运行，使用者无任何感知。瓴码PaaS是这类IPaaS的典型代表。

6、 认证和鉴权。

微服务架构下，一个应用会被拆分成若干个微应用，每个微应用都需要对访问进行鉴权，每个微应用都需要明确当前访问用户以及其权限。尤其当访问来源不只是浏览器，还包括其他服务的调用时，要考虑外部应用接入的场景、用户 – 服务的鉴权、服务 – 服务的鉴权等多种鉴权场景。

认证和鉴权组件有：JWT、OAuth2.0等

7、 监控和日志记录。

对于IPaaS系统，各SaaS应用和系统运维是重中之重。而运维过程中，监控工作更是占据重要位置。运维的目的之一是为了保证系统的平稳运行，进而保障公司业务能持续对外服务，为了达到这一目的，我们需要对系统的状态进行持续地观测，以期望一有风吹草动就能发现并作出应对，监控作为一种手段，就是以此为生。

硬件、网络以及系统层面的监控，现有的一些监控系统和方案已经可以很好地提供支持，比如开源的 Zabbix 系统或者以报警为强项的 Nagios 系统。

微服务监控组件比较常用的有：sentry、prometheus等。

微服务在多个主机上运行。 为了满足单个业务需求，我们可能需要与在不同计算机上运行的多个服务进行对话。 因此，微服务生成的日志消息分布在多个主机上。如果对任何问题进行故障排除，没有统一的日志的支持，将一无所知。因此如果将跨主机生成的所有日志发送到外部集中位置。 从那里可以轻松地从一个地方获取日志信息。

常用的日志管理组件有：elk、logback等

8、 远程调用管理。

IPaaS系统中，微服务之间有大量的互相调用操作，这种调用可能是跨线程，也可能跨服务器。需要一种可靠、高效的通讯机制，保证这种调用的成功执行。微服务之间的调用分为两种类型：一种是需要返回结果参数的同步调用；另一种是不需要返回结果参数的异步调用。

同步调用一般使用RPC框架实现，常用组件有：Dubbo、Motan、Tars、Spring Cloud、gRPC、Thrift等。

异步调用一般使用消息中间件，常用组件有：ActiveMQ、RabbitMQ、Kafka、RocketMQ等

9、 分布式数据一致性控制。

在IPaaS这类大型分布式系统中，数据不能存在单个节点（主机）上，否则可能出现单点故障，必须多个节点（主机）需要同时保证具有相同的数据。一致性算法就是为了解决多个节点数据同步保持一致性的问题。

常用组件有：Zookeeper、etcd、Chubby等。

10、 负载均衡。

负载均衡，是在IPaaS系统中，用来在多个具备相同功能的微服务中分配负载，以达到最优化资源使用、最大化吞吐率、最小化响应时间、同时避免过载的目的。

Nginx/LVS/HAProxy是目前使用最广泛的三种负载均衡软件。

Gartner把提供IPaaS某一局部服务的平台也作了不同的命名，提供数据库平台开发环境的定义为DBPaaS，提供业务流程管理开发环境的定义为BMPPaaS，提供函数服务的定义为FaaS等等，这些都可以归并为IPaaS的一个分支。

能够提供IPaaS全部技术栈的公司极少，像阿里云这类巨头也只能提供局部的组件，而且大部分组件只是把开源组件稍作改造发布推广。

根据技术架构的不同，可以把IPaaS分成两大阵营：

一类是面向数据库的贫血式IPaaS系统。

1、 计算和数据分离。多个微服务共享一个数据库，数据库单独为一个分布式集群给很多微服务提供数据。这种方式的优点是可以很容易扩充并发量，便于大数据分析。缺点：一是运行效率低，在计算中使用大量数据必须跨服务器到专门集群中获取；二是个完整的业务逻辑描述不能在一个类中完成，而是一组相互协作的类共同完成的。可复用的颗粒度比较小，代码量膨胀很厉害，很重要的一点是业务逻辑的描述能力较差，一个稍微复杂的业务逻辑，就需要太多类和太多代码去表达。

2、 多租户共享一个微服务。当同一个微服务并发量很大时，只能把该微服务多次部署，再使用负载均衡技术避免单个微服务过载。优点：维护和购置成本低。缺点：运行效率低，安全性低。

3、 微服务之间是互相平等的扁平关联。必须采用服务注册、服务发现、服务网关、负载均衡等复杂技术治理微服务之间的互相调用，效率低，维护较难。

4、 不同功能组件形成多集群架构。贫血式IPaaS包含很多集群：分布式数据库集群、分布式缓存集群、消息中间件集群、分布式一致性中间件集群、资源编排集群、负载均衡集群等等。集群越多，损坏越大，维护越复杂。

现阶段，主流IPaaS大都是贫血式架构，以Spring Cloud框架为代表。提供贫血式IPaaS的厂商包括：阿里、腾讯、网易、亚马逊等，包括所有的其它小型厂商。

另一类是领域驱动的充血式IPaaS系统。充血血式IPaaS主要特点是：

1、 计算和数据集成在一个领域模型中。一个微服务就是一个领域实体，一个领域实体一个微数据库，微服务和微数据库部署在同一个服务器。这种方式的优点：1、运行效率非常高，计算过程中操作数据非常快捷；2、所有逻辑运算在一个类中执行，便于复用，业务逻辑表达更清晰。

2、 一个业务应用由一个树形架构组成，包含多个微服务，微服务之间存在父子关系。在业务应用部署过程中，就确立了每个微服务之间的连接关系，无需通过服务注册、服务发现、服务网关、负载均衡等复杂技术去管理微服务之间的调用，效率高，维护简单。

3、 每个租户有独立的业务应用以及微服务群。租户之间不会互相抢占资源，当同一个微服务并发量很大时，可以对该微服务多次实例化部署到不同服务器，再使用负载均衡技术避免单个微服务过载。运行效率非常高，每个租户拥有独立数据库，确保数据安全。

4、 整个IPaaS系统由一个集群驱动。每个功能组件只是每个领域实体的功能模块，独立为一个实体服务，无需做出集群。每实例化一个领域实体，所有功能组件都会实例化一份。运行效率高，需要的服务器资源降低，维护非常简单。

领域驱动架构的IPaaS还一个最大的优点，可以完全支持图形化编码。降低开发成本。

充血式IPaaS非常少，典型代表是瓴码PaaS系统。

3、FPaaS

FPaaS为SaaS应用提供不同功能的专用接口服务，例如物联网的相关技术（IoTPaaS）、人工智能相关技术（AIPaaS）等。FPaaS严格意义上讲，是一个特殊的SaaS应用，仍然是运行在IPaaS之上的，而给普通SaaS提供调用接口。

1、 IoTPaas

IoTPaaS目的是降低IoT开发的门槛，提供成熟和标准化的平台接口，如账号体系设备绑定管理、事件通知引擎、OTA管理、定时任务引擎、设备分享等，避免重复造轮子。

能提供IoTPaaS的厂商较多，例如：阿里、腾讯、百度、谷歌、亚马逊、小米、西门子、GE、海尔、联想等等。

2、 AIPaaS

AIPaaS主要在两个维度加速人工智能企业的快速发展：

一是提供极致高性能的AI计算资源，实现高效的计算力支撑、精准的资源管理和调度、敏捷的数据整合及加速、流程化的AI场景及业务整合。

二是构建开放的AI创新生态，无缝对接行业ISV，赋能生态伙伴，兼容各AI应用和场景。

国内AIPaaS厂商相对较少，如阿里、百度、腾讯、商汤、旷视等。

根据海比研究，于2019年相比，2020年企业购买服务应用选择PaaS的比例均有提高，其中大中型企业比例分别增值到19.1%和24.3%，在企业服务领域PaaS越来越受到大中型企业的青睐。从消费市场来看，大中型企业对云化软件的需求力度持续加大，未来平台化产品和服务将逐步成为企业构件数字化运营的核心，需求旺盛必然加快企业未来对PaaS的更多部署。