創業公司工程師應該掌握的可伸縮Web開發技術

近些年來，越來越多的行業開始和互聯網結合，誕生了越來越多的互聯網創業公司。互聯網創業公司需要面對許多的不確定因素。如果你和你的小伙伴們夠 幸運，你們的公司可能會在幾個星期之內讓用戶數、商品數、訂單量增長幾十倍上百倍。一次促銷可能會帶來平時幾十倍的訪問流量，一次秒殺活動可能會吸引平時 數百倍的訪問用戶。這對公司自然是極大的好事，說明產品得到認可，公司未來前景美妙。

但是快速增長的用戶和訂單卻對公司的技術提出極大的挑戰。受計算資源本身的限制，一臺服務器能啟動的線程數、能存儲的數據，每秒鐘能完成的計算、 能讀寫的數據、能傳輸的數據都是有限的。而系統處理每一個用戶請求都需要消耗一定的計算資源，當大量的用戶同時來訪問系統的時候，會出現因計算資源不足而 導致的響應延遲以及超時出錯，當并發訪問用戶超過某個極限，甚至會導致服務器宕機，整個網站不可訪問的慘劇。

當公司正在為用戶增加訂單量上升而慶祝的時候，卻傳來系統崩潰網站不可訪問的噩耗。喜劇變成悲劇，慶祝會變成批斗會，作為負責公司技術的工程師，作為批斗會的主角，你，是否會覺得壓力山大。

本文面向創業公司的工程師，介紹可伸縮的Web開發技術。伸縮性是指系統可以根據需求和成本調整自身處理能力的一種特性。伸縮性意味著系統可以改變自身的處理能力以滿足更多用戶訪問處理更多數據而不會對用戶體驗造成任何影響。

一、構建可伸縮的Web架構

互聯網創業的一個特點是開始的時候規模都很小，幾個人的小團隊，少量的啟動資金，就開始創業了。Google是從斯坦福的實驗室開始創業 的，非死book是從哈佛的宿舍里開始創業的，Alibaba是從馬云家的客廳開始創業的。剛開始的時候，用戶也少，所以只要一臺服務器就可以應付所 有的用戶訪問，這時整個Web系統架構如圖1。數據庫、Web應用、文件服務都部署在一臺服務器上。

圖1 互聯網創業早期最簡單的Web系統架構

如果創業方向正確，產品解決用戶痛點，能為社會創造價值，就會有更多用戶來訪問網站。這時，Web系統受計算資源不足影響，會出現響應延遲，打不 開網站等情況。解決方法有兩種，一種方法是使用更強大計算能力的計算機，另一種方法是使用更多的計算機。第一種方法主要問題在于再強大的計算機也都有資源 限制，而一個成功的網站的終極目標是服務全世界，隨著網站的發展，不管多強大的計算機遲早也會遇到計算資源不足的問題；而且越強大的計算機其價格也越昂 貴，這也是剛剛起步的創業公司不能承受的。所以幾乎所有的互聯網公司都選擇了第二種方法，即構建一個彈性可伸縮的Web系統，通過逐步向系統中增加服務器 從而提高整個系統的計算處理能力。

增加服務器的一個基本手段是將不同的服務部署在不同的服務器上，應用服務器，數據庫服務器，文件服務器獨立部署，如圖2。

圖2 進行簡單拆分獨立部署的Web系統架構

此外，還可以將不同的模塊拆分到不同的服務器。比如一個電子商務網站，商城、論壇、賣家這些相對獨立的模塊可以獨立部署，即使在商城系統內部，首頁、商品列表、商品詳情、訂單等子模塊也可以進一步獨立部署，如圖3。

圖3 按功能模塊進一步拆分獨立部署的Web系統架構

事實上隨著業務不斷發展，網站需要使用更多的服務，緩存、消息隊列、搜索、NoSQL、反向代理等，還需要將靜態內容服務從應用服務器中分離出 來，以及使用CDN（內容分發網絡）進行靜態內容訪問加速。這些服務都應該部署在獨立的服務器上，通過使用更多的服務器提高網站的整體處理能力。

這些可以分拆的功能和服務雖然已經獨立部署，但是每個功能或者服務如果只能部署在一臺服務器上，能夠提供的計算能力以及能夠處理的并發訪問依然有限。解決方法是通過集群的方式將單一服務部署在多臺服務器上，從而提供更強大的處理能力，如圖4。

圖4 集群部署的Web系統架構

總之，可伸縮網站架構的核心思路就是通過分拆集群等手段向Web系統中添加各種服務器，為系統提供更多計算、存儲、傳輸能力，這些服務器能有效分擔系統訪問壓力，使Web系統能夠支撐更多用戶訪問、存儲更多數據而不至于影響用戶體驗。

二、使用可伸縮的基礎技術產品

前面提到，單一服務或者應用需要通過集群的方式提供更強大的計算處理能力。集群即多臺服務器部署相同應用或服務構成一個服務器群統一對外提供服 務。如果有更多用戶訪問，需要處理更多并發訪問請求的時候，只需要向集群中添加新的服務器即可。這就要求服務或應用本身具有可伸縮性。

1. 通過負載均衡實現應用服務器可伸縮

應用服務器一般指部署核心業務邏輯，主要處理用戶請求的服務器。應用通常設計成無狀態結構，即應用本身不記錄用戶請求的上下文信息，這樣設計的好 處是任何用戶的任何一次請求都可以交給任何一個應用服務器去處理。實踐中，一般通過負載均衡服務器將一組應用服務器構建成一個集群，如圖5。

圖5 通過負載均衡實現應用服務器可伸縮（圖片來源《大型網站技術架構：核心原理與案例分析》）

首先在負載均衡服務器上配置所有的應用服務器信息，用戶請求先到達負載均衡服務器，負載均衡服務器通過某種負載均衡算法計算得到一個應用服務器的 網絡地址，然后將請求數據包轉發給這個應用服務器，由該服務器完成用戶請求處理。如果用戶數增加，并發請求超過現有集群的處理能力，只需要在現有應用服務 器集群中增加服務器，在負載均衡服務器上增加新的服務器配置信息，部分用戶請求就會轉發到新增服務器上，實現分擔集群訪問壓力的目的。

負載均衡服務器的實現有很多種，DNS負載均衡、HTTP重定向負載均衡，HTTP轉發負載均衡、IP層負載均衡、數據鏈路層負載均衡等，實踐 中，中小網站多使用Nginx等反向代理服務器實現HTTP轉發負載均衡，而規模稍大以后則基本都使用LVS實現IP層負載均衡或者數據鏈路層負載均衡。 目前越來越多的網站使用云服務部署網站，這些云服務也提供負載均衡服務，背后使用的技術依然是LVS或者HTTP轉發。

2. 通過遠程分布式緩存實現緩存可伸縮

緩存是改善網站性能的最重要手段，一方面緩存使用內存存儲數據，可以更快速地響應請求；另一方面大量數據訪問請求通過緩存返回，減少數據庫壓力， 進一步改善性能。目前網站中大量使用的緩存服務是Memcached或者Redis。Memcached分布式緩存訪問模型如圖6。

圖6 Memcached分布式緩存訪問模型 （圖片來源《大型網站技術架構：核心原理與案例分析》）

應用程序通過Memcached客戶端訪問Memcached服務器集群，其中路由算法模塊負責根據應用程序輸入的KEY計算得到應該訪問哪臺服務器，然后通過通信模塊從對應服務器上讀寫數據。

如果Memecahed集群需要緩存更多數據或者需要提供更高的并發訪問，只需要向集群中增加新的服務器，然后修改客戶端服務器列表即可應用程序訪問到新加的服務器。

需要注意的是如果路由算法選擇不當，比如使用余數Hash算法，會出現加入一臺服務器而導致現有的緩存數據大量訪問不能命中的情況，其后果相當于 緩存服務器集群整體宕機，給系統帶來災難性后果。目前Memcached主要采用一致性Hash算法，這種算法可以使加入新服務器對現有數據訪問影響最 小。而Redis通過一種類似虛擬節點的映射算法也可以達到相似的效果。

3. 通過主從復制和分布式數據庫實現數據庫可伸縮

目前各種網站主要使用的關系數據庫是MySQL，MySQL支持數據復制功能，使用這個功能可以對數據庫進行簡單的伸縮。圖7為使用數據復制的MySQL集群伸縮性方案。

圖7 通過主從復制實現簡單伸縮性的MySQL集群 （圖片來源《大型網站技術架構：核心原理與案例分析》）

在這個方案中，雖然多臺服務器部署MySQL實例，但是他們的角色有主從之分，數據寫操作都在主服務器上，由主服務器將數據同步到集群中其他從服務器，數據讀操作及數據分析等離線操作在從服務器上進行。

主從復制只能通過增加有限的幾臺服務器分擔數據庫的訪問壓力，如果數據庫需要記錄數千萬上億條記錄，需要應對每秒數十萬次訪問壓力，那么主從復制 是遠遠不夠的。這種情況下，可以考慮使用更具伸縮性的各種NoSQL數據庫產品，如HBase等，也可以考慮使用分布式數據庫。分布式關系數據庫則通過一 個代理層將數據分片并經過路由后寫入一個關系數據庫集群中。

除了應用、緩存、數據庫，其他的服務，諸如搜索、消息隊列等也可以以類似的思路和方案實現集群可伸縮。

三、打造可伸縮的技術團隊

創業公司剛開始時，通常不過兩三個工程師，圍繞核心業務，開發一個簡單的版本就發布上線開始運營了。隨著業務不斷發展，服務器數量必定是越來越 多、技術越來越復雜，對應的，公司規模也是越來越大，工程師團隊越來越多人。一般說來，一家互聯網公司能做到上市，工程師團隊的人數大概從數百人到數千人 不等，技術團隊規模和創業時相比擴大數百倍。這就要求必須有效組織工程師團隊，打造可伸縮的技術團隊，使技術團隊的成長和公司業務成長、技術水平進步保持 一致。

1. 團隊拆分

制約一個團隊人數規模的主要因素是溝通路徑，溝通路徑越多，信息傳遞越慢，傳遞過程中引入的噪音越多，團隊越趨于混亂。一個5人團隊，溝通路徑是 10=(5*4)/2，一個9人團隊，溝通路徑是36=(9*8)/2，溝通路徑隨團隊規模呈指數級增長。所以當技術團隊人數增長到一定規模，和構建可伸 縮的Web架構中需要對服務進行拆分一樣，需要對團隊進行拆分，將一個大團隊拆分成幾個小團隊，使每個小的團隊保持一個比較少的人數。

團隊拆分有兩種方案，一種是按職能拆分，前端工程師、后端工程師、測試工程師、運維工程師、數據倉庫工程師各種工程師分別構成一個個的小團隊，這 種拆分的好處是團隊結構比較穩定，團隊成員都是使用同樣技術的“自己人”，團隊內部溝通交流更快速高效；帶來的問題是開發過程是按照產品和項目組織的，而 開發一個產品需要用到前端、后端、測試、運維各種工程師，開發過程會遇到各種跨團隊的交流與合作，帶來更多的溝通成本。另一種是按照產品和項目拆分，團隊 圍繞產品展開，每個團隊內部擁有開發維護一個產品所需的各種技術角色，從開發到測試發布運維都在團隊內部搞定，不需要太多跨團隊合作，這種拆分也存在一些 問題，特別是創業公司早期，產品不穩定，管理層決定要上一個新產品，于是迅速招人開發，但是很多時候產品剛上線不久甚至還沒上線，管理層的決定又有變化， 產品不做了，團隊解散，這種朝令夕改會對技術團隊造成較大傷害，所以某些互聯網公司特別將“擁抱變化”上升到公司價值觀高度，讓員工對這種情況做好心理準 備。

對于公司而言，前一種方案帶來的問題是溝通低效、人員冗余、開發進展緩慢；后一種方案帶來的問題是員工情緒低落影響士氣。顯然前一種方案對公司發 展影響更大，所以實踐中，更多公司采用后一種團隊組織方式。為了應對這種方案帶來的消極影響，公司會積極組織各種培（xi）訓（nao），提供各種員工福 利員工關懷，讓員工忘記各種不快，投入到下一個產品開發中。不過對創業公司而言，從本質上，員工利益和公司利益是一致的，只有公司活下去、做大做強，所有 人才能更好的獲益，不過這也要求創業公司盡可能做到決策透明，讓所有員工能理解管理層的決定，并自覺維護、執行管理層的決定。

2. 保持敏捷

創業團隊白手起家，不但表現在缺資金缺用戶缺人才，也表現在缺管理缺標準缺規范，于是采用各種“野路子”的管理手段。但是公司發展到一定規模，這 些手段就開始捉襟見肘，出現各種問題，于是公司開始從各種名企外企引入各類『管理人才』，進行規范化管理。不過在這個規范化的過程中，有時候會出現某種矯 枉過正，導致公司僵化笨拙，還沒成為大公司卻得了一堆大公司的病。

舉兩個極端但是真實的例子。某公司要求代碼單元測試覆蓋率必須達到一定比率，并且寫了工具專門掃描工程師提交的代碼是否達到要求的單元測試覆蓋 率，于是就看到有些工程師為getXXX和setXXX方法寫測試用例。某公司要求設計階段必須寫設計文檔，并提供了設計文檔模板，這個模板有一章叫做 『數據庫設計』，某個項目不需要數據庫，因此設計文檔不通過評審，為此工程師不得不設計了一個永遠不會用到的數據庫。

某位偉人曾經說過：教條不如狗屎，狗屎可以肥田，教條屁用沒有。有些『管理人員』自己不曾在一線實踐過，卻為一線人員制定各種規章制度，效果可想 而知。對創業公司而言，最好的管理不是流程規范，而是最佳實踐。某個項目迭代管理做得好，某個項目設計文檔寫得好，拿來在全公司分享，大家一起學習改進， 在實踐中提高，產生更好的實踐繼續分享。從實踐中來到實踐中去，而不是從PPT來到Word中去。

總結

本文限于篇幅，概要描述了Web應用可伸縮架構技術，期望創業公司工程師在創業早期就能明了網站技術發展的一般模式，更好地規劃自己公司的技術發 展道路。關于網站可伸縮架構的更多技術細節，可以根據這篇文章提到的技術點按圖索驥閱讀更多資料，更重要的當然是在實踐中學習，隨著公司逐步壯大，自己也 逐漸成長為網站技術方面的卓越人才。期待未來最偉大的互聯網公司出現在中國，期待未來最頂尖的互聯網技術人才出現在本文的讀者當中，祝福大家。

作者簡介： 目前任職宅米網CTO，曾供職阿里巴巴與英特爾亞太研發中心，從事大型網站、分布式系統、大數據平臺方面的研發工作。著有《大型網站技術架構 核心原理與案例分析》一書。