2.2架構模式在新浪微博的應用
短短幾年時間新浪微博的用戶數就從零增長到數億，明星用戶的粉絲數達數千萬,圍繞著新浪微博正在發展一個集社交、媒體、游戲、電商等多位一體的生態系統。

深圳網站建設同大多數網站一樣，新浪微博也是從一個小網站發展起來的。簡單的LAMP(Linux+Apache+MySQL+PHP)架構，支撐起最初的新浪微博，應用程序用PHP開發，所有的數據，包括微博、用戶、關系都存儲在MySQL數據庫中。

這樣簡單的架構無法支撐新浪微博快速發展的業務需求，隨著訪問用戶的逐漸增加,系統不堪重負。新浪微博的架構在較短時間內幾經重構，鼓后形成現在的架構，如圖2.1所示。

系統分為三個層次，最下層是基礎服務層，提供數據庫、緩存、存儲、搜索等數據服務，以及其他一些基礎技術服務，這些服務支撐了新浪微博的海量數據和高并發訪問，是整個系統的技術基礎。

中間層是平臺服務和應用服務層，新浪微博的核心服務是微博、關系和用戶，它們是新浪微博業務大廈的支柱。這些服務被分割為獨立的服務模塊，通過依賴調用和共享基礎數據構成新浪微博的業務基礎。

最上e是API和新浪微博的業務層，各種客戶端（包括Web網站）和第三方應用，通過調用AP丨集成到新浪微博的系統中，共同組成一個生態系統。

這些被分層和分割后的業務模塊與基礎技術模塊分布式部署，每個模塊都部署在一組獨立的服務器集群匕通過遠程調用的方式進行依賴訪問。新浪微博在早期還使用過一種叫作MPSS ( MultiPort Single Server,單服務器多端口）的分布式集群部署方案，在集群中的多臺服務器h,每臺都部署多個服務，每個服務使用不同的端口對外提供服務，通過這種方式使得有限的服務器可以部署更多的服務實例，改善服務的負載均衡和可用性。現在網站應用中常見的將物理機虛擬化成多個虛擬機后，在虛擬機上部署應用的方案跟新浪微博的MPSS方案異曲同工，只是更加簡單，還能在不同虛擬機上使用相同的端口號。

在新浪微博的早期架構中.微博發布使用同步推模式，用戶發表微博后系統會立即將這條微博插入到數據庫所有粉絲的訂閱列表中，當用戶M比較大時，特別是明星用戶發布微博時，會引起大量的數據庫寫操作，超出數據庫負載，系統性能急劇下降，用戶響應延遲加劇。后來新浪微博改用異步推拉結合的模式，用戶發表微博后系統將微博寫入消息隊列后立即返回，用戶響應迅速，消息隊列消費者任務將微博推送給所有當前在線粉絲的訂閱列表中，非在線用戶登錄后再根據關注列表拉取微博訂閱列表。

由于微博頻繁刷新，新浪微博使用多級緩存策略，熱門微博和明星用戶的微博緩存在所冇的微博服務器上，在線用戶的微博和近期微博緩存在分布式緩存集群中，對于微博操作中最常見的“刷微博”操作，幾乎全部都是緩存訪問操作，可以獲得很好的系統博操作中最常見的“刷微博”操作，幾乎全部都是緩存訪問操作，可以獲得很好的系統性能。

為了提高系統的整體可用性和性能，新浪微博啟用了多個數據屮心。這些數據中心既是地區用戶訪問中心，用戶可以就近訪問最近的數據中心以加快訪問速度，改善系統性能；同時也是數據冗余復制的災備中心，所有的用戶和微博數據通過遠程消息系統在不同的數據屮心之間同步，提高系統可用性。

同時，新浪微博還開發了一系列自動化工具，包括自動化監控，自動化發布，自動化故障修復等，這些自動化工具還在持續開發中，以改善運維水平提高系統可用性。

由于微博的開放特性，新浪微博也遇到了一系列的安全挑戰，垃圾內容、偎尸粉、微博攻擊從未停止，除了使用一般網站常見的安全策略，新浪微博在開放平臺上使用多級安全審核的策略以保護系統和用戶。

2.3小結

在程序設計與架構設計領域，模式正變得越來越受人關注，許多人寄希望通過模式一勞永逸地解決自己的問題。正確使用模式可以更好地利用業界和前人的思想與實踐，用更少的時間開發出更好的系統，使設計者的水平也達到更高的境界。但是模式受其適用場景限制，對系統的要求和約束也很多，不恰當地使用模式只會畫虎不成反類犬，不但沒有解決原來的老問題，反而帶來了更棘手的新問題。

好的設計絕對不是模仿，不是生搬硬套某個模式，而是對問題深刻理解之上的創造與創新，即使是“微創新”，也是讓人耳—新的似曾相識。山寨與創新的最大區別不在于是否抄襲，是否模仿，而在于對問題和需求是否真正理解與把握。