SAE

SAE從架構上採用分層設計，從上往下分別為反向代理層、路由邏輯層、Web計算服務池。而從Web計算服務層延伸出SAE附屬的分散式計算型服務和分散式存儲型服務，具體又分成同步計算型服務、非同步計算型服務、持久化存儲服務、非持久化存儲服務。各種服務統一向日誌和統計中心彙報，參考下圖：

Level7 Reverse Proxy（7層反向代理層）：HTTP反向代理，在最外層，負責響應用戶的HTTP請求，分析請求，並轉發到後端的Web服務池上，並提供負載均衡、健康檢查等功能。

徠Service Router（服務路由層）：邏輯層，負責根據請求的唯一標識，快速的映射（O(1)時間複雜度）到相應的Web服務池，並映射到相應的硬體路徑。如果發現映射關係不存在或者錯誤，則給出相應的錯誤提示。該層對用戶隱藏了很多具體地址信息，使開發者無需關心服務的內部實際分配情況。

Web Service Pools（Web服務池）：由一些不同特性的Web服務池組成。每個Web服務池實際是由一組Apache(PHP)組成的，這些池按照不同的SLA提供不同級別的服務。每個Web服務進程實際處理用戶的HTTP請求，進程運行在HTTP服務沙盒內，同時還內嵌同樣運行在SAE沙盒內的PHP解析引擎。用戶的代碼最終通過介面調用各種服務。

Statistics Center & Log Center（日誌和統計中心）：負責對用戶所使用的所有服務進行統計和資源計費，並設定的分鐘配額，來判定是否有非正常的使用。分鐘配額描述了資源消耗的速度，當資源消耗的速度到達一個預警閾值時，SAE通知系統會提前向用戶發出一個警告，提醒用戶應用在某個服務上的使用可能存在問題，需要介入關注或處理，配額系統是SAE用來保證整個平台穩定的措施之一；日誌中心負責將用戶所有服務的日誌匯總並備份，並提供檢索查詢服務。

各種分散式服務：SAE提供復蓋Web應用開發主要方面的多種服務，用戶可以通過StdLib（可以理解為SAE PHP版的STL）很方便的調用它們。同時因為Web服務的多樣性，SAE的標準服務不可能滿足所有場景的需求，所以SAE通過服務匯流排來對接第三方服務（如分詞、全文檢索等），SAE也歡迎第三方服務商選擇SAE來為開發者提供服務。

真正的用戶代碼是跑在SAE提供的Web運行環境下的，為了提供公有雲計算特有的安全性，SAE設計多層沙盒來保證用戶應用之間的隔離性。參考下圖：

最內層的就是用戶代碼，大部分PHP代碼不需要做任何修改就可以跑在SAE平台上。小部分代碼需要做一些修改以適應SAE的平台特性。這主要有，SAE因為安全性禁用了本地IO，所以fwrite等函數需要修改為使用TmpFD讀寫本地臨時文件或者直接通過Storage服務讀寫我們的分散式文件存儲。

PHP Zend為標準的PHP官方解釋器。

SAE Zend Sandbox為一個邏輯概念，為用戶的代碼運行提供良好的隔離性。這裡有兩個層面：

1、是通過標準的php.ini，我們設定了一些特殊配置和禁用函數；

2、為了達到一些php.ini無法實現的沙盒功能，我們對Zend解釋器核做了一些改進，以便通過用戶標識將資源進行隔離。另外我們還把一些SAE的特定服務也在Zend層做了融合。

Apache為標準的Apache Web Server。不過我們禁用了htaccess，並提供了自己實現的替換方案AppConfig。用戶可以通過類自然語言的方式編寫AppConfig，如- compress: if(out_header["Content-Length"] >= 500) compress 表示按條件啟動頁面壓縮。AppConfig提供的功能有：目錄默認頁面、自定義錯誤頁面、壓縮、頁面重定向、頁面過期、設置響應頭的content-type、設置頁面訪問許可權。我們選擇自行實現AppConfig還有一個考慮，就是因為傳統Apache的htaccess因為要按目錄遞歸方式合併配置文件，效率不能滿足SAE的需求。

HTTP Server沙盒為Apache的安全可靠運行提供了多種保護功能，比如防止某個用戶惡意佔用連接數從而導致整個Web服務不正常。

最外層的是標準POSIX環境，我們的服務跑在Linux上。

接著將詳細討論我們架構設計的特點。

擴展性是分散式系統的兩個主要目的之一，SAE作為公有雲計算，同樣把服務的擴展性作為架構設計的重要指標，要求在用戶增長、壓力提升的情況下，可以實現自動的服務擴展，同樣的當壓力降低時，可以將服務收縮，以節約資源，整個過程無需人工參與。SAE人工只需做好容量規劃和管理。國外的公有雲計算架構的擴展性主要有兩個思路：

靜態擴展，用戶和資源有強綁定關係。最典型的例子為亞馬遜的EC2和Ruby雲計算平台Heroku，用戶申請的資源和用戶有嚴格的一對一關係，換句話說，A用戶申請的虛擬機在A退還資源前，B用戶不能使用，哪怕A用戶的虛擬機處於閑置狀態。

動態擴展，用戶和資源沒有強綁定關係。最典型的例子為Google App Engine，用戶申請的資源和用戶沒有嚴格的一對一關係，換句話說，處理A用戶請求的進程在處理完之後，可以馬上處理B用戶的請求。

兩種擴展性各有利弊，靜態擴展的長處是為平台提供了良好的隔離性，資源可以固定的映射在某個用戶下，但缺點是資源利用率不高；動態擴展的長處是資源利用率高，這樣整個雲計算平台的成本會很低，但缺點是對隔離性有更高的要求，因為資源可以在很短的時間被多個用戶使用。相比較，在安全性上，動態擴展要比靜態擴展的技術門檻更高。

在SAE平台上，我們採用以動態擴展為主，靜態擴展為輔的兼而有之的設計。在Web計算池層，是典型的動態擴展，沒有一個用戶獨佔Web服務進程，而是所有用戶以共享的方式使用Web服務進程，通過Cache，熱的用戶自然在緩存層佔據更多的位置。而在SAE的某些服務中，擴展性又是以靜態擴展的方式展現，如RDC（Relational DB Cluster）分散式資料庫集群，當用戶申請了MySQL服務，我們就會在RDC後端根據SLA的級別創建一主多從的DB給用戶，在用戶顯式的刪除該DB前，該DB都不會被別人使用。當然，通過RDC，任何一個用戶也無需知道後端DB的實際地址，只需訪問RDC統一的host和port即可。

HA是分散式系統的另一個主要目的，SAE同樣以提供服務的高可靠性為架構設計的重要指標。HA的實現途徑主要有兩個，一個是硬體保證，一個是架構的冗餘設計。

在SAE平台上，所有伺服器都是新浪標準採購的硬體設備，運行在國內最好機房內，並進行多機房容災，網路資源方面則享用門戶網站所使用的帶寬環境。另外，所有的硬體設備都有專門的運維部門負責，故障的響應速度和新浪內部服務一樣。

在架構設計上，SAE通過對所有服務都進行冗餘設計來提供服務的高可靠性。這裡的服務可以分成計算型和數據型兩種類別討論：

針對計算型程序，冗餘設計就是程序在多節點運行。但這樣會帶來一致性問題，最主要的困擾就是選舉問題，如何在多個節點中選出一個主節點來執行。比如SAE上的分散式定時服務Cron，採用多點部署方式，多個計算節點相互隔離，通過時鐘同步服務同時觸發用戶設定的定時任務，但要求只能有一個節點負責執行。為了解決這個問題，SAE設計出了一套分散式鎖演演算法來提供選舉服務。該演演算法可以在犧牲某些特定條件下的一致性來提供比Paxos演演算法更高的可靠性（3台機器在最高任意2台機器發生故障的情況下整個選舉過程仍然正常，而Paxos演演算法最多容忍1台）。目前（截止至2012年12月）該演演算法正在申請專利，並廣泛應用在SAE內部。

針對數據型服務，SAE主要是通過複製來保證服務的高可靠性。SAE上的數據存儲服務普遍採用被動複製和主動複製兩種方式。如SAE上MySQL之間的主從Binlog同步就是典型的被動複製，TaskQueue、DeferredJob等服務也採用被動複製的方式，用戶的任務描述會寫到到主內存級隊列中，主隊列利用後台線程將寫操作同步到從隊列上，一旦主隊列發生故障，從隊列會快速的切換為主隊列。另外SAE上也有部分服務採用主動複製（雙寫複製）的方式來保證HA，比如Cron，當用戶通過App的工程配置文件appconfig.yaml設定定時任務時，任務信息會以雙寫的方式寫到多個持久化DB中，以供後續的到時觸發。

另外，SAE在整體架構設計時，充分考慮服務之間的“優雅降級”，盡量降低服務之間的耦合度，我們要求任何一個服務都不要假設其他服務是可靠的。SAE平台上的所有服務均不存在單點設計，服務的平均HA在99.95%，即年平均服務不可用時間在4到5個小時之間。

· SAE平台出口IP：

220.181.129.126

220.181.129.121

220.181.136.229

220.181.136.230

http介面方需要IP授權可以進行相應的設置。