剖析多租戶(hù)-SaaS-PaaS.doc

1 Salesforce的簡(jiǎn)介在云計(jì)算方面，Salesforce 可以稱(chēng)為業(yè)界的領(lǐng)袖，它不僅在產(chǎn)品方面比較成熟，而且在思維方面也是引領(lǐng)潮流的，特別是在SaaS（Software as a Service，軟件即服務(wù)）和PaaS（Platform as a Service，平臺(tái)即服務(wù)）這個(gè)兩個(gè)領(lǐng)域內(nèi)。圖1. Salesforce 商標(biāo)（圖源自S）首先，簡(jiǎn)要地介紹一下Salesforce的歷史：S在1999年由前甲骨文高管 Marc Benioff 創(chuàng)立，他創(chuàng)辦Salesforce的核心理念就是No Software（消滅軟件），但是其意義并不是排斥所有的軟件，而是主要排斥運(yùn)行在企業(yè)數(shù)據(jù)中心的軟件（On-Premise Software），也就是希望讓用戶(hù)能直接通過(guò)互聯(lián)網(wǎng)來(lái)諸如CRM等軟件服務(wù)，并同時(shí)讓用戶(hù)無(wú)需自己搭建和維護(hù)軟件所需的硬件和系統(tǒng)等資源。Salesforce的主要產(chǎn)品包括Sales Cloud（CRM）、Service Cloud、Chatter和F等。下面是它的主要發(fā)展史： 1999年，Salesforce在美國(guó)舊金山成立。 2001年，推出了第一款SaaS應(yīng)用CRM，同時(shí)也受到眾多廠商和客戶(hù)的熱議。 2004年，Sunguard成為Salesforce第1000位用戶(hù)。 2005年，推出了名為AppExchange的程序商店，以豐富用戶(hù)選擇。 2006年，推出了首個(gè)運(yùn)行在云計(jì)算平臺(tái)的語(yǔ)言Apex，并在語(yǔ)法上類(lèi)似Java。 2007年，推出了它的PaaS平臺(tái)F，來(lái)讓用戶(hù)更方便地在Saleforce平臺(tái)上開(kāi)發(fā)在線(xiàn)應(yīng)用，同時(shí)Salesforce憑借F得到了華爾街日?qǐng)?bào)的科技創(chuàng)新獎(jiǎng)（Technology Innovation Award）。 2009年，Salesforce成為首家年收入達(dá)到10億美元的云計(jì)算公司，并在年初推出了名為Service Cloud在線(xiàn)客戶(hù)服務(wù)應(yīng)用。 2010年，Salesforce將推出名為Chatter的企業(yè)級(jí)在線(xiàn)SNS服務(wù)，類(lèi)似于企業(yè)內(nèi)部的LinkedIn，同時(shí)其CRM應(yīng)用已更名為Sales Cloud。 1.1 Salesforce的整體架構(gòu)雖然Salesforce這些產(chǎn)品從表面而言有所不同，但是從全局而言，它們卻是一個(gè)整體，具體可看下圖：圖2. Salesforce的整體架構(gòu) （圖部分源自S）從這張Salesforce的整體架構(gòu)圖可以看成，F(xiàn) 是 Salesforce 整體架構(gòu)的核心，因?yàn)樗紫日虾涂刂屏说讓拥奈锢淼幕A(chǔ)設(shè)施，接著給上層的Sales Cloud，Service Cloud，Chatter和基于F的定制應(yīng)用提供PaaS服務(wù)，最后，那些F上層的應(yīng)用以SaaS形式供用戶(hù)使用。這樣做的好處主要有兩方面：其一是關(guān)于成本的，因?yàn)橥ㄟ^(guò)這個(gè)統(tǒng)一的架構(gòu)能極大地整合多種應(yīng)用，從而降低了在基礎(chǔ)設(shè)施方面的投入。其二是在軟件架構(gòu)方面，因?yàn)槭褂眠@個(gè)統(tǒng)一的架構(gòu)，使得所有上層的SaaS服務(wù)都依賴(lài)F的API，這樣將有效地確保API的穩(wěn)定性并避免了重復(fù)，從而方便了用戶(hù)和Saelsforce在這個(gè)平臺(tái)上開(kāi)發(fā)應(yīng)用。雖然Salesforce的Sales Cloud等SaaS應(yīng)用也比較經(jīng)典，但由于F堪稱(chēng)整個(gè)架構(gòu)的核心，同時(shí)也是最值得的學(xué)習(xí)和借鑒的部分，所以本系列接下來(lái)將會(huì)把重點(diǎn)對(duì)準(zhǔn)F。1.2 FF是Salesforce在2007推出的PaaS平臺(tái)，并且已經(jīng)有超過(guò)47000位企業(yè)已經(jīng)使用了這個(gè)平臺(tái)。F基于多租戶(hù)的架構(gòu)，其主要通過(guò)提供完善的開(kāi)發(fā)環(huán)境等功能來(lái)幫助企業(yè)和第三方供應(yīng)商交付健壯的，可靠的和可伸縮的在線(xiàn)應(yīng)用。圖1. F 商標(biāo)（圖源自參3）總體而言，F(xiàn)主要有五方面功能： 強(qiáng)大的定制功能：在F，不僅UI能夠定制，而且諸如Workflow和表格等也能被定制。 提供完善的開(kāi)發(fā)環(huán)境：首先，通過(guò)Visualforce能方便地使用Drag & Drop的方式來(lái)設(shè)計(jì)頁(yè)面。其次，Salesforce提供基于Eclipse的IDE來(lái)快速地開(kāi)發(fā)應(yīng)用。最后，Salesforce還提供Sandbox來(lái)方便用戶(hù)測(cè)試。 支持復(fù)雜的事務(wù)和流程：通過(guò)F專(zhuān)屬的APEX語(yǔ)言，能方便地設(shè)計(jì)和開(kāi)發(fā)復(fù)雜的事務(wù)和流程。 優(yōu)秀的整合功能：用戶(hù)除了可以在AppExchange購(gòu)買(mǎi)其所需的功能和應(yīng)用，而且還可以通過(guò)F的Web Service接口來(lái)和其他應(yīng)用整合，比如SAP等。 久經(jīng)考驗(yàn)的基礎(chǔ)設(shè)施：由于Salesforce除了通過(guò)在多個(gè)大洲建有數(shù)據(jù)中心來(lái)應(yīng)對(duì)災(zāi)難的發(fā)生，而且在可用性和安全性等方面也有一定積累，所以在Salesforce能長(zhǎng)時(shí)間地支持眾多服務(wù)的正常運(yùn)行。 2 多租戶(hù)的介紹2.1 概念雖然對(duì)我們而言，多租戶(hù)(Multitenancy)可以算是一個(gè)非常新穎的概念，但是其實(shí)這個(gè)概念已經(jīng)由來(lái)已久了。簡(jiǎn)單而言，多租戶(hù)指得就是一個(gè)單獨(dú)的軟件實(shí)例可以為多個(gè)組織服務(wù)。一個(gè)支持多租戶(hù)的軟件需要在設(shè)計(jì)上能對(duì)它的數(shù)據(jù)和配置信息進(jìn)行虛擬分區(qū)，從而使得每個(gè)使用這個(gè)軟件的組織能使用到一個(gè)單獨(dú)的虛擬實(shí)例，并且可以對(duì)這個(gè)虛擬實(shí)例進(jìn)行定制化。但是要讓一個(gè)軟件支持多租戶(hù)并非易事，因?yàn)椴粌H對(duì)它的軟件架構(gòu)進(jìn)行相應(yīng)的修改，而且需要對(duì)它的數(shù)據(jù)庫(kù)結(jié)構(gòu)進(jìn)行特殊的設(shè)計(jì)，同時(shí)在安全和隔離性方面也要有所保障。還有，為了幫助大家進(jìn)一步理解多租戶(hù)這個(gè)概念，特別選取兩個(gè)和多租戶(hù)比較接近的概念來(lái)進(jìn)行進(jìn)一步的辨析。多租戶(hù)和多用戶(hù)的區(qū)別多用戶(hù)的關(guān)鍵點(diǎn)在于不同的用戶(hù)擁有不同的訪(fǎng)問(wèn)權(quán)限，但是多個(gè)用戶(hù)共享同一個(gè)的實(shí)例。而在多租戶(hù)中，多個(gè)組織使用的實(shí)例各不相同。多租戶(hù)和虛擬化的區(qū)別多租戶(hù)和虛擬化在概念是比較類(lèi)似，都是給每個(gè)用戶(hù)一個(gè)虛擬的實(shí)例，并且都支持定制化，但是它們作用的層次不同：虛擬化主要是虛擬出一個(gè)操作系統(tǒng)的實(shí)例，而多租戶(hù)則是主要虛擬出一個(gè)應(yīng)用的實(shí)例。2.2 優(yōu)缺點(diǎn)多租戶(hù)的優(yōu)點(diǎn)： 經(jīng)濟(jì)：因?yàn)橥ㄟ^(guò)一個(gè)軟件實(shí)例被多個(gè)組織共享，從而減低了整體資源的消耗，也同時(shí)減低應(yīng)用運(yùn)行的成本和相應(yīng)的管理開(kāi)支。 易于更新和開(kāi)發(fā)：因?yàn)樗薪M織都共享同一套核心代碼，所以能夠讓軟件更新和開(kāi)發(fā)更簡(jiǎn)單。 管理方便：首先，通過(guò)使用了多租戶(hù)架構(gòu)能減少物理資源和軟件資源，這將簡(jiǎn)化管理。其次。由于多租戶(hù)軟件主要由有經(jīng)驗(yàn)的云供應(yīng)商運(yùn)營(yíng)，所以能依賴(lài)那些非常經(jīng)驗(yàn)的管理人員來(lái)提升效率。 多租戶(hù)的缺點(diǎn)： 更復(fù)雜：由于一個(gè)軟件需要做出極大地修改，才能支持多租戶(hù)架構(gòu)，而且這種修改，往往會(huì)增加整個(gè)軟件在架構(gòu)方面的復(fù)雜性。 不夠安全：因?yàn)楸姸嘟M織的應(yīng)用和數(shù)據(jù)共享同一套軟件和基礎(chǔ)設(shè)施，如果出現(xiàn)機(jī)器宕機(jī)，軟件出現(xiàn)問(wèn)題或者大規(guī)模的數(shù)據(jù)被暴露等情況，將會(huì)造成更嚴(yán)重的后果，因?yàn)橛绊懨娓蟆?2.3 幾種模型 在現(xiàn)有的實(shí)現(xiàn)中，主要有三種常見(jiàn)的模型，而且區(qū)別主要在于采用不同的數(shù)據(jù)庫(kù)模式（Database Schema）： 私有表（圖1-a）：它是最簡(jiǎn)單的擴(kuò)展模式，就是為每個(gè)租戶(hù)的自定義數(shù)據(jù)創(chuàng)建一個(gè)新表。優(yōu)點(diǎn)是簡(jiǎn)單。缺點(diǎn)是涉及到高成本的DDL操作，并且它的整合度不高。 擴(kuò)展表（圖1-b）：總體而言，比較類(lèi)似于私有表，但是一個(gè)擴(kuò)展表會(huì)被多個(gè)租戶(hù)共享，所以無(wú)論是共享表還是基本表都會(huì)有租戶(hù)欄位。好處是比私有表更高的整合度和更少的DDL操作，但是在架構(gòu)上比私有表更復(fù)雜。 通用表（圖1-c）： 主要通過(guò)一個(gè)通用表來(lái)存放所有自定義信息，里面有租戶(hù)欄位和許許多多統(tǒng)一的數(shù)據(jù)欄位（比如500個(gè)）。像這種統(tǒng)一的數(shù)據(jù)欄位會(huì)使用非常靈活的格式讓轉(zhuǎn)儲(chǔ)各種類(lèi)型的數(shù)據(jù)，比如VARCHAR。由于在每一行中的數(shù)據(jù)欄位都會(huì)以一個(gè)Key一個(gè)Value形式存放所有自定義數(shù)據(jù)，導(dǎo)致通用表的行都會(huì)很寬，而且會(huì)出現(xiàn)很多空值，所以通用表這種方式也被稱(chēng)為Sparse Column。好處是極高的整合度并避免了DDL操作，但是在處理數(shù)據(jù)方面難度加大。 圖1. 多種模式（圖源自參7）差異與取舍模型機(jī)制優(yōu)點(diǎn)缺點(diǎn)私有表為每個(gè)租戶(hù)的自定義數(shù)據(jù)創(chuàng)建一個(gè)新表簡(jiǎn)單需要DDL操作，低整合度擴(kuò)展表一個(gè)擴(kuò)展表會(huì)被多個(gè)租戶(hù)共享高整合度，少DDL操作有點(diǎn)復(fù)雜通用表通過(guò)一個(gè)通用表來(lái)存放所有自定義信息極高整合度，無(wú)DDL操作實(shí)現(xiàn)難度高在實(shí)戰(zhàn)中，具體選擇那個(gè)模型，主要還是看那個(gè)模型更適合。3 F的多租戶(hù)架構(gòu) 由于F所負(fù)載的應(yīng)用不論是在定制方面的靈活性上，還是所承受的負(fù)載上，對(duì)基于多租戶(hù)的架構(gòu)而言，都是史無(wú)前例的，導(dǎo)致之前提到的一些模型或者改動(dòng)已經(jīng)無(wú)法滿(mǎn)足要求了，所以Salesforce在F引入了通過(guò)Metadata（元數(shù)據(jù)）驅(qū)動(dòng)的多租戶(hù)架構(gòu)來(lái)動(dòng)態(tài)生成快速的，可伸縮的和可定制的應(yīng)用。接下來(lái)，將一步步為大家揭開(kāi)F多租戶(hù)架構(gòu)的神秘面紗，首先是它的總體架構(gòu)。3.1 總體架構(gòu) 在介紹F的整個(gè)架構(gòu)之前，請(qǐng)看下圖，此圖是根據(jù)Salesforce首席架構(gòu)師Craig Weissman在2009年舊金山QCon大會(huì)上的演講總結(jié)而成。圖1. F的架構(gòu)圖首先，在最前面是Gateway（網(wǎng)關(guān)），網(wǎng)關(guān)將接受所有訪(fǎng)問(wèn)F的請(qǐng)求，無(wú)論它是訪(fǎng)問(wèn)Sales Cloud，還是關(guān)于第三方定制程序的。接下來(lái)，網(wǎng)關(guān)會(huì)根據(jù)這個(gè)請(qǐng)求所屬的租戶(hù)把請(qǐng)求轉(zhuǎn)發(fā)給對(duì)應(yīng)的POD，什么是POD？簡(jiǎn)單的來(lái)說(shuō)，POD就是一組集群服務(wù)器，每個(gè)POD都運(yùn)行同一套F系統(tǒng)，而且每個(gè)POD支持成千上萬(wàn)個(gè)租戶(hù)，Salesforce總共有10多個(gè)POD來(lái)支撐它所有服務(wù)的運(yùn)營(yíng)，并把所有租戶(hù)平衡地分配給每個(gè)POD，而且主要通過(guò)建立新的POD來(lái)支撐新的租戶(hù)。當(dāng)POD收到請(qǐng)求之后，POD會(huì)先通過(guò)其內(nèi)置的Load Balancer（負(fù)載均衡器）來(lái)將請(qǐng)求轉(zhuǎn)發(fā)給負(fù)載略輕的App Server（應(yīng)用服務(wù)器），由于為了簡(jiǎn)化架構(gòu)和方便伸縮（Scale），所以應(yīng)用服務(wù)器是Stateless（無(wú)狀態(tài)），而且在一個(gè)POD內(nèi)會(huì)有多個(gè)應(yīng)用服務(wù)器以應(yīng)對(duì)大規(guī)模的請(qǐng)求。最后，當(dāng)應(yīng)用服務(wù)器在處理請(qǐng)求的時(shí)候，如果發(fā)現(xiàn)請(qǐng)求所需的數(shù)據(jù)沒(méi)有被Cache住的話(huà)，應(yīng)用服務(wù)器會(huì)調(diào)用這個(gè)租戶(hù)所屬的Shared DB（共享數(shù)據(jù)庫(kù)）來(lái)取得相關(guān)數(shù)據(jù)，雖然共享數(shù)據(jù)庫(kù)是使用成熟的Oracle數(shù)據(jù)庫(kù)產(chǎn)品，但是在數(shù)據(jù)庫(kù)表的設(shè)計(jì)上面為多租戶(hù)做了很多地優(yōu)化。接下來(lái)，將介紹F是如何通過(guò)Metadata來(lái)動(dòng)態(tài)生成和定制應(yīng)用的。3.2 Metadata驅(qū)動(dòng) 首先，F(xiàn)的Metadata是基于大家非常熟悉的面向?qū)ο蟮母拍睿砸部梢园袽etadata認(rèn)為是對(duì)象，也就是說(shuō)F是由一個(gè)個(gè)對(duì)象組裝而成，而且F中的對(duì)象可以是表格，也可以是UI，甚至可以是用戶(hù)權(quán)益等。一個(gè)F的對(duì)象和這個(gè)對(duì)象下面的字段可以對(duì)應(yīng)一個(gè)數(shù)據(jù)庫(kù)的表和這個(gè)表的列，而且F對(duì)象之間的關(guān)系（relationship）在功能上類(lèi)似于數(shù)據(jù)庫(kù)的引用完整性約束（referential integrity constraint），但與數(shù)據(jù)庫(kù)中每個(gè)數(shù)據(jù)庫(kù)表對(duì)應(yīng)于獨(dú)立的存儲(chǔ)地址不同的是，F(xiàn)使用幾個(gè)共享的大數(shù)據(jù)庫(kù)表來(lái)作為堆存儲(chǔ)（heap storage）來(lái)放置所有對(duì)象，另外這些存儲(chǔ)Metadata的表也被稱(chēng)為UDD（Universal Data Dictionary）。接著，是關(guān)于應(yīng)用的，一個(gè)在F上運(yùn)行的應(yīng)用實(shí)例是通過(guò)組合許許多多個(gè)對(duì)象來(lái)生成的，也可以說(shuō)一個(gè)應(yīng)用實(shí)例是使用Metadata來(lái)描述的，比如，在應(yīng)用初始的時(shí)候，每個(gè)客戶(hù)都是使用同一個(gè)版本和同樣規(guī)模的對(duì)象，而且用戶(hù)通過(guò)添加和更新對(duì)象來(lái)定制應(yīng)用，比如增加新的UI和字段等，同時(shí)系統(tǒng)會(huì)對(duì)共享的和定制的對(duì)象進(jìn)行嚴(yán)格地分離，使得既能非常方便地更新共享代碼，也能保證某個(gè)用戶(hù)定制過(guò)的部分不影響到其他用戶(hù)。在實(shí)現(xiàn)上，F(xiàn)并沒(méi)有實(shí)際地為一個(gè)新對(duì)象生成一個(gè)數(shù)據(jù)庫(kù)表，而且以元數(shù)據(jù)的形式存儲(chǔ)在幾張大表中，并在運(yùn)行時(shí)候，F(xiàn)會(huì)有一套引擎來(lái)通過(guò)分析數(shù)據(jù)庫(kù)中的Metadata來(lái)動(dòng)態(tài)生成一個(gè)虛擬應(yīng)用實(shí)例和這個(gè)應(yīng)用所需的模塊（Virtual Application Componets），比如公共UI（Common Application Screen），定制UI（Tenant-Specific Screen）和其他對(duì)象等。圖2. 虛擬應(yīng)用模塊圖（源自參1）還有，雖然Metadata驅(qū)動(dòng)這種和Java很類(lèi)似的動(dòng)態(tài)生成機(jī)制在速度上有天生缺陷，但是F也內(nèi)置與Sun的Hotspot技術(shù)有異曲同工之妙的Metadata Cache來(lái)加速常用Metadata的讀取。下面，將分別介紹F的兩大組成部分：應(yīng)用服務(wù)器和共享數(shù)據(jù)庫(kù)。3.3 應(yīng)用服務(wù)器應(yīng)用服務(wù)器主要包括五大核心模塊： Metadata Cache：用于存放那些最近用到的和比較常用的Metadata來(lái)加速應(yīng)用的生成。 大規(guī)模數(shù)據(jù)處理引擎：主要用來(lái)加速處理大量的數(shù)據(jù)讀寫(xiě)和在線(xiàn)事務(wù)。 多租戶(hù)感知的查詢(xún)優(yōu)化引擎：這個(gè)引擎將通過(guò)維護(hù)多租戶(hù)的信息來(lái)幫助Oracle自帶的基于成本的查詢(xún)優(yōu)化器更好地適應(yīng)多租戶(hù)環(huán)境。 運(yùn)行時(shí)應(yīng)用生成器：這個(gè)生成器主要根據(jù)用戶(hù)的請(qǐng)求來(lái)動(dòng)態(tài)生成應(yīng)用，并且利用上面提到的查詢(xún)優(yōu)化引擎來(lái)提升效率。 全文檢索引擎：在數(shù)據(jù)庫(kù)對(duì)數(shù)據(jù)進(jìn)行更新的同時(shí)，這個(gè)引擎會(huì)異步更新這個(gè)數(shù)據(jù)的相關(guān)索引。 3.4 共享數(shù)據(jù)庫(kù)圖1. F的架構(gòu)（圖源自參1）整個(gè)共享數(shù)據(jù)庫(kù)主要有三種類(lèi)型的數(shù)據(jù)庫(kù)表： Metadata表：主要存放用戶(hù)定制的對(duì)象和對(duì)象所包含的字段的結(jié)構(gòu)信息，也被稱(chēng)為UDD。 數(shù)據(jù)表：主要存儲(chǔ)那些用戶(hù)定制的對(duì)象和對(duì)象所包含的字段的數(shù)據(jù)。 Pivot表：用來(lái)維護(hù)那些用于檢索（indexing），唯一性和關(guān)系等denormalized （去規(guī)范化）數(shù)據(jù)以?xún)?yōu)化系統(tǒng)的效率。 還有，在物理層面，數(shù)據(jù)庫(kù)里面所有表格，包括底下的索引，都根據(jù)每個(gè)租戶(hù)不同的租戶(hù)ID（OrgID）來(lái)使用Oracle的Hash分區(qū)技術(shù)進(jìn)行分區(qū)。通過(guò)Hash分區(qū)這種久經(jīng)考驗(yàn)的技術(shù)能夠?qū)⒋笠?guī)模的數(shù)據(jù)平均地分割成多個(gè)更小的和更容易管理的分塊，從而幫助大數(shù)據(jù)庫(kù)系統(tǒng)能夠在多租戶(hù)的環(huán)境下提升速度，伸縮性和可用性等。3.5 大規(guī)模數(shù)據(jù)處理引擎由于F需要處理的數(shù)據(jù)量不論是來(lái)自網(wǎng)頁(yè)端，還是來(lái)自Web Service端都是非常巨大的，所以Salesforce在F中引入了特制的大規(guī)模數(shù)據(jù)處理引擎來(lái)處理大量的數(shù)據(jù)讀寫(xiě)和在線(xiàn)事務(wù)。它主要有兩大特點(diǎn)：其一是對(duì)大規(guī)模數(shù)據(jù)處理進(jìn)行了優(yōu)化，特別是當(dāng)一個(gè)API調(diào)用發(fā)來(lái)很多待處理的數(shù)據(jù)時(shí)，這個(gè)引擎能非?？焖俚靥幚怼Ｆ涠沁@個(gè)引擎內(nèi)置錯(cuò)誤恢復(fù)機(jī)制，當(dāng)處理大規(guī)模數(shù)據(jù)時(shí)候，假如其中一個(gè)步驟發(fā)生錯(cuò)誤時(shí)，這個(gè)引擎會(huì)捕捉和修復(fù)這個(gè)錯(cuò)誤，并且保持這個(gè)步驟之前正確的結(jié)果以避免整個(gè)重做。3.6 多租戶(hù)感知的查詢(xún)優(yōu)化引擎大多數(shù)現(xiàn)在數(shù)據(jù)庫(kù)都自帶基于成本的查詢(xún)優(yōu)化器，這種優(yōu)化器主要是基于數(shù)據(jù)庫(kù)表和索引數(shù)據(jù)等相關(guān)數(shù)值來(lái)進(jìn)行計(jì)算和比較。但是由于傳統(tǒng)的基于成本的優(yōu)化器都是主要為單租戶(hù)的環(huán)境設(shè)計(jì)的，所以他們并不能很好地適應(yīng)多租戶(hù)的環(huán)境，因?yàn)樵跀?shù)據(jù)庫(kù)中是沒(méi)有多租戶(hù)這個(gè)概念。為了讓優(yōu)化器能夠在多租戶(hù)環(huán)境下良好工作，Salesforce在Oracle自帶優(yōu)化器的基礎(chǔ)上搭建了一個(gè)多租戶(hù)感知的查詢(xún)優(yōu)化引擎，它也主要有兩個(gè)特點(diǎn)：其一是這個(gè)引擎為每個(gè)多租戶(hù)對(duì)象維護(hù)了一整套便于優(yōu)化的數(shù)據(jù)（租戶(hù)層的，組層的和用戶(hù)層的）。其二是這個(gè)引擎也維護(hù)租戶(hù)和租戶(hù)下面用戶(hù)的安全信息，這樣不僅能提升了效率，因?yàn)槟鼙苊鈱⒛切┎粚儆谶@個(gè)租戶(hù)的數(shù)據(jù)加入到計(jì)算，而且能提升數(shù)據(jù)的安全性。3.7 全文檢索引擎全文檢索功能對(duì)Web應(yīng)用而言，基本可以算是一種基本功能，而對(duì)基于F的應(yīng)用而言，同樣如此，F(xiàn)為此內(nèi)置一個(gè)全文檢索引擎，其是基于大名鼎鼎的Lucene技術(shù)。當(dāng)一個(gè)運(yùn)行在F平臺(tái)上的應(yīng)用對(duì)數(shù)據(jù)庫(kù)中數(shù)據(jù)進(jìn)行更新的時(shí)候，會(huì)有一組稱(chēng)為檢索服務(wù)器的后臺(tái)進(jìn)程來(lái)異步更新數(shù)據(jù)相關(guān)的索引。通過(guò)這種異步機(jī)制不僅能夠保證檢索工作不影響處理事務(wù)的效率，而且同時(shí)也能讓用戶(hù)使用到最新的搜索結(jié)果。為了優(yōu)化這個(gè)檢索流程，系統(tǒng)會(huì)同步將修改過(guò)的數(shù)據(jù)復(fù)制到一個(gè)內(nèi)部等待檢索的表，之后檢索服務(wù)器會(huì)訪(fǎng)問(wèn)這個(gè)表來(lái)進(jìn)行檢索，這樣好處是減少了檢索服務(wù)器的I/O處理量。而且為了更好地適應(yīng)多租戶(hù)環(huán)境，檢索引擎自動(dòng)為每個(gè)租戶(hù)維護(hù)一個(gè)獨(dú)立的索引。3.8 數(shù)據(jù)庫(kù)表的設(shè)計(jì)下圖為F的數(shù)據(jù)庫(kù)表結(jié)構(gòu)：圖1. 數(shù)據(jù)庫(kù)表的結(jié)構(gòu)（圖源自參4）Metadata表Metadata表的作用是存儲(chǔ)用戶(hù)定制的對(duì)象和對(duì)象所包含的字段的結(jié)構(gòu)信息，不保存具體的數(shù)據(jù)，主要有兩大類(lèi)： Object Metadata表：這個(gè)表主要存儲(chǔ)對(duì)象的信息，其中主要字段包括對(duì)象的ID（ObjID），擁有這個(gè)對(duì)象的租戶(hù)的ID（OrgID）和這個(gè)對(duì)象的名字（ObjName）。 Field Metadata表：這個(gè)表主要存儲(chǔ)對(duì)象附帶字段的信息，其中主要字段包括字段的ID（FieldID），擁有這個(gè)字段的租戶(hù)的ID（OrgID），這個(gè)字段的名字（FieldName），這個(gè)字段的數(shù)據(jù)類(lèi)型（datatype）和一個(gè)布爾字段（IsIndexed）來(lái)定義這個(gè)字段是否需要被檢索。 Data表Data表的作用和Metadata表正好相反，它主要存儲(chǔ)那些用戶(hù)定制的對(duì)象和對(duì)象所包含的字段的數(shù)據(jù)，主要也包括兩大類(lèi)： Data表：這個(gè)表放置著上面那些對(duì)象和字段所對(duì)應(yīng)的數(shù)據(jù)，核心字段有全局唯一的ID（GUID），租戶(hù)ID（OrgID），對(duì)象的ID（ObjID）和存放對(duì)象名字的Nature Name（自然名稱(chēng)），比如這行和一個(gè)會(huì)計(jì)對(duì)象有關(guān)，這行的Nature Name字段可能是Account Name，除了這些核心字段之外，這個(gè)表還有名字從Value0到Value500的501個(gè)數(shù)據(jù)列來(lái)存儲(chǔ)數(shù)據(jù)，而且這些列都是varchar的形式來(lái)承載不同類(lèi)型的數(shù)據(jù)，這種數(shù)據(jù)列也被稱(chēng)為flex列。 Clob表：這個(gè)表主要存放那些CLOB（Character Large Object，字符大對(duì)象）數(shù)據(jù)，對(duì)象最大支持到32000個(gè)字符。 Pivot表Pivot表，也稱(chēng)為數(shù)據(jù)透視表，在F中是以denormalized （去規(guī)范化）格式存儲(chǔ)那些用于特殊目的的數(shù)據(jù)，比如用于檢索（indexing），唯一性和關(guān)系等，主要作用是加速這些特殊數(shù)據(jù)的讀取以提升系統(tǒng)整體的性能。主要有五種Pivot表： Index Pivot表：由于Data表里面數(shù)據(jù)都是以flex列的形式存儲(chǔ)，所以很難在Data表的基礎(chǔ)上對(duì)表中的數(shù)據(jù)進(jìn)行檢索，所以F引入Index Pivot表來(lái)解決這個(gè)問(wèn)題，系統(tǒng)在運(yùn)行的時(shí)候會(huì)將需要索引的數(shù)據(jù)從Data表同步到Index Pivot表中相對(duì)應(yīng)的字段來(lái)方便檢索，比如這個(gè)數(shù)據(jù)的類(lèi)型是日期型的，那么它將會(huì)被同步到Index Pivot表中的日期字段。 UniqueFields Pivot表：這個(gè)表是用來(lái)幫助系統(tǒng)在Data表中字段實(shí)現(xiàn)唯一性。 Relationships Pivot表：F提供了Relationship這個(gè)數(shù)據(jù)類(lèi)型來(lái)定義多個(gè)對(duì)象之間的關(guān)系，而Relationships Pivot表則起到方便和加速Relationship數(shù)據(jù)讀取的作用。 NameDenorm表：是一個(gè)簡(jiǎn)單的數(shù)據(jù)表用于存儲(chǔ)對(duì)象的ID（ObjID）和這個(gè)對(duì)象的實(shí)例的名字，主要讓一些僅需獲取名字的查詢(xún)調(diào)用，從而讓一些簡(jiǎn)單的查詢(xún)無(wú)需查詢(xún)規(guī)模龐大的Data表。 FallbackIndex表：這個(gè)表將記錄所有對(duì)象的名字，來(lái)免去成本高昂的UNION操作，從而加速查詢(xún)。 3.9 APEXAPEX的語(yǔ)言是為F度身定做的一門(mén)語(yǔ)法上類(lèi)似Java的強(qiáng)類(lèi)型面向?qū)ο笳Z(yǔ)言，主要可以通過(guò)APEX在F上創(chuàng)建Web Service，編輯復(fù)雜的商業(yè)邏輯和整合多個(gè)F的模塊等。APEX主要以?xún)煞N方式執(zhí)行：其一是以單獨(dú)腳本的形式，按照用戶(hù)的需要執(zhí)行。其二是以觸發(fā)器的形式，當(dāng)一個(gè)特定的數(shù)據(jù)處理事件發(fā)生的之前或者之后，與這個(gè)事件綁定的APEX代碼將會(huì)被執(zhí)行。而且所有APEX代碼將會(huì)以Metadata的形式存儲(chǔ)在Metadata表內(nèi)。當(dāng)一段APEX代碼被調(diào)用的時(shí)候，APEX的翻譯器（runtime interpreter）將會(huì)從Metadata Cache讀取編譯之后的APEX代碼，而且能夠同時(shí)被多個(gè)租戶(hù)共享以提升效率。那么為什么要在F引入APEX這門(mén)新的語(yǔ)言，而不是像Google App Engine那樣支持已經(jīng)有一定市場(chǎng)占有率的語(yǔ)言，比如Java和Pyhon。Salesforce的首席架構(gòu)師在談到這點(diǎn)時(shí)，他提出了一個(gè)非常重要的原因，那就是安全，首先，Salesforce會(huì)APEX語(yǔ)言度身設(shè)計(jì)一組管理工具，通過(guò)這個(gè)工具能夠非常方便地監(jiān)控APEX腳本的執(zhí)行，并且能知道這個(gè)腳本在執(zhí)行過(guò)程所耗費(fèi)的CPU時(shí)間，內(nèi)存容量和SQL語(yǔ)句的數(shù)量等數(shù)據(jù)來(lái)判斷是否需要中斷這個(gè)APEX腳本，以避免影響到屬于其他租戶(hù)的應(yīng)用，如果中斷的話(huà)，系統(tǒng)會(huì)拋出一個(gè)runtime exception給上層的調(diào)用者。其次，基于APEX語(yǔ)言的代碼能夠?qū)ζ鋬?nèi)嵌的SOQL（Sforce Object Query Language）和SOSL（Sforce Object Search Language）進(jìn)行驗(yàn)證來(lái)避免實(shí)際運(yùn)行時(shí)出現(xiàn)錯(cuò)誤。還有，在安全方面除了APEX自帶的功能之外，Salesforce還要求每個(gè)上傳到F的APEX腳本，都需要自帶能覆蓋其75%代碼的測(cè)試用例，這種做法不僅顯著地提升APEX代碼的質(zhì)量從而確保平臺(tái)整體運(yùn)行的穩(wěn)定，而且在F自己更新的時(shí)候，能使用這些用例來(lái)確保新的更新不會(huì)影響現(xiàn)有的基于F的應(yīng)用。4 總結(jié)4.1 設(shè)計(jì)理念根據(jù) Craig Weissman 的演講和幾份官方的白皮書(shū)，在F的設(shè)計(jì)方面Salesforce團(tuán)隊(duì)主要有下面這五大考量： 數(shù)據(jù)驅(qū)動(dòng)：由于 Salesforce 主要面向企業(yè)用戶(hù)，導(dǎo)致其上面運(yùn)行的應(yīng)用，無(wú)論是 CRM ，還是報(bào)表工具，都是以數(shù)據(jù)的CRUD（增刪改查）為核心，所以 F 需要由數(shù)據(jù)來(lái)驅(qū)動(dòng)，而且也需要為此做一定程度的優(yōu)化。 規(guī)模經(jīng)濟(jì)：由于需要在低價(jià)格和靈活付費(fèi)的基礎(chǔ)上提供可定制化應(yīng)用，所以需要讓盡可能多用戶(hù)共享同一套系統(tǒng)，來(lái)大幅減低基礎(chǔ)設(shè)施和管理等資源的投入，并實(shí)現(xiàn)規(guī)模經(jīng)濟(jì)的效益。 安全為先：由于在一套物理設(shè)備上將承載數(shù)以萬(wàn)計(jì)客戶(hù)的企業(yè)級(jí)應(yīng)用，那么如果出現(xiàn)嚴(yán)重的程序錯(cuò)誤或者數(shù)據(jù)方面遺失或者錯(cuò)亂，將會(huì)發(fā)生非常嚴(yán)重的后果，所以安全問(wèn)題是一個(gè) Salesforce絕不能輕視的問(wèn)題。 定制方便：雖然各個(gè)企業(yè)都會(huì)存在一部分比較通用的流程，但是每個(gè)企業(yè)都可能存在一部分私有或者獨(dú)特的流程，所以F需要提供方便的定制功能來(lái)幫助用戶(hù)將更快捷地將企業(yè)的業(yè)務(wù)遷移到其上。 功能豐富：雖然用戶(hù)能在 F 上進(jìn)行開(kāi)發(fā)和定制，但是如果 F 能提供更多的功能模塊或者能讓用戶(hù)購(gòu)買(mǎi)和整合第三方的應(yīng)用將非常有效地幫助用戶(hù)開(kāi)發(fā)應(yīng)用。 雖然這些設(shè)計(jì)理念說(shuō)起來(lái)很容易