Larson首先認為，一個理想的系統，對于容量（Capacity）的增長應該與添加的硬體數是線性的關系。換言之，如果系統隻有一台伺服器，在增加了另一台同樣的機器後，容量應該翻倍。以此類推。這種線性的容量伸縮方式，通常被稱之為水準伸縮“Horizontal Scalability”。
在設計一個健壯的系統時，自然必須首要考慮失敗的情況。Larson認為，一個理想的系統是當失去其中一台伺服器的時候，系統不會崩潰。當然，對應而言，失去一台伺服器也會導緻容量的響應線性減少。這種情況通常被稱為備援“Redundancy”。
無論是水準伸縮還是備援，都可以通過負載均衡來實作。負載均衡就好似一個協調請求的調停者，它會根據叢集中機器的目前負載，合理的配置設定發往Web伺服器的請求，以達到有效利用叢集中各台機器資源的目的。顯然，這種均衡器應該介于用戶端與Web伺服器之間，如下圖所示：
本文提到了實作負載均衡的幾種方法。其一是Smart Client，即将負載均衡的功能添加到資料庫（以及緩存或服務）的用戶端中。這是一種通過軟體來實作負載均衡的方式，它的缺點是方案會比較複雜，不夠健壯，也很難被重用（因為協調請求的邏輯會混雜在業務系統中）。對此，Larson在文章以排比的方式連續提出問題，以強化自己對此方案的不認可态度：
Is it attractive because it is the simplest solution? Usually, no. Is it seductive because it is the most robust? Sadly, no. Is it alluring because it’ll be easy to reuse? Tragically, no.
資料庫緩存對于應用代碼沒有污染，一些天才的DBA甚至可以在不修改任何代碼的情況下，通過資料庫調優來改進系統性能。例如通過配置Cassandra行緩存。
提高性能，降低Web伺服器負載的另一種常見做法是将靜态媒體放入CDN（Content Distribution Network）中。如下圖所示：
引入緩存所帶來的問題是如何保證真實資料與緩存資料之間的一緻性。這一問題通常被稱之為緩存失效（Cache Invalidation）。從高屋建瓴的角度來講，解決這一問題的辦法無非即使更新緩存中的資料。一種做法是直接将新值寫入緩存中（通常被稱為write-through cache）；另一種做法是簡單地删除緩存中的值，在等到下一次讀緩存值的時候再生成。
整體而言，要避免緩存實效，可以依賴于資料庫緩存，或者為緩存資料添加有效期，又或者在實作應用程式邏輯時，盡量考慮避免此問題。例如不直接使用DELETE FROM a WHERE…來删除資料，而是先查詢符合條件的資料，再使得緩存中對應的資料失效，繼而根據其主鍵顯式地删除這些行。
為了更好地提高代碼可讀性，可以在公開的接口定義中明确地标示該任務是On-Line還是Off-Line。
引入Message Queue，可以極大地緩解Web伺服器的壓力，因為它可以将耗時較長的任務轉到專門的機器上去執行。
對于大資料的處理，自然可以引入Map-Reduce。為整個系統專門引入一個Map-Reduce層來處理資料是有必要的。相對于使用SQL資料庫作為資料中心的方式，Map-Reduce對可伸縮性的支援更好。Map-Reduce可以與任務的定時機制結合起來。如下圖所示：
Larson認為，大多數系統都是Web應用直接與資料庫通信，但如果能加入一個平台層（Platform Layer），或許會更好。
首先，将平台與Web應用分離，使得它們可以獨立地進行伸縮。例如需要添加一個新的API，就可以添加新的平台伺服器，而無需增加Web伺服器。要知道，在這樣一個獨立的實體分層架構中，不同層次對伺服器的要求是不一樣的。例如，對于資料庫伺服器而言，由于需要頻繁地對磁盤進行I/O操作，是以應保證資料庫伺服器的IO性能，如盡量使用固态硬碟。而對于Web伺服器而言，則對CPU的要求比較高，盡可能采用多核CPU。
其次，增加一個額外的平台層，可以有效地提高系統的可重用性。例如我們可以将一些與系統共有特性以及橫切關注點的内容（如對緩存的支援，對資料庫的通路等功能）抽取到平台層中，作為整個系統的基礎設施（Infrastructure）。尤其對于産品線系統而言，這種架構可以更好地為多産品提供服務。
最後，這種架構也可能對跨團隊開發帶來好處。平台可以抽離出一些與産品無關的接口，進而隐藏其具體實作的細節。如果劃分合理，并能設計出相對穩定的接口，就可以使得各個團隊可以并行開發。例如可以專門成立平台團隊，緻力于對平台的實作以及優化。
Posted by 張逸 Feb 27th, 2013
<a target="_blank" href="http://agiledon.github.io/blog/categories/architecture/">Architecture</a>