大型網站架構

網站架構包括：前端架構+應用層架構+服務層架構+存儲層架構+后臺架構+數據中心機房架構+安全架構+數據采集與監控。

前端架構

• 瀏覽器優化技術
  并不是優化瀏覽器，而是通過優化響應頁面，加快瀏覽器頁面的加載和顯示，常用的有頁面緩存、合并HTTP 減少請求次數、使用頁面壓縮等。
• CDN
  內容分發網絡，部署在網絡運營商機房，通過將靜態頁面內容分發到離用戶最近的CDN 服務器，使用戶可以通過最短路徑獲取內容。
• 動靜分離，靜態資源獨立部署
  靜態資源，如JS,CSS 等文件部署在專門的服務器集群上，和Web 應用動態內容服務分離，并使用專門的（二級）域名。
• 圖片服務
  圖片不是指網站Logo 按鈕圖標等，這些文件屬于上面提到的靜態資源，應該和JS CSS 部署在一起。這里的圖片指用戶上傳的圖片，如產品圖片、用戶頭像等，圖片服務同樣使用獨立部署的圖片服務器集群，并使用獨立（二級）域名。
• 反向代理
  部署在網站機房，在應用服務器、靜態資源服務器、圖片服務器之前，提供頁面緩存服務。
• DNS
  域名服務，將域名解析成IP 地址，利用DNS 可以實現DNS 負載均衡，配置CDN也需要修改DNS使域名解析后指向CDN 服務器。

應用層架構

應用層是處理網站主要業務邏輯的地方。

• 開發框架
• 頁面渲染
  將分別開發維護的動態內容和靜態頁面模板集成起來，組合成最終顯示給用戶的完整頁面。
• 負載均衡
  將多臺應用服務器組成一個集群，通過負載均衡技術將用戶請求分發到不同的服務器上，以應對大量用戶同時訪問時產生的高并發負載壓力。
• Session 管理
  為了實現高可用的應用服務器集群，應用服務器通常設計為無狀態，不保存用戶請求上下文信息，但是網站業務通常需要保持用戶會話信息，需要專門的.機制管理Session
  使集群內甚至跨集群的應用服務器可以共享Session
• 動態頁面靜態化
  對于訪問量特別大而更新又不很頻繁的動態頁面，可以將其靜態化，即生成一個靜態頁面，利用靜態頁面的優化手段加速用戶訪問，如反向代理、CDN、 瀏覽器緩存等。
• 業務拆分
  將復雜而又龐大的業務拆分開來，形成多個規模較小的產品，獨立開發、部署、維護，除了降低系統耦合度，也便于數據庫業務分庫。按業務對關系數據庫進行拆分，技術難度相對較小，而效果又相對較好。
• 虛擬化服務器
  將一臺物理服務器虛擬化成多臺虛擬服務器，對于并發訪問較低的業務，更容易用較少的資源構建高可用的應用服務器集群。

服務層架構

提供基礎服務，供應用層調用，完成網站業務。

• 分布式消息
  利用消息隊列機制，實現業務和業務、業務和服務之間的異步消息發送及低耦合的業務關系。
• 分布式服務
  提供高性能、低耦合、易復用、易管理的分布式服務，在網站實現面向服務架構SOA
• 分布式緩存
  通過可伸縮的服務器集群提供大規模熱點數據的緩存服務，是網站性能優化的重要手段。
• 分布式配置
  系統運行需要配置許多參數，如果這些參數需要修改，比如分布式緩存集群加入新的緩存服務器，需要修改應用程序客戶端的緩存服務器列表配置，并重啟應用程序服務器。分布式配置在系統運行期提供配置動態推送服務，將配置修改實時推送到應用系統,無需重啟服務器。

存儲層架構

• 分布式文件
  網站在線業務需要存儲的文件大部分都是圖片、網頁、視頻等比較小的文件，但是這些文件的數量非常龐大，而且通常都在持續增加，需要伸縮性設計比較好的分布式文件系統。

• 關系數據庫
  大部分網站的主要業務是基于關系數據庫開發的，但是關系數據庫對集群伸縮性的支持比較差。通過在應用程序的數據訪問層增加數據庫訪問路由功能，根據業務配置將數據庫訪問路由到不同的物理數據庫上，可實現關系數據庫的分布式訪問

• NoSQL 數據庫
  目前各種NoSQL 數據庫層出不窮，在內存管理、數據模型、集群分布式管理等方面各有優勢，不過從社區活躍性角度看，HBase 無疑是目前最好的。

• 數據同步
  在支持全球范圍內數據共享的分布式數據庫技術成熟之前，擁有多個數據中心的網站必須在多個數據中心之間進行數據同步，以保證每個數據中心都擁有完整的數據。在實踐中，為了減輕數據庫壓力，將數據庫的事務日志（或者NoSQL 的寫操作Log) 同步到其他數據中心，根據Log 進行數據重演，實現數據同步。

后臺架構

網站應用中，除了要處理用戶的實時訪問請求外，還有一些后臺非實時數據分析要處理。

• 搜索引擎
  即使是網站內部的搜索引擎，也需要進行數據增量更新及全量更新、構建索引等。
  這些操作通過后臺系統定時執行。
• 數據倉庫
  根據離線數據，提供數據分析與數據挖掘服務。
• 推薦系統
  社交網站及購物網站通過挖掘人和人之間的關系，人和商品之間的關系，發掘潛在的人際關系和購物興趣，為用戶提供個性化推薦服務。

數據采集與監控

監控網站訪問情況與系統運行情況，為網站運營決策和運維管理提供支持保障。

• 瀏覽器數據采集
  通過在網站頁面中嵌入JS 腳本釆集用戶瀏覽器環境與操作記錄，分析用戶行為。
• 服務器業務數據采集
  服務器業務數據包括兩種，一種是采集在服務器端記錄的用戶請求操作日志；一種是釆集應用程序運行期業務數據，比如待處理消息數目等。
• 服務器性能數據采集
  采集服務器性能數據，如系統負載、內存使用率、網卡流量等。
• 系統監控
  將前述采集的數據以圖表的方式展示，以便運營和運維人員監控網站運行狀況，做
  到這一步僅僅是系統監視。更先進的做法是根據釆集的數據進行自動化運維，自動處理
  系統異常狀況，實現自動化控制。
• 系統報警
  如果采集來的數據超過預設的正常情況的閾值，比如系統負載過高，就通過郵件、
  短信、語音電話等方式發出報警信號，等待工程師干預。

安全架構

保護網站免遭攻擊及敏感信息泄露。

• Web 攻擊
  以HTTP 請求的方式發起的攻擊，危害最大的就是XSS 和SQL 注入攻擊。但是只要
  措施得當，這兩種攻擊都是比較容易防范的。
• 數據保護
  敏感信息加密傳輸與存儲，保護網站和用戶資產。

數據中心機房架構

山寨與創新的最大區別不在于是否抄襲、是否模仿，而在于對問題和需求是否真正理解與把握

在解決問題之前，能夠認真思考自己面對的真正問題究竟是什么，有哪些技術方案可以選擇，其基本原理是什么。

網站架構其實并不難，真正能解決問題的技術一定是簡單的。

大型網站的特點：
高并發、大流量；高可用；海量數據；用戶分布廣泛且網絡環境復雜；安全環境惡劣；需求快速變更，發布頻繁；漸進式發展。

網站系統的演進：

1. 單機部署
2. 數據和應用分離
3. 使用緩存減少數據庫壓力
   網站訪問特點和現實世界的財富分配一樣遵循二八定律：80%的業務訪問集中在20%
   的數據上
4. 應用服務器集群化
   可擴展性，負載均衡
5. 數據庫讀寫分離
   利用的是數據庫的主從熱備。寫主讀從。
6. 加速網站訪問速度：CDN和反向代理。
   CDN 和反向代理的基本原理都是緩存，區別在于CDN 部署在網絡提供商的機房，使
   用戶在請求網站服務時，可以從距離自己最近的網絡提供商機房獲取數據；而反向代理
   則部署在網站的中心機房，當用戶請求到達中心機房后，首先訪問的服務器是反向代理
   服務器，如果反向代理服務器中緩存著用戶請求的資源，就將其直接返回給用戶。
7. 分布式數據庫和分布式文件系統
   網站更常用的數據庫拆分手段是業務分庫，將不同業務的數據
   庫部署在不同的物理服務器上。
8. 使用NoSQL和搜索引擎
9. 業務拆分
10. 分布式服務

但事物發展到一定階段，就會擁有自身的發展沖動，擺脫其初衷，向著使自己更強
大的方向發展。既然大型網站架構解決了海量數據的管理和高并發事務的處理，那么就
可以把這些解決方案應用到網站自身以外的業務上去。我們看到目前許多大型網站都開
始建設云計算平臺，將計算作為一種基礎資源出售，中小網站不需要再關心技術架構問
題，只需要按需付費，就可以使網站隨著業務的增長逐漸獲得更大的存儲空間和更多的
計算資源。

這個世界沒有哪個網站從誕生起就是大型網站；也沒有哪個網站第一次發布就擁有
龐大的用戶，高并發的訪問，海量的數據；大型網站都是從小型網站發展而來。網站的
價值在于它能為用戶提供什么價值，在于網站能做什么，而不在于它是怎么做的，所以
在網站還很小的時候就去追求網站的架構是舍本逐末，得不償失的。小型網站最需要做
的就是為用戶提供好的服務來創造價值，得到用戶的認可，活下去，野蠻生長。

技術是用來解決業務問題的，而業務的問題，也可以通過業務的手段去解決。
恩，不要妄圖用技術解決所有問題。

大型網站架構模式

1. 分層
   單一職責，上層對下層的依賴關系。
2. 分割
   業務縱向分割，分布式部署。
3. 分布式
   分層和分割都是為了便于分布式部署。
   常用的分布式方案有：分布式應用和服務；分布式靜態資源；分布式數據和存儲；分布式計算。
4. 集群
5. 緩存
   緩存是改善軟件性能的第一手段。
   使用緩存有兩個前提條件，一是數據訪問熱點不均衡，某些數據會被更頻繁的訪問，
   這些數據應該放在緩存中；二是數據在某個時間段內有效，不會很快過期，否則緩存的
   數據就會因已經失效而產生臟讀，影響結果的正確性。
6. 異步
   將一個業務操作分成多個階段，每個階段之間通過共享數據的方式異步執行進行協作。
   在分布式系統中，多個服務器集群通過分布式消息隊列實現異步，分布式消息隊列可以看作內存隊列的分布式部署。
   提高系統可用性。
   加快網站響應速度。
   消除并發訪問高峰。
7. 冗余

架構要素

從性能、可用性、伸縮性、擴展性、安全這五個要素。
所謂伸縮性是指通過不斷向集群中加入服務器的手段來緩解不斷上升的
用戶并發訪問壓力和不斷增長的數據存儲需求。
衡量架構伸縮性的主要標準就是是否可以用多臺服務器構建集群，是否容易向集群
中添加新的服務器。加入新的服務器后是否可以提供和原來的服務器無差別的服務。集
群中可容納的總的服務器數量是否有限制。

關系數據庫雖然支持數據復制，主從熱備等機制，但是很難做到大規模集群的可伸
縮性，因此關系數據庫的集群伸縮性方案必須在數據庫之外實現，通過路由分區等手段
將部署有多個數據庫的服務器組成一個集群
至于大部分NoSQL 數據庫產品，由于其先天就是為海量數據而生，因此其對伸縮性
的支持通常都非常好，可以做到在較少運維參與的情況下實現集群規模的線性伸縮。

擴展性是指的功能擴展，伸縮是指性能伸縮。

性能優化

System Load 即系統負載，指當前正在被CPU 執行和等待被CPU 執行的進程數目總和，是反映系統忙閑程度的重要指標。多核CPU 的情況下，完美情況是所有CPU 都在使用，沒有進程在等待處理，所以Load 的理想值是CPU 的數目。當Load 值低于CPU 數目的時候，表示CPU 有空閑，資源存在浪費；當Load 值高于CPU 數目的時候，表示進程在排隊等待CPU 調度，表示系統資源不足，影響應用程序的執行性能。
在Linux 系統中使用top 命令査看，該值是三個浮點數，表示最近1 分鐘，10 分鐘，15 分鐘的運行隊列平均進程數。

性能測試是一個總稱，具體可細分為性能測試、負載測試、壓力測試、穩定性測試。

排査一個網站的性能瓶頸和排査一個程序的性能瓶頸的手法基本相同：檢査請求處
理的各個環節的日志，分析哪個環節響應時間不合理、超過預期；然后檢査監控數據，
分析影響性能的主要因素是內存、磁盤、網絡、還是cpu? 是代碼問題還是架構設計不
合理，或者系統資源確實不足。

前端性能優化

主要優化手段有優化瀏覽器訪問、使用反向代理、CDN 等。
優化瀏覽器訪問的措施：

1. 減少http請求。
   HTTP 協議是無狀態的應用層協議，意味著每次HTTP 請求都需要建立通信鏈路、進行數據傳輸，而在服務器端，每個HTTP 都需要啟動獨立的線程去處理。這些通信和服務的開銷都很昂貴，減少HTTP 請求的數目可有效提高訪問性能。
   減少HTTP 的主要手段是合并CSS,合并JavaScript,合并圖片。將瀏覽器一次訪問需要的JavaScript CSS 合并成一個文件，這樣瀏覽器就只需要一次請求。圖片也可以合并，多張圖片合并成一張，如果每張圖片都有不同的超鏈接，可通過CSS 偏移響應鼠標點擊操作，構造不同的URL
2. 使用瀏覽器緩存
   對一個網站而言，CSS? JavaScript , Logo圖標這些靜態資源文件更新的頻率都比較低，而這些文件又幾乎是每次HTTP 請求都需要的，如果將這些文件緩存在瀏覽器中，可以極好地改善性能。
   通過設置HTTP 頭中Cache-Control 和Expires 的屬性，可設定瀏覽
   器緩存，緩存時間可以是數天，甚至是幾個月。
   在某些時候，靜態資源文件變化需要及時應用到客戶端瀏覽器，這種情況，可通改變文件名實現，即更新JavaScript 文件并不是更新JavaScript 文件內容，而是生成一個新的JS 文件并更新HTML 文件中的引用。
   使用瀏覽器緩存策略的網站在更新靜態資源時，應采用批量更新的方法，比如需要更新10 個圖標文件，不宜把10 個文件一次全部更新，而是應一個文件一個文件逐步更
   新，并有一定的間隔時間，以免用戶瀏覽器突然大量緩存失效，集中更新緩存，造成服
   務器負載驟增、網絡堵塞的情況。
3. 啟用壓縮
   在服務器端對文件進行壓縮，在瀏覽器端對文件解壓縮，可有效減少通信傳輸的數
   據量。文本文件的壓縮效率可達80%以上，因此HTML? CSS? JavaScript 文件啟用GZip
   壓縮可達到較好的效果。但是壓縮對服務器和瀏覽器產生一定的壓力，在通信帶寬良好，
   而服務器資源不足的情況下要權衡考慮。
4. CSS 放在頁面最上面、JavaScript 放在頁面最下面
   但如果頁面解析時就需要用到JavaScript, 這時放在底部就不合適了。

5，減少cookie傳輸

服務器端性能優化

1. 分布式緩存
   網站性能優化第一定律：優先考慮使用緩存優化性能。
   產品在設計之初就需要一個明確的定位：什么是產品要實現的功能，什么
   不是產品提供的特性。在產品漫長的生命周期中，會有形形色色的困難和誘惑
   來改變產品的發展方向，左右搖擺、什么都想做的產品，最后有可能成為一個
   失去生命力的四不像。
   緩存預熱
   緩存穿透
2. 異步
   消息隊列。需要注意的是，由于數據寫入消息隊列后立即返回給用戶，數據在后續的業務校驗、寫數據庫等操作可能失敗，因此在使用消息隊列進行業務異步處理后，需要適當修改業
   務流程進行配合
   任何可以晚點做的事情都應該晚點做。
3. 使用集群。
4. 代碼優化
   • 多線程。
     啟動線程數= [任務執行時間/ (任務執行時間-10 等待時間）] xCPU 內核數
     最佳啟動線程數和CPU 內核數量成正比，和IO 阻塞時間成反比。
     如果是計算型任務，那么線程數最多不超過CPU 內核數，因為啟動再多線程，CPU 也來不及調度；相反如果是任務需要等待磁盤操作，網絡響應，那么多啟動線程有助于提高任務并
     發度，提高系統吞吐能力，改善系統性能。
   • 對象復用。單例和池技術。
   • 數據結果。
   • 垃圾回收。

存儲性能優化

B+樹，關系型數據庫多采用此數據結構。
NoSql產品多采用LSM樹作為主要數據結構。
在LSM 樹上進行一次數據更新不需要磁盤訪問，在內存即可完成，速度遠快于B+
樹。當數據訪問以寫操作為主，而讀操作則集中在最近寫入的數據上時，使用LSM樹可以極大程度地減少磁盤的訪問次數，加快訪問速度。

RAID，通過使用RAID 技術，實現數據在多塊磁盤上的并發讀寫和數據備份。
RAID 技術在傳統關系數據庫及文件系統中應用比較廣泛，但是在大型網站比
較喜歡使用的NoSQL? 以及分布式文件系統中，RAID 技術卻遭到冷落。

高可用性優化

4個9也就是一年中大約最多53 分鐘不可用。

主要手段是數據和服務的冗余備份及失效轉移。

分級管理，部署隔離。
超時設置。
異步調用。
服務降級。
冪等性設計。

CAP 原理認為，一個提供數據服務的存儲系統無法同時滿足數據一致性
(Consistency)、數據可用性（Availibility )、分區耐受性即可擴展性（Patition Tolerance? 系統具有跨網絡分區的伸縮性）這三個條件。
通常我們必須去保證A可用性和P擴展性，某種程度上放棄C一致性。

數據最終一致性，這是數據一致性中較弱的一種，數據可能不一致，但經過一段時間的自我恢復和修正，數據達到最終一致。

數據備份，冷備和熱備。熱備又分同步熱備和異步熱備。

失效轉移操作由三部分組成：失效確認、訪問轉移、數據恢復。

伸縮性優化

實現負載均衡的基礎技術：

• HTTP 重定向
  這種負載均衡方案的優點是比較簡單。缺點是瀏覽器需要兩次請求服務器才能完成
  一次訪問，性能較差；重定向服務器自身的處理能力有可能成為瓶頸，整個集群的伸縮
  性規模有限；使用HTTP302 響應碼重定向，有可能使搜索引擎判斷為SEO 作弊，降低搜
  索排名。因此實踐中使用這種方案進行負載均衡的案例并不多見。
• DNS 域名解析負載均衡
  事實上，大型網站總是部分使用DNS 域名解析，利用域名解析作為第一級負載均衡
  手段，即域名解析得到的一組服務器并不是實際提供Web 服務的物理服務器，而是同樣
  提供負載均衡服務的內部服務器，這組內部負載均衡服務器再進行負載均衡，將請求分
  發到真實的Web 服務器上。
• 反向代理負載均衡
• IP 負載均衡
• 數據鏈路層負載均衡
  這種數據傳輸方式又稱作三角傳輸模式，負載均衡數據分發過程中不修改IP 地址，
  只修改目的mac 地址，通過配置真實物理服務器集群所有機器虛擬IP 和負載均衡服務器
  IP 地址一致，從而達到不修改數據包的源地址和目的地址就可以進行數據分發的目的
  是目前大型網站使用最廣的一種負載均衡手段。在Linux 平臺上最好的鏈路層負載均衡開源產品是LVS ( Linux Virtual Server )。

分布式緩存
一致性哈希
計算機領域有句話：計算機的任何問題都可以通過增加一個虛擬層來解決。
。那么在實踐中，一臺物理服務器虛擬為多少個虛擬服務器節點合適呢？太多會影響
性能，太少又會導致負載不均衡，一般說來，經驗值是150，當然根據集群規模和負載均
衡的精度需求，這個值應該根據具體情況具體對待。

關系型數據庫
使用開源中間件，如Cobar。原理是在數據庫之上又加了一層。是一個分布式數據庫的訪問代理。
當前分布式數據庫無法解決的問題是，無法跨庫Join，更無法實現跨庫事務。
所以需要從業務上避免分布式數據庫的缺點：避免事務或者利用事務補償機制代替數據庫事務。分解數據訪問邏輯避免Join操作。

還有一類分布式數據庫可以支持JOIN 操作執行復雜
的SQL 査詢，如GreenPlum? 但是這類數據庫的訪問延遲比較大（可以想象，JOIN 操作
需要在服務器間傳輸大量的數據）， 因此一般使用在數據倉庫等非實時業務中。

NoSql
NoSQL數據庫產品都放棄了關系數據庫的兩大重要基礎：以關系代數為基礎的結構化査詢語言
( SQL ) 和事務一致性保證（ACID )。而強化其他一些大型網站更關注的特性：高可用性
和可伸縮性。

可擴展性架構

設計網站可擴展架構的核心思想是模塊化，并在此基礎之上，降低模塊間的耦合性，
提高模塊的復用性。

• 利用分布式消息隊列降低系統耦合性
• 利用分布式服務框架，如Dubbo
• 搭建開放平臺建設網站生態圈
  API接口，協議轉換，安全，審計，路由，流程

安全架構

常見攻擊

XSS，跨站點腳本攻擊。惡意腳本執行。
防御：消毒（特殊字符轉義）
httponly，防止XSS 攻擊者竊取Cookie。

注入攻擊，消毒，預編譯

CSRF，跨站點請求偽造。其核心是利用了瀏覽器Cookie 或服務器Session 策略，盜取用戶身份。
防御：表單Token，驗證碼，referer check（請求來源檢查）

web應用防火墻

ModSecurity

加密

• 單項散列加密
  常用的單向散列算法有MD5? SHA 等。單向散列算法還有一個特點就是輸入的任何
  微小變化都會導致輸出的完全不同，這個特性有時也會被用來生成信息摘要、計算具有
  高離散程度的隨機數等用途。
• 對稱加密
  常用的對稱加密算法有DES 算發、RC 算法等
• 非對稱加密
  非對稱加密的常用算法有RSA 算法

信息過濾

• 文本匹配
  正則表達式的效率一般較差，僅適用于短文本及低并發場景。
  高并發時使用的公幵的算法有很多，基本上都是Trie 樹的變種，空間和時間復雜度都比較好
  的有雙數組Trie 算法等。

秒殺系統架構

網站如果為秒殺時的最高并發訪問量進行設計部署，就需要比正常運營多得多的服務器，而這些服務器在絕大部分時候都是用不著的，浪費驚人。所以網站的秒殺業務不能使用正常的網站業務流程，也不能和正常的網站交易業務共用服務器，必須設計部署專門的秒殺系統，進行專門應對。

技術挑戰

1. 對現有網站業務沖擊。
   如果部署在一起，稍有不慎全業務癱瘓。
2. 高并發下的應用、數據庫負載。
3. 突然增加的網絡及服務器帶寬
4. 直接下單
   下單頁面也是一個普通的URL, 如果得到這個URL， 不用等到秒殺開始就可以下單了。

應對策略

1. 獨立部署
   2，秒殺產品頁面靜態化
   使其不需要經過web服務器和數據庫服務器。
   3，租借秒殺活動帶寬
2. 動態生成隨機下單頁面URL
   為了避免用戶直接訪問下單頁面URL. 需要將該URL 動態化，即使秒殺系統的開發
   者也無法在秒殺開始前訪問下單頁面的URL. 辦法是在下單頁面URL 加入由服務器端生
   成的隨機數作為參數，在秒殺開始的時候才能得到。

架構設計

1. 如何控制秒殺按鈕的點亮
   解決辦法是使用JavaScript 腳本控制，在秒殺商品靜態頁面中加入一個JavaScript 文
   件引用，該JavaScript 文件中加入秒殺是否開始的標志和下單頁面URL 的隨機數參數，
   當秒殺開始的時候生成一個新的JavaScript 文件并被用戶瀏覽器加載，控制秒殺商品頁面
   的展示。這個javaScript 文件使用隨機版本號，并且不被瀏覽器、CDN 和反向代理服務
   器緩存。
   2，只允許用戶的第一個下單請求到達服務器
   并且服務器接收到的單量超過設定值后，其他的請求直接秒殺結束。
   如果服務器出錯，直接秒殺結束頁面。

經驗教訓

寫日志導致磁盤滿

• 控制業務日志級別warn
• 某些第三方包也會打太多錯誤日志，要關閉
• 自己的業務日志和第三方的日志要分開配置

數據庫load高

原因：首頁訪問了數據庫

• 首頁訪問頻繁，不要直接訪問數據庫
• 首頁最好應該做出靜態的

高并發下鎖超時

• 減小粒度
• 謹慎使用

緩存

緩存服務器宕機，數據庫壓力陡增引發宕機。

• 緩存服務器也很重要，大家普遍不夠重視

應用啟動不同步引發故障

原因：應用程序Web 環境使用Apache+JBoss 的模式，用戶請求通過Apache 轉
發JBoss? 在發布時，Apache 和JBoss 同時啟動，由于JBoss 啟動時需要加載很多應用并
初始化，花費時間較長，結果JBoss 還沒有完全啟動，Apache 就已經啟動完畢開始接收
用戶請求，大量請求阻塞在JBoss 進程中，最終導致JBoss 崩潰。除了這種Apache 和JBoss
啟動不同步的情況，網站還有很多類似的場景，都需要后臺服務準備好，前臺應用才能
啟動，否則就會導致故障。

大文件讀寫獨占磁盤

有幾個文件非常大，有數百兆，讀寫這些大文件一
次需要幾十秒，這段時間，磁盤基本被這個文件操作獨占，導致其他用戶的文件操作緩慢。

• 大文件和小文件區分存儲，區別對待。

架構師

架構師作為項目組最資深的專業技術人員，是項目組開發測試工程師的前輩。從架
構師的身上，工程師可以看到自己的未來，因此架構師在做人做事方面需要嚴格要求自
己，做好表率。

關注人而不是產品

一定要堅信：一群優秀的人做一件他們熱愛的事，一定能取得成功。不管過程多么
曲折，不管外人看來多么不可思議不靠譜。
領導的真諦：尋找一個值得共同奮斗的目標，營造一個讓大家都能最大限度
發揮自我價值的工作氛圍。
沒有懶惰的員工，只有沒被激發出來的激情。所有強迫員工加班的管理者都應該為
自己的無能而羞愧。

發覺人的優秀

是事情成就了人，而不是人成就了事。指望優秀的人來幫自己成事，不如做成一件
事讓自己和參與的人都變得優秀。

共享美好藍圖

架構師要和項目組全體成員共同描繪一個藍圖，這個藍圖是整個團隊能夠認同的，
是團隊共同奮斗的目標。
藍圖應該是表述清楚的：產品要做什么、不做什么、要達到什么業務目標，都需要
描述清楚。
藍圖應該是形象的：產品能為用戶創造什么價值、能實現什么樣的市場目標、產品
最終會長什么樣，都需要形象地想象出來。
藍圖應該是簡單的：不管內部還是外部溝通，都能一句話說明白：我們在做什么。
藍圖應該寫在軟件架構設計文檔的扉頁、寫在郵件的簽名檔、寫在內部即時通信群
的公告上。
在項目過程中，架構師要保持對目標藍圖的關注，對任何偏離藍圖的設計和決定保持警惕，錯誤的偏離要及時修正，必要的變更要經過大家討論，并且需要重新獲得大家
的認同。

共同參與架構

架構師需要對系統架構負責，但并不是說一定要架構師自己完成架構設計，并要項
目團隊嚴格遵守架構決策。
把架構和架構師凌駕于項目和項目組之上，只會讓架構師變成孤家寡人，讓架構曲
局和寡。

1. 不要只有架構師一個人擁有架構
2. 讓其他人維護框架與架構文檔

學會妥協

不要企圖在項目中證明自己是正確的，一定要記住，你是來做軟件的，不是來當老
大的。所以不要企圖去證明自己了不起，永遠也別干這種浪費時間、傷害感情的事

很多時候，對架構和技術方案的反對意見，其實意味著架構和技術方案被關注、被
試圖理解和接受。架構師不應該對意見過于敏感，這時架構師應該做的是坦率地分享自
己的設計思路，讓別人理解自己的想法并努力理解別人的想法，求同存異。
對于技術細節的爭論應該立即驗證而不是繼續討論，當討論深入到技術細節的時候
也意味著問題已經收斂，對于整體架構設計，各方意見正趨于一致。
而當大家不再討論架構的時候，表明架構已經融入到項目、系統和開發者中了，架
構師越早被項目組遺忘，越表示架構非常成功；項目組越離不開架構師，越表示架構還
有很多缺陷。

成就他人

架構師作為團隊的技術領導者，在項目過程中不要去試圖控制什么，帶著一個彈性
的計劃和藍圖推進，團隊會管好他們自己。你越是強加禁令，隊伍就越是沒有紀律；你
越是強制，團隊就越是不能獨立自主；你越是從外面尋找幫助，大家就越是沒有信心。

發現問題，尋找突破

其實即使是在一流的技術團隊里，也一定有數不清的問題，只是人們習慣了這些問
題，以至于無視它們的存在。正所謂“魚是最后一個看見水的”，天天面對這些問題，反
而不覺得有什么問題。

提出問題，尋求支持

問題被發現，它只是問題發現者的問題，而不是問題擁有者的問題，如果想要解決一個問題，就必須提出這個問題，讓問題的擁有者知道問題的存在。 　　
找對關鍵人

• 把“我的問題”表述成“我們的問題”
• 給上司提封閉式問題，給下屬提開放式問題
  不要問上司“你覺得該怎么辦？”這種沒有建設性的開放式問題，給上司
  提問題是希望能夠得到他的支持，而不是帶著一頭霧水等他去指點迷津。公司
  付你薪水不是讓你睜著迷茫的眼睛賣萌。給上司提問應該是“你覺得A 和B 兩
  個方案哪個更好？”這種封閉式問題。
• 指出問題而不是批評人
  如果在合作中出現問題，告訴他問題的存在和緊迫性，而不是責問他為什
  么出現問題。
• 用贊同的方式提出問題
  所謂直言有諱是指想要表達的意圖要直截了當說明白，不要兜圈子，但是
  在表達方式上要有所避諱，照顧到當事人的感受。

解決問題，達成績效

1. 在解決我的問題之前，先解決你的問題
   先解決別人的問題有幾個好處：
   你幫別人解決了問題，禮尚往來，別人也會幫你解決問題。
   在幫別人解決問題的過程中，熟悉了情況，后面解決自己的問題也就得
   心應手了。
   解決別人的問題時使用的是你的解決方案，這個方案在你的控制之中，
   將來往這個方案里再塞一些東西解決自己的問題，手到擒來。

2. 適當的逃避問題