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個小時之間。
線路特性
·平臺出口IP：
220.181.129.126
220.181.129.121
220.181.136.229
220.181.136.230
http接口方需要IP授權可以進行相應的設置。