百度技術沙龍第9期 App Engine 技術應用
本文做者：HelloDeveloperphp
在 2010 年 12 月 18 日第 9 期的百度技術沙龍活動中，咱們請到了百度基礎平臺部高級軟件工程肖偉和新浪SAE 經理叢磊，分別分享了百度和新浪的 App Engine 技術及其應用話題。如今對他們的的分享簡單總結以下，並提供相關音視頻等資料的下載。前端
百度應用開發引擎linux
在肖偉的演講中，主要介紹了百度App Engine 的項目內容應用以及和其餘公司 App Engine 的不一樣之處：算法
通過半年多的推廣，百度 App Engine 已經初見成效，雖然項目名字是 Baidu App Engine（BAE），可是和google的GAE內容是徹底不同的，在不少功能上都作了優化，它的定位也是面向企業的雲平臺服務。它的定義有如下幾個方面：數據庫
面向開發者的單機環境編程
面向程序執行的分佈式環境緩存
面向運維的自動化工具鏈安全
面向分佈式的多語言編程框架服務器
統一管理百度全部分佈式資源網絡
所以對於 BAE，你們的理解應該是面向網絡的操做系統，而不是一個開發平臺。肖偉爲了說明這個問題拿了 Windows 程序來與百度互聯網服務比較，從功能、表明產品、開發工具、開發技巧以及運行環境等方面來進行的闡述，爲何把 Baidu App Engine 稱做是一個網絡操做系統。經過比較，你們也大概瞭解了，BAE 只是在名字上相似，其實徹底是不同的，百度的產品是解決公司企業問題的雲服務。接下來肖偉又開始給你們介紹 BAE 的使用模式和特色：
統一集羣、多產品使用 ；每一個產品帳號擁有獨立的資源 ：CPU、帶寬、內存容量、存儲容量 等，所以資源能夠根據服務熱度，動態調整 ；支持傳統服務的移植 ：直接移植 ；少許修改移植；
在這以後內，肖偉把 BAE 和業界其餘雲服務平臺進行了對比，讓你們對其優缺點一目瞭然：在進行了對比以後，肖偉宏觀的陳述了 BAE 的架構：
全部雲服務資源化，支持多帳號限額訪問
提供管理這些資源的平臺
提供用戶使用這些資源的程序運行環境
其它輔助工具
以上就是 BAE 的一個簡單的架構，用戶請求傳至 7 層負載以後，就會扔給計算結點，計算結點接到請求就會循序漸進的進行處理。若是機器發生變化，好比發生死機或者你進行擴容，咱們會有一個定位服務器，服務發生變動就會通知到這裏，定位服務器再反饋到 7 層負載，而後傳給計算結點，你就能找到合適的資源進行處理。
對於定位服務器的定義和功能，肖偉是這樣解釋的：
管理程序啓動的進程組，這些進程有可能在本機，有可能在其餘機器上；
管理進程組下每一個進程的狀態和配置；
動態監控進程組下進程的變化；
能將進程變化信息實時推送給監聽者；
計劃提供 DNS 服務。
對計算結點，肖偉也進行了說明：
計算結點是用戶進程執行的環境 ；
提供多語言支持 ：對於 c 語言就是虛擬機 ，對於 php 就是 php 解釋器 ；
提供分佈式化支持 ：對虛擬機進程和鏡像的調度 ，對 php 解釋器進程（fastcgi）和 php 代碼的調度 。
最後肖偉舉例進行說明，首先演示了 PhP 的架構，解釋如何伸縮資源和更新代碼的細節問題，以及對進程調度粒度還有如何進行不一樣服務的進程隔離都作了詳細的描述。同時也介紹了分佈式數據庫、分佈式 KV 存儲以及消息隊列等等其餘功能性服務。目前百度的中小型 PhP 網站都是用這個 PhP 框架來作的，而且之前的網站也都挪過來了。但僅是 PhP 框架仍是遠遠不夠的，做爲一個搜索引擎公司，怎麼把數據分析、大規模計算以及不少不少的 C 語言、Java 等服務統一運維來，天生的分佈式化呢，咱們目前展開了如下工做，第一就是支持 linux 老服務遷移 ，第二開發 C 語言分佈式開發框架 。
在講完 PhP 以後，肖偉開始向你們介紹他們是如何對 C 語言進行支持的：
不只是 C 語言框架，就是對純 C 語言也是支持的。C 服務於 PhP 框架有什麼區別呢？就是虛擬機進程取代 fastcgi 進程，即載體取代載體，fastcgi 進程上有 PhP 編譯器來運行 PhP，那麼虛擬機取代之後也能夠運行任何語言。
隨後肖偉又列出了兩者之間比較的框架並像開始那樣對虛擬機框架也進行了演示。並着重解釋了虛擬機內的進程通信及其優化。
在最後，肖偉現場回答了你們在新浪微博上以及現場的提問：
BAE 的 PhP 能夠寫本地目錄嗎？
咱們的全部文件均可以寫本地目錄，並且它能夠作分佈式化，這涉及到運維的策略，有兩個方案，第一個是我提供分佈式文件系統，經過 VFS 虛擬文件接口把遠程磁盤掛載進來，全部人共享這個磁盤的話，PhP 寫一個磁盤是能夠的，並且也不會由於服務流量的增長而出現瓶頸問題，由於咱們的雲存儲能夠多作副本，而後在前面加分佈式緩存就能解決；第二就是一些很是大的數據咱們經過腳本運維的方式解決，不過要是快的話，咱們建議修改之前操做本地數據的 API 改爲個人 API，數據咱們幫你導過去。由於寫本地的數據很是小，能達到一個 T 就不錯了。因此咱們容許寫本地目錄，並有辦法把它同步到其餘服務器上去。
Fastcgi 如何解決 PhP 依賴文件調度
是 require once 嗎？這個得說清楚，若是是的話，根本不存在依賴的問題，由於咱們的代碼是存在雲端的，若是發現本地緩存沒有這段代碼的話，會去發請示網絡請求所要代碼，並加載到本地。若是有的話就能夠直接讀，跟實際中的用法沒有區別。
BAE 用的是什麼虛擬機？
你們若是仔細看的話，虛擬機只是個幌子，它能夠是物理機，之因此我說虛擬機，這是有歷史緣由的，由於以前提到，並非全部的服務均可以不用修改的遷移過來，只能利用虛擬機把它的資源利用率提升，其實這個方案不只是虛擬機能作的，物理機也能夠。
Java 應用是如何分佈式化的？
若是是進程的話，能夠用我剛纔的這套方案，可是要配合 Java 的編程框架；另一個是這樣的，好比說 JSP，雖然如今尚未作，可是要是作出來的話，仍是和 fastcgi 同樣。咱們如今仍是隻作 PhP 和 C 的。PhP 已經完成，C 語言項目正在開展中。
BAE 對開發者開放有沒有計劃表？
以前的介紹中你們已經看到，BAE 跟其餘產品比較有兩點不好，一個是安全性，一個是存儲度，如今仍是不能推薦給你們用，由於我不相信互聯網用戶不會搞破壞，只要有人找一個漏洞，個人精力就不能放到繼續完善中來，二是不停的解決安全性問題，這對產品的發展沒有太大的好處。咱們還準備研發一種技術，可以對機器的進程進行監控，並把監控的進程彙報給定位服務器，若是咱們作了這個技術之後，Java 進程仍是能夠作的，可是如今尚未考慮。
深刻SAE雲計算架構
新浪的 SAE 技術經理叢磊給咱們分享了的是 SAE 雲計算架構的話題。
在以前的一些活動和文章中，已經作過關於新浪 SAE 相關內容的陳述，此次話題在之前一些表面架構介紹的基礎上，又有所深刻，進入雲服務裏面，進行一些更細節具體的介紹。SAE 是新浪在 2009 年 11 月開始研發的國內公有云計算平臺，目的是打造一個 Web 服務的運行和運營的平臺，一直到如今，SAE 的發展趨勢已經達到預期的目標。
今天 SAE 話題的主要內容有 4 個部分：SAE 上的雲服務（Cloud Sevice）、RDC（ Relational Database Cluster：分佈式數據庫集羣）、MemcacheX（新版分佈式緩存）、TaskQueue（異步離線任務隊列服務）。
SAE 上的雲服務（Cloud Sevice）：
SAE 和虛擬主機最大的區別就是它提供了特別多的分佈式服務供開發者使用，而虛擬主機是沒有的。目前新浪要的服務如下內容：PhP、Stor、MemcacheX、Datebase、RDC、TaskQueue、Cron（分佈式定時服務，新浪目前採用了一種比 paxos 級別還要高的算法，目前正在爲這種算法申請專利）、DeferredJobs、fetchurl、tmpfs、appconfig、smail、 image、xhprofc 等十幾項內容。
接下來叢磊一樣給咱們繪出了 SAE 的架構圖並介紹了用戶代碼運行的環境：
首先是一個反向代理（Level7 Reverse Proxy）接應外部請求，經過邏輯上的 Service Router 轉發到相應的 Web Service Pools（阿帕奇的進程池）上，而後往外延伸至四個主要服務分類：同步計算雲、異步計算雲、可持久化存儲、非可持久化存儲。這四個服務分類最後會統一貫統計中心和日誌彙報。
用戶代碼運行環境 App Sandbox 組成由內到外分別爲：User App、PhP Zend、SAE Zend Sandbox、Apache with SAE Appconfig、Http Sever Sandbox、POSIX Environment。
而後接下來在話題分享中，叢磊把 RDC（ Relational Database Cluster：分佈式數據庫集羣）、MemcacheX（新版分佈式緩存）、TaskQueue（異步離線任務隊列服務）這三個重點給你們作了詳細的介紹。
RDC（ Relational Database Cluster）：
是一種面向公有云計算服務的數據集羣，它的主要目標或者功能以下：
1．監控百萬數量級的 DB，包括心跳檢查、主從同步檢查、節點負載；
2．管理百萬數量級的 DB，包括啓動、中止、遷移、重啓、切換；
3．被動複製模式的 HA；
4．支持 MySQL5 通信協議，代理層徹底透明，代理損耗低；
5．無狀態依賴，自身支持水平擴展；
6．提供用戶的 DB 的隔離性，保證總體集羣的安全性。
以後，叢磊又向你們介紹了 RDC 與 SQL 在實現上的不一樣，並特別指出：
1．RDC 不負責用戶數據庫的水平擴展，因此水平擴展須要用戶本身作分表；
2．RDC 自身提供一主多從的 DB 結構，上層支持讀寫分離；
3．爲了整個數據庫平臺的安全和可靠，RDC 會根據自身的預判算法預先屏蔽某些 SQL 語句，目前這個預判算法新浪也正在準備申請專利；
4．RDC 強烈建議用戶使用正確的 MySQL 調用習慣，對每一個 MySQL 函數判斷返回值。
介紹這些以後，叢磊又跟你們分享了 RDC 的結構、用法以及其運行環境要求等。而後進入第二個重點話題介紹—MemcacheX（新版分佈式緩存）：
MemcacheX 就是新版的分佈式緩存。在以往的分佈式緩存中，若是用戶須要 Memcache 服務，咱們就給開啓一個 Memcache 實例，若是發現宕掉以後，就會立刻作一個遷移，這個遷移是沒有數據遷移的，直接再從新起來一個，把原來的映射關係轉過去。咱們仍然須要把用戶的繼承放在這裏，這就形成了一種資源的浪費。MemcacheX 就考慮到了這一點並作了優化，即 low overhead；
第二個就是 HA 的問題：以前包括新浪內部也有過幾回大的運維事故，所以以爲 HA 對於開發者來講更加的重要。在之前的 Memcache 中存在這樣的問題：宕掉以後再從新起一個是有問題的，由於從新起的 Memcache 是空的，用戶須要時間預熱。MemcacheX 中就不存在這樣的問題，即時有一兩臺機器宕掉，但 Memcache 對用戶的服務是正常的。
還有一點就是 Connection Protector：這也是根據咱們內部的需求來的，咱們發現併發很是大的時候，因對於 PB 人員的水平不一樣的緣由，極有可能會有服務器 Socket 不能及時被關閉。MemcacheX 就增長了主動關閉服務器 Socket 的功能；
最後就是 MemcacheX 增長了 Date dump 的功能，加快用戶數據預熱時間。
接下來，對 MemcacheX 的結構和用法作了詳細說明後，叢磊開始了最後一個分享的重點：就是 TaskQueue（異步離線任務隊列服務）。
TaskQueue 就是一個簡單的任務離線處理隊列，好比說，一個 Web 開發者要給 100 我的或者 1000 我的發微博，你確定不能寫一個循環去賦 100 次或者 1000 次發微博。因此把任務放到離線處理的隊列裏去，讓隊列離線去處理，能保證頁面時正常。它與 Deferredjob 不一樣，後者是一個重量級離線任務處理隊列。TaskQueue 只是回一個 URL，真正執行的仍是用戶的 PhP 代碼；Deferredjob 是系統在執行，是一種 C 語言級的代碼。
最後，在介紹完 TaskQueue 的結構和用法以後，叢磊向你們透露了下一步 SAE 的計劃：
第一個是新的代碼部署文件系統：爲了更好的提供服務，須要設計具備更高可靠性和一致性的代碼部署文件系統。
第二就是無縫遷移：這是一個重點項目，爭取把全部用戶的 PhP 代碼不作任何修改轉化直接轉換遷移到 SAE 上來。第三個我就很少說了，就是 Key-Value 數據庫，也是下一步工做計劃之一。
分享結束後叢磊現場回答了參會者經過微博或者直接提出的幾個問題：
如何進行代碼重構和數據結構的變換？
首先是代碼重構，咱們 SAE 已經有版本切換，作代碼重構的時候能夠切換到一個測試版本，本身去作去，作完以後在合到默認版本里，如今 SAE 都支持。而後說數據結構的更改，我以爲可能說的是表的修改，若是是這樣，你執行大量數據，好比說 Auto Table，絕對會被攔截掉，可是能夠用咱們的 DeferredJobs 來實現。
GD 庫中的函數比較耗 cpu，但 SAE 也有 cpu 方面的計費機制，請問 SAE 能支持 PhP 中的 GD 庫嗎？
如今 SAE 自己在前端並無把 GD 模塊編譯進去，而是提供了 Image 服務，這是跟咱們的理念同樣的，就是說咱們但願吧 cpu 逆行的服務單獨放到一個計算池裏去。若是支持 GD 的話可能就會打破這個設計，可是請提問的人放心，咱們立刻就能支持無縫遷移 GD 代碼。若是能夠的話，這個服務代碼明年一月份就能完成。
在兩位精彩的分享以後，就是咱們百度技術沙龍的 OpenSpace 環節，在這個環節裏你們自由分組積極的參與了相關話題的討論，並由話題提出人對各自話題小組的討論進行了分享。
會後，來自鳳凰網的資深架構師孫立在他的我的博客裏發表了我的對本期百度技術沙龍的總結並分享了本身所在 OpenSpace 話題小組的內容和見解。