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