熬夜的蟲子

 系統架構的定義：  

      軟件架構有很多種定義，下面是卡內基梅隆大學軟件研究所關于軟件架構的定義：  

      軟件架構是一系列相關的抽象模式，用于指導大型軟件系統各個方面的設計。軟件架構是一個系統的草圖。軟件架構描述的對象是直接構成系統的抽象組件。各個組件之間的連接則明確和相對細致地描述組件之間的通訊。在實現階段，這些抽象組件被細化為實際的組件，比如具體某個類或者對象。在面向對象領域中，組件之間的連接通常用接口(計算機科學)來實現。   軟件體系結構是構建計算機軟件實踐的基礎。與建筑師設定建筑項目的設計原則和目標，作為繪圖員畫圖的基礎一樣，一個軟件架構師或者系統架構師陳述軟件構架以作為滿足不同客戶需求的實際系統設計方案的基礎。  

 系統架構的設計目標：可靠性、安全性、可擴展性、可定制、可維護性，考慮用戶體驗、市場時機

1、為大規模開發提供基礎和規范，并提供可重用的資產，軟件系統的大規模開發，必須要有一定的基礎和遵循一定的規范，這既是軟件工程本身的要求，也是客戶的要求。架構設計的過程中可以將一些公共部分抽象提取出來，形成公共類和工具類，以達到重用的目的。
2、一定程度上縮短項目的周期，利用軟件架構提供的框架或重用組件，縮短項目開發的周期。
3、降低開發和維護的成本，大量的重用和抽象，可以提取出一些開發人員不用關心的公共部分，這樣便可以使開發人員僅僅關注于業務邏輯的實現，從而減少了很多工作量，提高了開發效率。
4、提高產品的質量，好的軟件架構設計是產品質量的保證，特別是對于客戶常常提出的非功能性需求的滿足。

常見的問題

數據庫海量數據處理：負載量不大的情況下select、delete和update是響應很迅速的，最多加幾個索引就可以搞定，但千萬級的注冊用戶和一個 設計不好的多對多關系將帶來非常嚴重的性能問題。另外在高UPDATE的情況下，更新一個聚焦索引的時間基本上是不可忍受的。索引和更新是一對天生的冤 家。
高并發死鎖：平時我們感覺不到，但數據庫死鎖在高并發的情況下的出現的概率是非常高的。
大型網站有海量圖片數據、視頻數據、文件數據等等，他們如何存儲并被有效索引？高并發的情況下IO的瓶頸問題會迅速顯現。也許用RAID和專用存貯服務器 能解決眼下的問題，但是還有個問題就是各地的訪問問題，也許我們的服務器在北京，可能在云南或者新疆的訪問速度如何解決？如果做分布式，那么我們的文件索 引以及架構該如何規劃。
最底層首先是操作系統。好的操作系統能提高好的性能、穩定性和安全性，而這些對大型網站的性能、安全性和穩定性都是至關重要的。

• 淘寶網（阿里巴巴）: Linux操作系統 + Web 服務器: Apache
• 新浪：FreeBSD + Web 服務器：Apache
• Yahoo：FreeBSD + Web 服務器：自己的
• Google: 部分Linux + Web 服務器：自己的
• 百度：Linux + Web 服務器: Apache
• 網易：Linux + Web 服務器: Apache
• eBay: Windows Server 2003/8 (大量) + Web 服務器：Microsoft IIS
• MySpace: Windows Server 2003/8 + Web 服務器：Microsoft IIS

常用的系統架構是:

下面再看服務器集群與負載

服務器群集中每個服務結點運行一個所需服務器程序的獨立拷貝，而網絡負載均衡則將工作負載在這些主機間進行分配。負載均衡建立在現有網絡結構之上，它提供 了一種廉價有效的方法擴展服務器帶寬和增加吞吐量，加強網絡數據處理能力，提高網絡的靈活性和可用性。它主要完成以下任務：解決網絡擁塞問題，服務就近提 供，實現地理位置無關性 ;為用戶提供更好的訪問質量;提高服務器響應速度;提高服務器及其他資源的利用效率;避免了網絡關鍵部位出現單點失效。
CDN （Content Delivery Network）： 幾乎在各大網站都有使用該技術。例如，使得你的網站在各省市訪問更快，其原理是采取了分布式網絡緩存結構（即國際上流行的web cache技術），通過在現有的Internet中增加一層新的網絡架構，將網站的內容發布到最接近用戶的cache服務器內，通過DNS負載均衡的技 術，判斷用戶來源就近訪問cache服務器取得所需的內容，解決Internet網絡擁塞狀況，提高用戶訪問網站的響應速度，如同提供了多個分布在各地的 加速器，以達到快速、可冗余的為多個網站加速的目的。
Squid cache，Squid服務器群，把它作為web服務器端前置cache服務器緩存相關請求來提高web服務器速度。Squid將大部分靜態資源（圖片，js，css等）緩存起來，直接返回給訪問者，減少應用服務器的負載
memcache，memcache服務器群，一款分布式緩存產品，很多大型網站在應用; 它可以應對任意多個連接，使用非阻塞的網絡IO。由于它的工作機制是在內存中開辟一塊空間，然后建立一個HashTable，Memcached自管理這些HashTable。
獨立的圖片服務器
無論從管理上，還是從性能上看，只要有可能，盡量部署獨立的圖片服務器。這幾乎成為常識了。具備獨立的圖片服務器或者服務器集群后，在 Web 服務器上就可以有針對性的進行配置優化。 

再拿幾個實際的case看一下
MySpace的站點架構已經歷了5個版本，最初只有兩臺Web服務器和一個數據庫服務器
在每個里程碑，站點負擔都會超過底層系統部分組件的最大載荷，特別是數據庫和存儲系統。
里程碑一：MySpace運行在3個SQL Server數據庫服務器上——一個為主，所有的新數據都向它提交，然后由它復制到其他兩個；另兩個全力向用戶供給數據，用以在博客和個人資料欄顯示。這種方式在一段時間內效果很好——只要增加數據庫服務器，加大硬盤，就可以應對用戶數和訪問量的增加。
里程碑二：MySpace注冊數到達1百萬至2百萬區間后，數據庫服務器開始受制于I/O容量——即它們存取數據的速度。這一次的數據庫架構按照垂直分割模式設計，不同的數據庫服務于站點的不同功能，如登錄、用戶資料和博客。于是，站點的擴展性問題看似又可以告一段落了，可以歇一陣子。 垂直分割策略利于多個數據庫分擔訪問壓力，當用戶要求增加新功能時，MySpace將投入新的數據庫予以支持它。賬戶到達2百萬后，MySpace還從存 儲設備與數據庫服務器直接交互的方式切換到SAN（Storage Area Network，存儲區域網絡）——用高帶寬、專門設計的網絡將大量磁盤存儲設備連接在一起，而數據庫連接到SAN。這項措施極大提升了系統性能、正常運 行時間和可靠性
里程碑三：當用戶繼續增加到3百萬后，垂直分割策略也開始難以為繼。盡管站點的各個應用被設計得高度獨立，但有些信息必須共享。在這 個架構里，每個數據庫必須有各自的用戶表副本——MySpace授權用戶的電子花名冊。這就意味著一個用戶注冊時，該條賬戶記錄必須在9個不同數據庫上分 別創建。但在個別情況下，如果其中某臺數據庫服務器臨時不可到達，對應事務就會失敗，從而造成賬戶非完全創建，最終導致此用戶的該項服務無效。另外一個問題是，個別應用如博客增長太快，那么專門為它服務的數據庫就有巨大壓力。
Scale Up和Scale Out，也稱硬件擴展和軟件擴展
分布式計算架構——它在物理上分布的眾多服務器，整體必須邏輯上等同于單臺機器。拿數據庫來說，就不能再像過去那樣將應用 拆分，再以不同數據庫分別支持，而必須將整個站點看作一個應用。現在，數據庫模型里只有一個用戶表，支持博客、個人資料和其他核心功能的數據都存儲在相同 數據庫。
這次，不再按站點功能和應用分割數據庫，MySpace開始將它的用戶按每百萬一組分割，然后將各組的全部數據分別存入獨立的SQL Server實例。目前，MySpace的每臺數據庫服務器實際運兩個SQL Server實例，也就是說每臺服務器服務大約2百萬用戶。
當然，還是有一個特殊數據庫保存了所有賬戶的名稱和密碼。用戶登錄后，保存了他們其他數據的數據庫再接管服務。特殊數據庫的用戶表雖然龐大，但它只負責用戶登錄，功能單一，所以負荷還是比較容易控制的。
里程碑四：據技術總監Whitcomb說，新代碼需要150臺服務器完成的工作，如果用ColdFusion則需要246臺。Benedetto還指出，性能上升的另一個原因可能是在變換軟件平臺，并用新語言重寫代碼的過程中，程序員復審并優化了一些功能流程。
長期解決方案是遷移到虛擬存儲體系上，這樣，整個SAN被當作一個巨型存儲池，不再要求每個磁盤為特定應用服務。MySpace目前采用了一種新型SAN設備——來自加利福尼亞州弗里蒙特的3PARdata。      在3PAR的系統里，仍能在邏輯上按容量劃分數據存儲，但它不再被綁定到特定磁盤或磁盤簇，而是散布于大量磁盤。這就使均分數據訪問負荷成為可能。當數據 庫需要寫入一組數據時，任何空閑磁盤都可以馬上完成這項工作，而不再像以前那樣阻塞在可能已經過載的磁盤陣列處。而且，因為多個磁盤都有數據副本，讀取數 據時，也不會使SAN的任何組件過載。
當2005年春天賬戶數達到1千7百萬時，MySpace又啟用了新的策略以減輕存儲系統壓力，即增加數據緩存層——位于 Web服務器和數據庫服務器之間，其唯一職能是在內存中建立被頻繁請求數據對象的副本，如此一來，不訪問數據庫也可以向Web應用供給數據。換句話 說，100個用戶請求同一份資料，以前需要查詢數據庫100次，而現在只需1次，其余都可從緩存數據中獲得。當然如果頁面變化，緩存的數據必須從內存擦 除，然后重新從數據庫獲取——但在此之前，數據庫的壓力已經大大減輕，整個站點的性能得到提升。
里程碑五：2005年中期，服務賬戶數達到2千6百萬時，MySpace切換到了還處于beta測試的SQL Server 2005。轉換何太急？主流看法是2005版支持64位處理器。但Benedetto說，“這不是主要原因，盡管這也很重要；主要還是因為我們對內存的渴 求。”支持64位的數據庫可以管理更多內存。      更多內存就意味著更高的性能和更大的容量。原來運行32位版本的SQL Server服務器，能同時使用的內存最多只有4G。切換到64位，就好像加粗了輸水管的直徑。升級到SQL Server 2005和64位Windows Server 2003后，MySpace每臺服務器配備了32G內存，后于2006年再次將配置標準提升到64G。

淘寶網，是一個在線商品數量突破一億，日均成交額超過兩億元人民幣，注冊用戶接近八千萬的大型電子商務網站，是亞洲最大的購物網站
Lighty是一個非常輕量級、占用內存資源也比較少的Web Server。雖然功能上沒有Apache強大，但是在不少場景下，性能是非常出色、強于Apache的。
Oracle是一款優秀的、廣泛采用的商業數據庫管理軟件。有很強大的功能和安全性，可以處理相對海量的數據。而MySQL是一款非常優秀的開源數據庫管 理軟件，非常適合用多臺PC Server組成多點的存儲節點陣列(這里我所指的不是MySQL自身提供的集群功能)，每單位的數據存儲成本也非常的低廉。用多臺PC Server安裝MySQL組成一個存儲節點陣列，通過MySQL自身的Replication或者應用自身的處理，可以很好的保證容錯(允許部分節點失 效)，保證應用的健壯性和可靠性。可以這么說，在關系數據庫管理系統的選擇上，可以考慮應用本身的情況來決定。

盛大起點中文網

最佳實踐 #1：按功能分割
相關的功能部分應該合在一起，不相關的功能部分應該分割開來——不管你把它叫做SOA、功能分解還是工程秘訣。而且，不相關的功能之間耦合程度越松散，就越能靈活地獨立伸縮其中的一部分。
在編碼層次，我們無時不刻都在運用這條原則。JAR文件、包、Bundle等等，都是用來隔離和抽象功能的機制。
在應用層次，eBay將不同的功能劃分成幾個應用程序池。銷售功能由一組應用服務器運行，投標功能由另一組負責，搜索又是另外一組服務器。我們把總 共約16,000臺應用服務器分成220個池。這樣就可以根據某項功能的資源消耗，單獨地伸縮其中一個池。我們也因此得以進一步隔離及合理化資源依賴關系 ——比如銷售池只需要訪問后臺資源的一個相對較小的子集。
在數據庫層次，我們也采取同樣的做法。eBay沒有無所不包的單一數據庫，相反我們有一組數據庫主機存放用戶數據、一組存放商品數據、一組存放購買數據……總共1000個邏輯數據庫分布在400臺物理主機上。同樣，這種做法讓我們得以單獨為某一類數據伸縮其數據庫設施。
最佳實踐 #2：水平切分
按功能分割對我們的幫助很大，但單憑它還不足以得到完全可伸縮的架構。即使將功能一一解耦，單項功能的資源需求隨著時間增長，仍然有可能超出單一系 統的能力。我們常常提醒自己，“沒有分割就沒有伸縮”。在單項功能內部，我們需要能把工作負載分解成許多我們有能力駕馭的小單元，讓每個單元都能維持良好 的性能價格比。這就是水平分割出場的時候了。
在應用層次，由于eBay將各種交互都設計成無狀態的，所以水平分割是輕而易舉之事。用標準的負載均衡服務器來路由進入的流量。所有應用服務器都是 均等的，而且任何服務器都不會維持事務性的狀態，因此負載均衡可以任意選擇應用服務器。如果需要更多處理能力，只需要簡單地增加新的應用服務器。
數據庫層次的問題比較有挑戰性，原因是數據天生就是有狀態的。我們會按照主要的訪問路徑對數據作水平分割（或稱為“sharding”）。例如用戶 數據目前被分割到20臺主機上，每臺主機存放1/20的用戶。隨著用戶數量的增長，以及每個用戶的數據量增長，我們會增加更多的主機，將用戶分散到更多的 機器上去。商品數據、購買數據、帳戶數據等等也都用同樣的方式處理。用例不同，我們分割數據的方案也不同：有些是對主鍵簡單取模（ID尾數為1的放到第一 臺主機，尾數為二的放到下一臺，以此類推），有些是按照ID的區間分割（1-1M、1-2M等等），有些用一個查找表，還有些是綜合以上的策略。不過具體 的分割方案如何，總的思想是支持數據分割及重分割的基礎設施在可伸縮性上遠比不支持的優越。
最佳實踐 #3：將過程轉變為異步的流
用異步的原則解耦程序，盡可能將過程變為異步的。對于要求快速響應的系統，這樣做可以從根本上減少請求者所經歷的響應延遲。對于網站或者交易系統， 犧牲數據或執行的延遲時間（完成全部工作的實踐）來換取用戶的延遲時間（用戶得到響應的時間）是值得的。活動跟蹤、單據開付、決算和報表等處理過程顯然都 應該屬于后臺活動。主要用例過程中常常有很多步驟可以進一部分解成異步運行。任何可以晚點再做的事情都應該晚點再做。
最佳實踐 #4：虛擬化所有層次
虛擬化和抽象化無所不在，計算機科學里有一句老話：所有問題都可以通過增加一個間接層次來解決。操作系統是對硬件的抽象，而許多現代語言所用的虛擬 機又是對操作系統的抽象。對象-關系映射層抽象了數據庫。負載均衡器和虛擬IP抽象了網絡終端。當我們通過分割數據和程序來提高基礎設施的可伸縮性，為各 種分割增加額外的虛擬層次就成為重中之重。
在eBay，我們虛擬化了數據庫。應用與邏輯數據庫交互，邏輯數據庫再按照配置映射到某個特定的物理機器和數據庫實例。應用也抽象于執行數據分割的 路由邏輯，路由邏輯會把特定的記錄（如用戶XYZ）分配到指定的分區。這兩類抽象都是在我們自己開發的O/R層上實現的。這樣虛擬化之后，我們的運營團隊 可以按需要在物理主機群上重新分配邏輯主機——分離、合并、移動——而完全不需要接觸應用程序代碼。
最佳實踐 #5：適當地使用緩存
最適合緩存的是很少改變、以讀為主的數據——比如元數據、配置信息和靜態數據。