PaaS（Platform as a Service）是指云計(jì)算領(lǐng)域的平臺(tái)即服務(wù)。

根據(jù)Gartner，截至2019年整個(gè)PaaS市場蓬勃發(fā)展，已經(jīng)有360多家廠商，在21個(gè)品類下提供550多種云平臺(tái)服務(wù)。Gartner將PaaS平臺(tái)分為兩類：一類是應(yīng)用部署和運(yùn)行平臺(tái)APaaS（applicationplatform as a service)，另一類是集成平臺(tái)IPaaS（integrationas a service）。

海比研究則將PaaS分為六大類，一是應(yīng)用開發(fā)、部署和運(yùn)行平臺(tái)APaaS；二是集成平臺(tái)IPaaS；三是IaaS延伸性PaaS基礎(chǔ)服務(wù)平臺(tái)IaaS ；四是物聯(lián)網(wǎng)服務(wù)平臺(tái)IoTPaaS；五是人工智能服務(wù)平臺(tái)AIPaaS；六是其它類PaaS。

按筆者的理解，既然PaaS是為SaaS服務(wù)的底層平臺(tái)，PaaS的類別應(yīng)該以為SaaS提供不同的服務(wù)來劃分。筆者把PaaS分為三大類：第一類，為SaaS提供全套云端的開發(fā)、部署、運(yùn)行工具，這一類叫APaaS(application platform as a service)。第二類，為SaaS提供運(yùn)行、維護(hù)和營運(yùn)環(huán)境，這一類叫IPaaS（integration platform as a service）。第三類，為SaaS提供一些特殊功能接口服務(wù)，這一類叫FPaaS（function platform as a service）。

1、APaaS

早期的SaaS開發(fā)都使用很傳統(tǒng)方式，一般分為以下幾步：

第一步：選擇系統(tǒng)架構(gòu)及技術(shù)框架。根據(jù)項(xiàng)目的規(guī)模以及團(tuán)隊(duì)的能力選用一種系統(tǒng)架構(gòu)，例如：單體架構(gòu)、分層架構(gòu)、總線架構(gòu)、微服務(wù)架構(gòu)等。再根據(jù)系統(tǒng)架構(gòu)選用一些流行框架，比較流行的如：JAVA語言框架spring boot、spring cloud；PHP語言框架ThinkPHP、YII、CodeIgniter；NODEJS語言框架express等。也有幾種框架同時(shí)混合使用的案例。

第二步：選擇編程語言及開發(fā)工具。開發(fā)一款SaaS，一般根據(jù)模塊的功能和層級可能選用不同的語言開發(fā)，底層模塊更重視運(yùn)行效率，一般選用例如：C、C 、RUST、GOLANG等，業(yè)務(wù)層模塊更重視開發(fā)效率，一般選用例如：JAVA、PHP、NODEJS、PYTHON等。具體選哪種語言還與選擇的框架，以及團(tuán)隊(duì)以往的偏好有關(guān)系。

使用的也是傳統(tǒng)流行的開發(fā)工具，根據(jù)使用的編程語言不同稍有差異，最流行的開發(fā)工具有：Eclipse IDE、MyEclipse、Intellij IDEA、NetBeans等。

第三步：選擇中間件以及開源模塊。不同的系統(tǒng)架構(gòu)，選擇中間件也大不一樣。中間件是整個(gè)技術(shù)架構(gòu)中最復(fù)雜的部分，包含以下幾種類型：關(guān)系型數(shù)據(jù)庫、持久層框架、緩存數(shù)據(jù)庫、非關(guān)系型數(shù)據(jù)庫、搜索、反向代理、消息中間件、監(jiān)控、日志收集、分布式、配置中心、容器化、容器編排、鏈路跟蹤。

中間件使用最多的是微服務(wù)架構(gòu)，最多可超過30到40個(gè)中間件。組織、使用、部署、維護(hù)這些中間件是個(gè)非常大的工作量，特別是業(yè)務(wù)升級后如何保證中間件的同步升級存在很大不確定性。

SaaS應(yīng)用傳統(tǒng)開發(fā)模式的復(fù)雜性，促使互聯(lián)網(wǎng)公司推出第一代APaaS，這一類APaaS是仍然采用傳統(tǒng)計(jì)算機(jī)編程語言進(jìn)行開發(fā)、部署和運(yùn)行，并提供更集成化的在線開發(fā)工具，以及大量中間件的調(diào)用接口，開發(fā)效率得到了一定的提升。典型代表有：微軟的Azure App Service、亞馬遜的Amazon Web Service、阿里的云效、騰訊應(yīng)用開放平臺(tái)、華為軟件開發(fā)平臺(tái)(DevCloud)等。

近兩年，第二代APaaS（低代碼開發(fā)平臺(tái)）開始出現(xiàn)，這類開發(fā)平臺(tái)通常采用表單、流程或模型加少量代碼就可以應(yīng)用開發(fā)，替代了原先代碼式編程語言的模式，開發(fā)效率比第一代有明顯提升。這類平臺(tái)由于采用技術(shù)方式差異很大，面向的使用人群，以及使用范圍也有很大差異。根據(jù)采用技術(shù)的差異筆者把低代碼開發(fā)平臺(tái)再細(xì)分為三大類。

第一類是純表格和流程驅(qū)動(dòng)，無需編寫任何代碼的無代碼模式。這類APaaS通過建立多張表單，使用流程串聯(lián)，定義報(bào)表輸出方式，構(gòu)建表單類輕應(yīng)用。該類模式的技術(shù)壁壘不高，主要支持開發(fā)表單類應(yīng)用，場景有一定局限性。更適合簡單短期項(xiàng)目，不適合長期的循環(huán)迭代產(chǎn)品的開發(fā)，尤其產(chǎn)品要面對多樣性需求，必須具備高配置屬性的時(shí)候。比如表格展示，同一個(gè)流程不同職位看到的表格都是一樣，涉及到敏感信息不能區(qū)別展示，無法實(shí)現(xiàn)千人千面。這類平臺(tái)有：輕流、云表、簡道云、搭搭云、阿里的宜搭、宜創(chuàng)科技等。

第二類是貧血模型驅(qū)動(dòng)的低代碼模式。底層技術(shù)涉及云原生、元數(shù)據(jù)、多租戶等。該類模式的技術(shù)壁壘較高，顆粒度更細(xì)，復(fù)雜度、靈活度更高，能夠支持廣泛場景的復(fù)雜應(yīng)用開發(fā)，具備服務(wù)大客戶和中小客戶的能力。這類模式在面對復(fù)雜場景時(shí)，仍然需要編寫邏輯代碼。特別是在面向高并發(fā)應(yīng)用場景，需要投入大量的后端軟件開發(fā)。這類平臺(tái)有：OutSystems、Mendix、奧哲網(wǎng)絡(luò)（氚云）、ClickPaaS、炎黃盈動(dòng)、數(shù)式科技、黑帕云等。

第三類是領(lǐng)域驅(qū)動(dòng)的圖形碼模式。這類平臺(tái)完全由模型驅(qū)動(dòng)，可不用編寫任何代碼實(shí)現(xiàn)各種復(fù)雜場景的應(yīng)用開發(fā)。無論前端組件還是后端業(yè)務(wù)邏輯都能細(xì)粒度搭建，實(shí)現(xiàn)高度復(fù)雜、高度靈活的應(yīng)用場景。這類平臺(tái)的后端部分屬于領(lǐng)域驅(qū)動(dòng)的設(shè)計(jì)模式，其核心概念：域、子域、領(lǐng)域?qū)嶓w、值對象、領(lǐng)域服務(wù)、領(lǐng)域事件等是天然的圖形化解決復(fù)雜問題的表達(dá)模式，面對任何復(fù)雜應(yīng)用場景都能支撐APaaS的可視化搭建，并能可視化集成各種業(yè)務(wù)應(yīng)用，適用任何高并發(fā)的應(yīng)用場景。這類平臺(tái)有：瓴碼APaaS。

2、IPaaS

IPaaS是SaaS運(yùn)行的底座，就像Android是APP的底座一樣，在云計(jì)算領(lǐng)域扮演非常重要的角色。

IPaaS可運(yùn)行在一個(gè)跨區(qū)域的服務(wù)器大集群上，調(diào)度千百萬臺(tái)電腦就像一臺(tái)巨型電腦，提供給不同企業(yè)的千百萬個(gè)SaaS在其上運(yùn)行。各企業(yè)只需要在IPaaS上注冊一個(gè)賬號(hào)，即可通過APaaS在IPaaS上安裝各種SaaS應(yīng)用，例如：B端應(yīng)用ERP、CRM、OA、MES等等，以及C端應(yīng)用電子商城、會(huì)員管理、新聞?wù)搲鹊取?/span>

IPaaS是云計(jì)算中技術(shù)含量最高的部分，負(fù)責(zé)解決以下技術(shù)的基礎(chǔ)架構(gòu)：

1、 資源編排和調(diào)度。

主要負(fù)責(zé)給各企業(yè)以及SaaS應(yīng)用分配云計(jì)算資源，包括計(jì)算資源、內(nèi)存資源、存儲(chǔ)資源、網(wǎng)絡(luò)資源等。

首先，在SaaS部署時(shí)，通過APaaS的部署工具為SaaS指定的配置，IPaaS負(fù)責(zé)提供對應(yīng)資源，并激活該SaaS應(yīng)用。

其次，在SaaS運(yùn)行過程中，根據(jù)訪問情況動(dòng)態(tài)調(diào)整資源的分配。避免資源溢出，及時(shí)釋放已閑置資源。

再有，SaaS可以根據(jù)需要實(shí)現(xiàn)資源遷移、擴(kuò)充或者縮小等操作。

最后，當(dāng)SaaS卸載時(shí)，把云計(jì)算資源及時(shí)回收。

傳統(tǒng)資源調(diào)度組件有：K8S、Docker、mesos、yarn、swarm

2、 分布式實(shí)時(shí)流計(jì)算。

云端計(jì)算被觸發(fā)時(shí)，可能涉及多個(gè)微服務(wù)之間串行或并行的互相調(diào)用，形成實(shí)時(shí)的流計(jì)算。流計(jì)算的最大特點(diǎn)是必須快速響應(yīng)；必須有序執(zhí)行；數(shù)據(jù)必須保持原子性，該次計(jì)算如果失敗則關(guān)聯(lián)微服務(wù)的數(shù)據(jù)必須全部還原；

傳統(tǒng)流計(jì)算組件有：MapReduce、Spark、Storm、Flink、

3、 分布式業(yè)務(wù)流管理(BPM)。

業(yè)務(wù)流管理是企業(yè)應(yīng)用軟件不可缺少的重要組成部分。業(yè)務(wù)流程是通過多個(gè)職位或角色的有序操作，以完成某項(xiàng)獨(dú)立的業(yè)務(wù)為目標(biāo)。BPM負(fù)責(zé)啟動(dòng)業(yè)務(wù)流，向每個(gè)角色展示相關(guān)信息并記錄和處理該角色輸入的的數(shù)據(jù)，并根據(jù)業(yè)務(wù)順序推動(dòng)流程的執(zhí)行，流程結(jié)束后及時(shí)歸檔流程數(shù)據(jù)。

完整的BPM一般具備以下特點(diǎn)：1、不同角色可設(shè)定不同的界面；2、根據(jù)業(yè)務(wù)需求可設(shè)定變量、訪問數(shù)據(jù)庫并嵌入任意邏輯計(jì)算，從而實(shí)現(xiàn)業(yè)務(wù)流的分叉；3、業(yè)務(wù)流可并行執(zhí)行，且可匯合；4、業(yè)務(wù)流可支持循環(huán)執(zhí)行的需要；5、業(yè)務(wù)流可回滾或撤回到指定節(jié)點(diǎn)，且被回滾的節(jié)點(diǎn)數(shù)據(jù)必須自動(dòng)恢復(fù)到之前狀態(tài)；6、業(yè)務(wù)流可撤銷和歸檔。

傳統(tǒng)開源BPM組件有：Activiti

4、 分布式數(shù)據(jù)存儲(chǔ)、檢索和傳輸。

云計(jì)算中，數(shù)據(jù)類型有結(jié)構(gòu)化數(shù)據(jù)、非結(jié)構(gòu)化數(shù)據(jù)等。負(fù)責(zé)存儲(chǔ)結(jié)構(gòu)化數(shù)據(jù)的叫關(guān)系型數(shù)據(jù)庫，例如：mySQL、Oracle、SQL server等。存儲(chǔ)非結(jié)構(gòu)化數(shù)據(jù)的叫NOSQL數(shù)據(jù)庫，例如：Redis、Mongodb等。非結(jié)構(gòu)化數(shù)據(jù)搜索一般使用elesticsearch。

為了簡化數(shù)據(jù)庫的訪問，會(huì)使用一下持久化框架，例如：mybatis、Hibernate等。

不同微服務(wù)之間需要數(shù)據(jù)交換，涉及到數(shù)據(jù)庫之間的數(shù)據(jù)傳輸操作。大部分貧血型IPaaS平臺(tái)未能提供相應(yīng)組件，一般是由工程師自行編碼完成。基于領(lǐng)域驅(qū)動(dòng)的IPaaS平臺(tái)，在實(shí)現(xiàn)域、子域、兄弟域之間的數(shù)據(jù)交換時(shí)，都會(huì)定義相關(guān)接口函數(shù)，保證域與域之間的數(shù)據(jù)有序傳輸和數(shù)據(jù)版本更新操作，例如：瓴碼PaaS系統(tǒng)。

5、 異地多活的備災(zāi)機(jī)制。

對于高可用的IPaaS系統(tǒng)，必須解決部分服務(wù)器故障的場景下，保證系統(tǒng)能夠繼續(xù)提供服務(wù)。在一些極端場景下，有可能所有服務(wù)器都出現(xiàn)故障。即使有其他地區(qū)的備份，把備份業(yè)務(wù)系統(tǒng)全部恢復(fù)到能夠正常提供業(yè)務(wù)，花費(fèi)的時(shí)間也比較長，可能是半小時(shí)，也可能是12小時(shí)。如果業(yè)務(wù)期望達(dá)到即使在此類災(zāi)難性故障的情況下，業(yè)務(wù)也不受影響，或者在幾分鐘內(nèi)就能夠很快恢復(fù)，那么就需要設(shè)計(jì)異地多活架構(gòu)。

異地多活架構(gòu)的關(guān)鍵點(diǎn)就是異地、多活，就是指不同地理位置上的系統(tǒng)都能夠同時(shí)提供業(yè)務(wù)服務(wù)，當(dāng)一個(gè)地區(qū)出現(xiàn)災(zāi)難性故障，系統(tǒng)運(yùn)行不會(huì)受到任何影響。

部分IPaaS系統(tǒng)提供了存儲(chǔ)架構(gòu)的異地多活服務(wù)，這種IPaaS在一個(gè)地區(qū)出現(xiàn)災(zāi)難故障時(shí)，只能保證數(shù)據(jù)不會(huì)丟失。正在運(yùn)行的業(yè)務(wù)計(jì)算會(huì)立即報(bào)錯(cuò)，出現(xiàn)一定時(shí)間的服務(wù)中斷，直到運(yùn)算系統(tǒng)切換到其它地區(qū)恢復(fù)正常。最完善的IPaaS應(yīng)該提供計(jì)算和存儲(chǔ)都能實(shí)現(xiàn)異地多活。基于領(lǐng)域驅(qū)動(dòng)的IPaaS架構(gòu)，由于計(jì)算和存儲(chǔ)集成在一個(gè)領(lǐng)域內(nèi)作為一個(gè)整體，是領(lǐng)域?qū)拥漠惖囟嗷罴軜?gòu)，當(dāng)一個(gè)地區(qū)的領(lǐng)域?qū)嶓w故障，其備份領(lǐng)域?qū)嶓w仍然無縫運(yùn)行，使用者無任何感知。瓴碼PaaS是這類IPaaS的典型代表。

6、 認(rèn)證和鑒權(quán)。

微服務(wù)架構(gòu)下，一個(gè)應(yīng)用會(huì)被拆分成若干個(gè)微應(yīng)用，每個(gè)微應(yīng)用都需要對訪問進(jìn)行鑒權(quán)，每個(gè)微應(yīng)用都需要明確當(dāng)前訪問用戶以及其權(quán)限。尤其當(dāng)訪問來源不只是瀏覽器，還包括其他服務(wù)的調(diào)用時(shí)，要考慮外部應(yīng)用接入的場景、用戶 – 服務(wù)的鑒權(quán)、服務(wù) – 服務(wù)的鑒權(quán)等多種鑒權(quán)場景。

認(rèn)證和鑒權(quán)組件有：JWT、OAuth2.0等

7、 監(jiān)控和日志記錄。

對于IPaaS系統(tǒng)，各SaaS應(yīng)用和系統(tǒng)運(yùn)維是重中之重。而運(yùn)維過程中，監(jiān)控工作更是占據(jù)重要位置。運(yùn)維的目的之一是為了保證系統(tǒng)的平穩(wěn)運(yùn)行，進(jìn)而保障公司業(yè)務(wù)能持續(xù)對外服務(wù)，為了達(dá)到這一目的，我們需要對系統(tǒng)的狀態(tài)進(jìn)行持續(xù)地觀測，以期望一有風(fēng)吹草動(dòng)就能發(fā)現(xiàn)并作出應(yīng)對，監(jiān)控作為一種手段，就是以此為生。

硬件、網(wǎng)絡(luò)以及系統(tǒng)層面的監(jiān)控，現(xiàn)有的一些監(jiān)控系統(tǒng)和方案已經(jīng)可以很好地提供支持，比如開源的 Zabbix 系統(tǒng)或者以報(bào)警為強(qiáng)項(xiàng)的 Nagios 系統(tǒng)。

微服務(wù)監(jiān)控組件比較常用的有：sentry、prometheus等。

微服務(wù)在多個(gè)主機(jī)上運(yùn)行。 為了滿足單個(gè)業(yè)務(wù)需求，我們可能需要與在不同計(jì)算機(jī)上運(yùn)行的多個(gè)服務(wù)進(jìn)行對話。 因此，微服務(wù)生成的日志消息分布在多個(gè)主機(jī)上。如果對任何問題進(jìn)行故障排除，沒有統(tǒng)一的日志的支持，將一無所知。因此如果將跨主機(jī)生成的所有日志發(fā)送到外部集中位置。 從那里可以輕松地從一個(gè)地方獲取日志信息。

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

8、 遠(yuǎn)程調(diào)用管理。

IPaaS系統(tǒng)中，微服務(wù)之間有大量的互相調(diào)用操作，這種調(diào)用可能是跨線程，也可能跨服務(wù)器。需要一種可靠、高效的通訊機(jī)制，保證這種調(diào)用的成功執(zhí)行。微服務(wù)之間的調(diào)用分為兩種類型：一種是需要返回結(jié)果參數(shù)的同步調(diào)用；另一種是不需要返回結(jié)果參數(shù)的異步調(diào)用。

同步調(diào)用一般使用RPC框架實(shí)現(xiàn)，常用組件有：Dubbo、Motan、Tars、Spring Cloud、gRPC、Thrift等。

異步調(diào)用一般使用消息中間件，常用組件有：ActiveMQ、RabbitMQ、Kafka、RocketMQ等

9、 分布式數(shù)據(jù)一致性控制。

在IPaaS這類大型分布式系統(tǒng)中，數(shù)據(jù)不能存在單個(gè)節(jié)點(diǎn)（主機(jī)）上，否則可能出現(xiàn)單點(diǎn)故障，必須多個(gè)節(jié)點(diǎn)（主機(jī)）需要同時(shí)保證具有相同的數(shù)據(jù)。一致性算法就是為了解決多個(gè)節(jié)點(diǎn)數(shù)據(jù)同步保持一致性的問題。

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

10、 負(fù)載均衡。

負(fù)載均衡，是在IPaaS系統(tǒng)中，用來在多個(gè)具備相同功能的微服務(wù)中分配負(fù)載，以達(dá)到最優(yōu)化資源使用、最大化吞吐率、最小化響應(yīng)時(shí)間、同時(shí)避免過載的目的。

Nginx/LVS/HAProxy是目前使用最廣泛的三種負(fù)載均衡軟件。

Gartner把提供IPaaS某一局部服務(wù)的平臺(tái)也作了不同的命名，提供數(shù)據(jù)庫平臺(tái)開發(fā)環(huán)境的定義為DBPaaS，提供業(yè)務(wù)流程管理開發(fā)環(huán)境的定義為BMPPaaS，提供函數(shù)服務(wù)的定義為FaaS等等，這些都可以歸并為IPaaS的一個(gè)分支。

能夠提供IPaaS全部技術(shù)棧的公司極少，像阿里云這類巨頭也只能提供局部的組件，而且大部分組件只是把開源組件稍作改造發(fā)布推廣。

根據(jù)技術(shù)架構(gòu)的不同，可以把IPaaS分成兩大陣營：

一類是面向數(shù)據(jù)庫的貧血式IPaaS系統(tǒng)。

1、 計(jì)算和數(shù)據(jù)分離。多個(gè)微服務(wù)共享一個(gè)數(shù)據(jù)庫，數(shù)據(jù)庫單獨(dú)為一個(gè)分布式集群給很多微服務(wù)提供數(shù)據(jù)。這種方式的優(yōu)點(diǎn)是可以很容易擴(kuò)充并發(fā)量，便于大數(shù)據(jù)分析。缺點(diǎn)：一是運(yùn)行效率低，在計(jì)算中使用大量數(shù)據(jù)必須跨服務(wù)器到專門集群中獲??；二是個(gè)完整的業(yè)務(wù)邏輯描述不能在一個(gè)類中完成，而是一組相互協(xié)作的類共同完成的?？蓮?fù)用的顆粒度比較小，代碼量膨脹很厲害，很重要的一點(diǎn)是業(yè)務(wù)邏輯的描述能力較差，一個(gè)稍微復(fù)雜的業(yè)務(wù)邏輯，就需要太多類和太多代碼去表達(dá)。

2、 多租戶共享一個(gè)微服務(wù)。當(dāng)同一個(gè)微服務(wù)并發(fā)量很大時(shí)，只能把該微服務(wù)多次部署，再使用負(fù)載均衡技術(shù)避免單個(gè)微服務(wù)過載。優(yōu)點(diǎn)：維護(hù)和購置成本低。缺點(diǎn)：運(yùn)行效率低，安全性低。

3、 微服務(wù)之間是互相平等的扁平關(guān)聯(lián)。必須采用服務(wù)注冊、服務(wù)發(fā)現(xiàn)、服務(wù)網(wǎng)關(guān)、負(fù)載均衡等復(fù)雜技術(shù)治理微服務(wù)之間的互相調(diào)用，效率低，維護(hù)較難。

4、 不同功能組件形成多集群架構(gòu)。貧血式IPaaS包含很多集群：分布式數(shù)據(jù)庫集群、分布式緩存集群、消息中間件集群、分布式一致性中間件集群、資源編排集群、負(fù)載均衡集群等等。集群越多，損壞越大，維護(hù)越復(fù)雜。

現(xiàn)階段，主流IPaaS大都是貧血式架構(gòu)，以Spring Cloud框架為代表。提供貧血式IPaaS的廠商包括：阿里、騰訊、網(wǎng)易、亞馬遜等，包括所有的其它小型廠商。

另一類是領(lǐng)域驅(qū)動(dòng)的充血式IPaaS系統(tǒng)。充血血式IPaaS主要特點(diǎn)是：

1、 計(jì)算和數(shù)據(jù)集成在一個(gè)領(lǐng)域模型中。一個(gè)微服務(wù)就是一個(gè)領(lǐng)域?qū)嶓w，一個(gè)領(lǐng)域?qū)嶓w一個(gè)微數(shù)據(jù)庫，微服務(wù)和微數(shù)據(jù)庫部署在同一個(gè)服務(wù)器。這種方式的優(yōu)點(diǎn)：1、運(yùn)行效率非常高，計(jì)算過程中操作數(shù)據(jù)非?？旖?；2、所有邏輯運(yùn)算在一個(gè)類中執(zhí)行，便于復(fù)用，業(yè)務(wù)邏輯表達(dá)更清晰。

2、 一個(gè)業(yè)務(wù)應(yīng)用由一個(gè)樹形架構(gòu)組成，包含多個(gè)微服務(wù)，微服務(wù)之間存在父子關(guān)系。在業(yè)務(wù)應(yīng)用部署過程中，就確立了每個(gè)微服務(wù)之間的連接關(guān)系，無需通過服務(wù)注冊、服務(wù)發(fā)現(xiàn)、服務(wù)網(wǎng)關(guān)、負(fù)載均衡等復(fù)雜技術(shù)去管理微服務(wù)之間的調(diào)用，效率高，維護(hù)簡單。

3、 每個(gè)租戶有獨(dú)立的業(yè)務(wù)應(yīng)用以及微服務(wù)群。租戶之間不會(huì)互相搶占資源，當(dāng)同一個(gè)微服務(wù)并發(fā)量很大時(shí)，可以對該微服務(wù)多次實(shí)例化部署到不同服務(wù)器，再使用負(fù)載均衡技術(shù)避免單個(gè)微服務(wù)過載。運(yùn)行效率非常高，每個(gè)租戶擁有獨(dú)立數(shù)據(jù)庫，確保數(shù)據(jù)安全。

4、 整個(gè)IPaaS系統(tǒng)由一個(gè)集群驅(qū)動(dòng)。每個(gè)功能組件只是每個(gè)領(lǐng)域?qū)嶓w的功能模塊，獨(dú)立為一個(gè)實(shí)體服務(wù)，無需做出集群。每實(shí)例化一個(gè)領(lǐng)域?qū)嶓w，所有功能組件都會(huì)實(shí)例化一份。運(yùn)行效率高，需要的服務(wù)器資源降低，維護(hù)非常簡單。

領(lǐng)域驅(qū)動(dòng)架構(gòu)的IPaaS還一個(gè)最大的優(yōu)點(diǎn)，可以完全支持圖形化編碼。降低開發(fā)成本。

充血式IPaaS非常少，典型代表是瓴碼PaaS系統(tǒng)。

3、FPaaS

FPaaS為SaaS應(yīng)用提供不同功能的專用接口服務(wù)，例如物聯(lián)網(wǎng)的相關(guān)技術(shù)（IoTPaaS）、人工智能相關(guān)技術(shù)（AIPaaS）等。FPaaS嚴(yán)格意義上講，是一個(gè)特殊的SaaS應(yīng)用，仍然是運(yùn)行在IPaaS之上的，而給普通SaaS提供調(diào)用接口。

1、 IoTPaas

IoTPaaS目的是降低IoT開發(fā)的門檻，提供成熟和標(biāo)準(zhǔn)化的平臺(tái)接口，如賬號(hào)體系設(shè)備綁定管理、事件通知引擎、OTA管理、定時(shí)任務(wù)引擎、設(shè)備分享等，避免重復(fù)造輪子。

能提供IoTPaaS的廠商較多，例如：阿里、騰訊、百度、谷歌、亞馬遜、小米、西門子、GE、海爾、聯(lián)想等等。

2、 AIPaaS

AIPaaS主要在兩個(gè)維度加速人工智能企業(yè)的快速發(fā)展：

一是提供極致高性能的AI計(jì)算資源，實(shí)現(xiàn)高效的計(jì)算力支撐、精準(zhǔn)的資源管理和調(diào)度、敏捷的數(shù)據(jù)整合及加速、流程化的AI場景及業(yè)務(wù)整合。

二是構(gòu)建開放的AI創(chuàng)新生態(tài)，無縫對接行業(yè)ISV，賦能生態(tài)伙伴，兼容各AI應(yīng)用和場景。

國內(nèi)AIPaaS廠商相對較少，如阿里、百度、騰訊、商湯、曠視等。

根據(jù)海比研究，于2019年相比，2020年企業(yè)購買服務(wù)應(yīng)用選擇PaaS的比例均有提高，其中大中型企業(yè)比例分別增值到19.1%和24.3%，在企業(yè)服務(wù)領(lǐng)域PaaS越來越受到大中型企業(yè)的青睞。從消費(fèi)市場來看，大中型企業(yè)對云化軟件的需求力度持續(xù)加大，未來平臺(tái)化產(chǎn)品和服務(wù)將逐步成為企業(yè)構(gòu)件數(shù)字化運(yùn)營的核心，需求旺盛必然加快企業(yè)未來對PaaS的更多部署。