整體架構
SAE從架構上採用分層設計，從上往下分別為反向代理層、路由邏輯層、Web計算服務池。而從Web計算服務層延伸出SAE附屬的分散式計算型服務和分散式存儲型服務，具體又分成同步計算型服務、異步計算型服務、持久化存儲服務、非持久化存儲服務。各種服務統一向日誌和統計中心匯報，參考下圖：
SAELevel7 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設計多層沙盒來保證用戶套用之間的隔離性。參考下圖：
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的線路特性
SAE· SAE平台出口IP：
220.181.129.126
220.181.129.121
220.181.136.229
220.181.136.230
http接口方需要IP授權可以進行相應的設定。
