創建現代化的大規模應用程序是一件令人生畏的任務。客戶期望獲得高性能及快速的響應，並且“隨時隨地可以訪問”他們的數據。運營團隊希望應用程序易於配置、維護、遷移及問題診斷。開發團隊希望能使用類似的技術范式，使用簡單的API，有著易用的工具並能充分利用現有的人員及遺留的基礎代碼。最後，業務人員要求應用程序具有競爭優勢：他們希望應用程序成本適中，能快速推向市場，並能夠快速應對不斷變化的業務策略。在以往，我們基本可以確定，企業將不得不放棄很大一部分的需求，以求將應用程序盡快發布。即便如今，也時常見到各種不同的技術被混合在一起，去打造一個拜占庭建築式（大規模）的大型項目。這種項目往往結構脆弱、速度緩慢並且過於復雜化。現如今，雲端技術、平台即服務（PaaS）以及NoSQL這些相關技術的大量湧現正好能夠應對這部分的缺失，而它們的出現並非偶然。擺在眼前的現實是，要想“按照正確的方法做事”，同時又要滿足利益相關者的各種需求並非易事，它需要我們摒棄陳舊的模式，采取新的思考方式。
大約6年前，FatCloud的姐妹公司Wilshire Media為CBS Radio、AOL和Yahoo等公司提供了當時最大的流媒體Web服務。這些項目的開發過程都有著近似的特征，面臨的挑戰也幾乎相同。我們發覺自己在不斷地做著重復的事，卻始終沒有簡化這些項目的開發。我們急需一個完整的解決方案，它能夠做到以下幾點：
以一種靈活且容錯性強的方式在多個結點間進行通信。
存儲、獲取及查詢數據和文件。
緩存數據。
為達到最大負載能力，盡可能並行化並消除網絡延遲。
為經常變更的業務邏輯提供同步與異步多線程處理兩種工作方式。
對集群進行擴容或重新配置時，將停機時間降至最低。
對大型集群實現自動化配置、監控及維護。
如果產品投放市場時間非常重要，可以嚴格控制研發時間。
我們隨即領悟到：我們可以充分利用之前工作中的經驗，在此流程中盡量滿足利益相關人的要求並減少業務上的犧牲。解決這些問題的關鍵是一個簡單的概念：將企業級應用的關鍵特征抽象概括為一個已證明的、可重用的、高性能的、容錯性強的、高度集成並且分布式的平台。實現這一方式的支點就是我們如今稱為面向任務架構（Mission Oriented Architecture）或MOA的方法。而這個通用框架如今已經演化成為我們所知的FatDB平台技術了。大約兩年前，FatDB這項技術進行了首次主要的測試，當時美國的Cricket Wireless公司推出了一項移動音樂服務Muve music，這項服務如今已經有超過一百萬訂閱用戶了。Muve的後台幾乎全部是基於FatDB平台搭建的，它運行在幾百台服務器上。從那時起，我們圍繞著這門技術成立了FatCloud公司。能夠基於FatDB平台創建的應用程序種類的數量是沒有限制的，而且FatDB的應用范圍也跨越多個垂直行業。我們的使命是為微軟開發社區提供這項技術，以簡化企業開發的復雜性和降低成本。我們希望幫助我們的客戶避免那些我們曾經犯過的錯誤。通過為客戶提供一系列強大與成熟的構建塊，就可以幫助他們徹底改進創建大規模web應用的方式，並且克服每一項挑戰。
那麼FatDB平台都包含了哪些構建塊呢？它的核心產品一共可分為九個部分：
核心基礎– 這一部分為FatDB平台的所有組件提供了基本功能。
FatDB / Cache – 一個最優秀的NoSQL數據庫以及內存緩存服務。
FatFMS – 一個分布式文件管理服務。
FatWQ – 一個異步批量任務的隊列及處理服務。
FatApps – 一個軟件開發包（SDK）以及一套支持基於同步的WCF服務的架構。
FatProcessors – 一個SDK以及一套提供了異步批量任務處理路由的架構，並且與FatWQ相集成。
FatDB Management Studio （FatDBMS）- 一個圖形用戶界面，允許用戶在他們的各種開發環境（開發環境，測試環境與生產環境等等）中對他們的服務器、數據以及業務邏輯進行配置、檢查、監控、查詢、發布以及維護。
與SQL集成– FatDB、FatWQ、FatFMS以及FatDBMS的一個功能子集，它允許用戶通過一系列方式利用FatDB核心服務的強大功能，並且保留甚至增加了在SQL Server中的使用習慣。
Map/Reduce式分析 - FatDB、FatWQ、FatFMS以及FatDBMS的一個功能子集，它允許用戶進行數據挖掘或在線分析處理（OLAP）式的分析，能夠將數量巨大的原始數據進行提煉，作為下一步發展提供參考的商業度量值。
核心基礎部分由一系列的API所組成，並且對所有用戶可見，這意味著創建FatDB或FatFMS這些核心服務所需的一切，都可以由用戶自由使用，讓他們創建屬於自己的服務。以下是這個核心基礎的基本功能：
可移植的應用程序托管 – FatCloud是一個作為Windows服務運行的應用程序托管，而通信的終結點是由WCF實現的，這為微軟技術的開發者提供了一個標准而熟悉的范式。FatDB平台集群可以將提供業務邏輯的WCF服務作為一等公民直接暴露並提供托管服務。不僅如此，FatDB平台服務端軟件可以在任何虛擬或實體Windows server系統上運行、進行沙盒測試或直接托管。甚至可以把它遷移到任何公共IaaS（基礎架構即服務）平台、公司內部數據中心或某種兩者的結合體形式的環境中運行。
探索 – 集群可以通過服務器探索功能進行自我聚合，並能夠通過兩種不同方式進行廣播。一種是在可以使用UDP多播技術的任意地方使用一個探索服務中介（discovery service broker），比如Azure。另一種是基於TCP的策略，包括“閒聊（gossip）”協議。
代理及服務層 – FatCloud中的所有服務都分為兩層：代理層與服務層。代理層將服務調用路由至適當的服務器上，並對結果進行聚合。而服務層則進行實際的工作，即運行業務邏輯或者存取數據。通過對兩者進行清晰的關注分離，我們使發布的策略變得簡單了，這有助於我們消除系統瓶頸。並且在將轉發負載的任務交給代理層的同時，將繁重的本職工作控制在服務層內，使得各層職責分明。
統一路由 – FatDB平台能夠將所有的服務調用以一種統一的方式進行路由，再加上應用程序托管能力，這兩種功能的統一結合正是FatDB平台的關鍵優勢和獨特之處。FatDB依賴於一個20字節的hash鍵來提供一個定位器，它本身能夠防范沖突，並且可以在每個子集群組中均勻分布。這一概念處於FatCloud的MOA核心。每個子集群，或者說每個組都被分區為多個小塊，並提供鏡像服務以保證可用性和分區容錯。服務器將組織成一個網格，每台鏡像都能夠作為一個主分區服務，以保證負載能夠均衡地分布，這與傳統的“ring”或“master-slave（主從）”架構等相關技術都有所不同。這種結構保證了優秀的可伸縮性、容錯性以及響應速度，並且不會產生局部過熱現象。
統一的API – FatDB平台暴露了一系列API，因此開發者可以構建自己的FatApps服務和FatProcessors，並且和它的核心服務具有同樣的功能。它也包含了所有保證數據的一致性的服務調用訪問策略，包括“仲裁”（quorum）訪問、並行訪問及順序訪問。另外還包含了為反熵（anti-entropy）及維護機制所提供的鉤子和回調函數。整個API列表廣泛而全面。假設你創建的某個業務邏輯依賴於“仲裁”訪問，需要確保代碼運行於數據所在的服務器上，這時你只需在代理中加入一些簡單的基礎代碼，再加上一行回調函數即可！
FatDB是我們的旗艦服務。它是一個實現了最終一致性的多模型NoSQL數據庫，包括以下關鍵特性：
靈活的數據一致性 – 客戶可以為他們所創建的每個數據庫選擇一種數據一致性策略。一致性級別從full到weak均可選擇，並且我們很快會為多數據中心的場景提供一種全球一致性策略。
數據模型版本兼容 – FatDB中的數據可以存儲為原始的blob或透明的對象。對於後者，我們使用ProtoBuf作為序列化機制。由於我們保留了每個對象版本的元數據，為數據模型保留了很高的兼容性。簡單地說，用戶可以在今後隨意地為對象定義添加或刪除字段，而不必擔心破壞現有的客戶端功能，並且無需進行各種煩人的數據轉換操作。
加鎖 – FatDB提供了一種對象級別的加鎖功能，能夠確保同一時間只被修改一次，以此保證程序能在一個強壯的一致性級別上工作。
分布式LINQ – 我們使用了LINQ作為查詢語法，並且可以對對象定義中的字段進行索引。如果某個LINQ查詢指向了某個未被索引的字段，它就會執行一種類似於SQL中的表掃描操作。此外，它能夠對二進制大對象進行索引，以提供一些基本的查詢能力。當前版本的LINQ實現支持對象映射、排序和分頁，並且很快就能夠支持關聯查詢。
緩存 – FatDB的核心是一個基於內存的緩存，並可選擇性地持久化到磁盤中。可以使用它定義一個應用於任何數據庫的相對過期時間或絕對過期時間。（注意：目前的非持久化內存緩存還不支持LINQ查詢。）
與SQL集成 – 對於那些讀取量很大的數據，如果已經做好了遷移的准備，那FatDB可以幫助有效降低SQL server的負載。對於遷移後的SQL數據，FatDB可以作為一個高性能的持久化倉儲。FatDB還可以作為一個內存緩存，對SQL server進入同步讀取和同步寫入。它還能夠替代SQL server擔任分布式web會話緩存的職責。
Map/Reduce – 通過使用分布式LINQ，可以應用簡單的map/reduce查詢。這就允許用戶創建並執行基本的mapper和reducer語句，執行跨組的原始數據分析。
FatFMS是我們的分布式文件管理系統。在它的核心部分，FatFMS會在某個子集群裡創建所有的直接附加存儲內容，並把該子集群視為一個巨大的硬盤進行處理。FatFMS的以下方面功能值得一提。
多個拷貝 – 在FatFMS中，用戶可以在多個不同的硬盤中保存某個文件內容的多份拷貝。
靈活的獲取方式 – 用戶可以使用UNC列表、URL列表或者流的方式獲取文件。
元數據標簽與搜索 – FatFMS用戶可以使用元數據對文件加上標簽，並且搜索滿足某個指定標簽集的文件
與SQL集成 – FatFMS可以將SQL中的大對象保存為物理文件，而不是保留在SQL server數據庫中，以此減少SQL Server的負載。
FatWQ是一個高速的異步批量任務工作隊列及執行引擎，這要歸功於FatDB提供的強大功能。用戶需要提供簡單的FatProcessors的實現，以運行FatWQ中的每一個單獨步驟。開發者編寫的任意C#代碼都可以暴露為一個任務處理器（processor）。而有效地使用這一技術的核心就在於異步的“分而治之”（divide and conquer）哲學。
以下是一些應用場景的示例：
為某個銷售團隊處理輸入的銷售線索（lead）。
對商行的股票投資組合估價。
媒體文件的格式轉換。
監測商業交易中的欺詐行為。
視頻內容中的面部識別處理。
播放動畫幀。
計算Pi的N次冪。
攝入並規格化傳感器的數據包。
數據挖掘或Map/Reduce處理。
計算數量巨大的協同過濾。
FatWQ還提供了以下這些強大的特性：
以FatDB為基礎 – 因為FatDB是它的基本存儲平台，它就可以在任務所在的同一結點進行可靠的任務處理，並且能夠保證達到相同的數據一致性。
數據本地化 – 因為使用了統一路由機制，它可以直接在輸入數據所在的結點上進行任務處理，比起使用SOA進行互相通信，這種方式可獲得極大的性能提升。
可組合的任務網絡 – 單獨的任務步驟可以被組合為一種有向無環圖結構，它的執行可以達到完美的同步性，這樣就可以高度並行地執行復雜的工作流了。
按優先級調度 – 隊列中的任務可以調整優先級。
任務處理器 – 用戶可以編寫自己的任務處理器，以處理一個或多個任務步驟。
獨立隊列 – 如果用戶打算使用這套任務處理機制處理其它實體，或者以某種全新的方式利用其中的任務包裝器，那麼可以使用FatWQ以取代MSMQ的功能。
與SQL集成 – FatWQ可以有效地解除SQL server管理工作流的負擔，後者不僅速度緩慢而且相當脆弱
本欄目
企業級應用的一個關鍵部分是它的業務邏輯，FatDB平台能夠為寄宿用戶的WCF服務提供第一等的支持，並與它的核心緊密集成。以這種方式暴露業務邏輯，用戶就可以獲得底層平台的全部功能了。所有的配置以及伸縮性、路由以及冗余等這些復雜的工作直接成為了服務的一個組成部分，而無需用戶操心。這些功能是非常有價值的，當FatDB平台的應用程序托管功能與其它核心服務相結合使用時，用戶將看到一個高度集成的平台的協同作用。對於同步的請求/應答傳輸，用戶只需編寫一個傳統的WCF業務邏輯服務，並將其托管為一個FatApps即可。而對於異步處理，用戶需要創建一個程序集，該程序集中的某個類需要實現某個非常簡單的接口，它僅包括兩個方法。FatApps和FatProcessors都將通過FatDBMS發布到子群集組，並自動安裝到正確的機器上。隨後整個企業應用都可以按照這種方式編寫，這是一種全新的思路……FatCloud在子集群或組的層面，把企業應用的各個功能方面作為一個內聚的整體進行構建、部署及調整，數據及處理將作為一個整體進行處理。
過去的應用程序架構傾向於將所有東西封裝成一個巨大的黑盒，而如今的應用程序架構已經演化成高度分布式的架構，以達到最大程度的關注分離。這就是面向服務架構（SOA）的精髓，同時也反映了面向對象編程的種種概念。關注分離背後的概念是令人贊賞的，因為它隔離了各功能單元，並且促進了松耦合。不過正如OOP一樣，關注分離的口號發展得過頭也會脫離實際應用，在復雜性與性能之間必然存在一個平衡點。
性能 – 如果數據與它的處理被隔絕開，那麼存取時必然會導致額外的網絡延遲……不斷累積的延遲會最終導致系統的高吞吐，由延遲導致失敗的用例數量會不斷增長。或許你不得不尋找某種縱向擴展的解決方案，而這又增加了不必要的成本開銷。將數據與其處理結合在一起正是發明存儲過程的起因。
配置與通信 – 如今 “混搭”風似乎已經成了主流，企業希望將他們從不同供應商那裡獲取的技術揉合在一起並讓它們協同工作。但人們經常忽視的一個簡單事實是：這些技術組件不可避免地具有不兼容性，而為了讓所有組件良好地運行，用戶不得不編寫一系列的適配器與抽象層。由於缺乏一個高度整合的途徑，他們的產品就像是各種組件拼湊起來的大雜燴，充斥著大量的通信策略，對各種配置文件的維護也是一個惡夢。對這種僵硬的系統進行維護、改變或者故障修復都是非常困難的，而且必然需要投入多名頂尖技術人員對其進行維護。
擴展與轉型 - 在某個時間點上，當前的企業應用必須進行擴展以滿足不斷增加的需求。如果采用傳統的“混搭”方式，那麼每個組件都需要進行分別擴展。這對於網絡運維人員是件痛苦的事，因為他們不得不手動更新服務器與配置文件。為什麼添加了服務器卻不能直接獲得更強的能力呢？另一個更糟糕的潛在問題是，用戶也許會“把自己逼進死角”，因為應用程序架構經常會對業務邏輯做出各種假設，而當實際業務需要進行改變時，開發團隊為配合業務變動所進行的技術轉型往往開銷非常大。將各種組件整合在一起動作往往需要消耗大量時間和精力，而拆開這些組件，並根據不同的配置重新整合同樣需要消耗時間。
如果把客戶、數據與業務邏輯按照為它們所定義的任務聚合在一起，成為一個內聚的組的話，那麼很多問題都得以緩解。讓我們以一個電子商務網站作為示例：通常需要管理的組件包括用戶帳戶、願望清單、喜歡、不喜歡與訂單歷史等等。那麼首先可以創建一個“用戶組”，它包含了有可能調用的所有業務邏輯和大多數數據。另外我們知道產品目錄是必須要有的，並且需要與數據提供方的feed相整合，那麼我們再創建一個包含了這部分數據與業務邏輯的組。另外還需要處理訂單和出貨，同樣可以在屬於它們自己的組內進行定義。金融交易與報表也可以單獨成一組，不過它還會使用SQL Server的功能，畢竟這一領域是它的專長。
通過將數據與業務邏輯聚合在為它們所定義的組，在性能上的提升上就能夠獲得立桿見影的效果。此外，擴展與轉型都得到了極大的簡化，因為用戶在進行升級時只需往某個組裡添加新的服務器，或者替換現有的FatApps或者FatProcessors就可以提升整體處理能力了。最後，由於FatDB是在一個統一了路由、擴展、配置、探索與容錯能力的標准平台上創建的數據，它能夠讓用戶專注於業務邏輯，而不會成為90-90法則的又一個受害者（最後10%的開發工作占據了整個開發時間的90%！ - 由貝爾實驗室的Tom Cargill所提出）。這是FatCloud對未來的分布式計算的願景，同時也是我們的MOA產品。
我們從客戶那裡收到的需求中，最多的就是要求提供一個優秀的工具。對於運行環境進行管理的每日工作需要完成一系列的任務，而FatDB就提供了一個符合用戶習慣的用戶界面（看起來類似於SQL Management Studio），以下是現有及計劃中的特性：
基本元素的操作 – 用戶可以在集群環境、組、服務器、數據存儲、文件存儲、隊列、FatApps、FatProcessors與服務器實例等一系列地方對基本元素進行創建、查看、配置、更新以及刪除等操作。只需簡單的拖放操作就可以對元素進行重新組織，並且對服務器、數據、業務邏輯應用程序和處理器等進行分組操作。
檢查與查詢 – 用戶可以使用LINQ語法對數據存儲、文件存儲以及隊列進行檢查、編輯與查詢操作。
監控、維護、擴展及升級 – 用戶可以實時監控生產環境、組與服務器的情況，執行各種維護工作。並且可以實時進行擴展、或者對組和環境進行重新配置，而無需將整個系統停機。
在SQL server與代碼間建立綁定 – 用戶不僅可以方便地集成 SQL server，並且可以將FatDB作為緩存服務，與SQL server之間實現數據的導入或導出，以此消除性能瓶頸。作為緩存，FatDB能夠管理用戶的數據模型，並且從對象關系映射（ORM）功能集中導入或導出數據遷移對象（DTO）。SQL Server集成服務（SSIS）的數據包同樣可以進行批量操作。
Map/Reduce式分析 – 用戶可以通過運行簡單的LINQ語句，或者可視化地創建動態的任務步驟圖，以運行Map/Reduce分析。這是FatDBMS中最令人興奮的強大特性之一了，在接下來幾個月中還會有關於這部分的一系列升級和改進。
其它特性 – 產品的路線圖中也包括了對IaaS提供者的支持，例如Amazon和Azure。此外，FatDBMS還將為Visual Studio創建一個插件。
FatDB平台為開發現代化分布式.NET應用創建了一個完整的生態系統。FatCloud提供了企業創建一個完整解決方案的所有基本構建塊，這些方案可以是一個全新的系統，或是在現有架構、托管環境、軟硬件配置的基礎上對遺留系統進行增強與升級。通過引入MOA這個概念，企業不僅能創建出比傳統方式或SOA方式更為成功的應用，而且它更易於遷移到其它數據中心或IaaS平台，或者進行重新配置、維護、擴展與轉型。不僅如此，成本、磁盤空間、妥協及產品投放時間都能夠大幅縮減。FatCloud是高度整合的分布式計算應用托管平台的先驅之一，它將對當今的大規模web應用開發產生革命性的影響。
