論辯：好的架構是設計出來的，還是進化出來的？

編輯｜小智 關於好的架構是設計而來還是進化而來的爭論，架構師們眾說紛紜莫衷一是。本篇文章的目的不在於得出一個普世性的結論，而在於通過兩種截然相反的觀點，給大家帶來一些啟發，引出一些討論。讀完全文後，請給我一個你的答案。

資深架構師眼中的架構是怎樣的？

作者：楊波，LVMH集團區首席架構師

我對架構定義的理解

大概在7~8年前，我曾經有一個美國對口的架構師導師，他對我講架構其實是發現利益相關者（stakeholder），然後解決他們的關注點（concerns），後來我讀到一本書《軟體系統架構:使用視點和視角與利益相關者合作》，裡面提到的理念也是這樣說：系統架構的目標是解決利益相關者的關注點。

這是從那本書裡頭的一張截圖，我之前公司分享架構定義常常用這張圖，架構是這樣定義的：

• 每個系統都有一個架構

• 架構由架構元素以及相互之間的關係構成

• 系統是為了滿足利益相關者（stakeholder）的需求而構建的

• 利益相關者都有自己的關注點（concerns）

• 架構由架構文檔描述

• 架構文檔描述了一系列的架構視角

• 每個視角都解決並且對應到利益相關者的關注點。

架構系統前，架構師的首要任務是盡最大可能找出所有利益相關者，業務方，產品經理，客戶/用戶，開發經理，工程師，項目經理，測試人員，運維人員，產品運營人員等等都有可能是利益相關者，架構師要充分和利益相關者溝通，深入理解他們的關注點和痛點，並出架構解決這些關注點。

架構師常犯錯誤是漏掉重要的利益相關者，溝通不充分，都會造成架構有欠缺，不能滿足利益相關者的需求。利益相關者的關注點是有可能衝突的，比如管理層（可管理性）vs技術方（性能），業務方（多快好省）vs 技術方（可靠穩定），這需要架構師去靈活平衡，如何平衡體現了架構師的水平和價值。

關於架構的第二點定義是說架構主要關注非功能性需求（non-functional requirements），即所謂的-abilities。

這個是我上次公司內分享的一個圖。

這個是slideshare一個ppt裡頭截取的，兩個圖都是列出了架構的非功能性關注點；關於架構的水平該如何衡量，去年我看到一句話，對我影響很大。

Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change.

翻譯為中文就是，架構表示對一個系統的成型起關鍵作用的設計決策，架構定系統基本就成型了，這裡的關鍵性可以由變化的成本來決定。這句話是Grady Booch說的，他是UML的創始人之一。

進一步展開講，架構的目標是用於管理複雜性、易變性和不確定性，以確保在長期的系統演化過程中，一部分架構的變化不會對架構的其它部分產生不必要的負面影響。這樣做可以確保業務和研發效率的敏捷，讓應用的易變部分能夠頻繁地變化，對應用的其它部分的影響儘可能的小。

我剛入軟體開發這個行業之初，談的架構主要是性能，高可用等等。現在，見過無數遺留系統，特別是國內企業IT的現狀，無數高耦合的遺留系統，不良的架構像手銬一樣牢牢地限制住業務，升級替換成本非常巨大， 所以我更加關注可理解，可維護性，可擴展性，成本 。我想補充一句，創業公司創業之初獲得好的架構師或技術CTO非常重要。

架構師如何看待應用架構的進化？

軟體是人類活動的虛擬，業務架構是生產活動的體現，應用架構是具體分工合作關係的體現。

單體應用類似原始氏族時代，氏族內部有簡單分工，氏族之間沒有聯繫；分散式架構類似封建社會，每個家庭自給自足，家庭之間有少量交換關係；SOA架構類似工業時代，企業提供各種成品服務，我為人人，人人為我，相互依賴。微內核的SOA架構類似后工業時代，有些企業聚焦提供水電煤等基礎設施服務，其他企業在之上提供生活服務，依賴有層次。

業務架構是生產力，應用架構是生產關係，技術架構是生產工具。業務架構決定應用架構，應用架構需要適配業務架構，並隨著業務架構不斷進化，同時應用架構依託技術架構最終落地。

企業一開始業務比較簡單，比如進銷存，此時面向內部用戶，提供簡單的信息管理系統（MIS），支持數據增刪改查即可，單體應用可以滿足要求。

隨著業務深入，進銷存每塊業務都變複雜，同時新增客戶關係管理，以更好支持營銷，業務的深度和廣度都增加，這時需要對系統按照業務拆分，變成一個分散式系統。

更進一步，企業轉向互聯網+戰略，拓展在線交易，線上系統和內部系統業務類似，沒必要重做一套，此時把內部系統的邏輯做服務化改造，同時供線上線下系統使用，變成一個簡單的SOA架構。

緊接著業務模式越來越複雜，訂單、商品、庫存、價格每塊玩法都很深入，比如價格區分會員等級，訪問渠道（無線還是PC），銷售方式（團購還是普通）等，還有大量的價格促銷，這些規則很複雜，容易相互衝突，需要把分散到各個業務的價格邏輯進行統一管理，以基礎價格服務的方式透明地提供給上層應用，變成一個微內核的SOA架構。

同時不管是企業內部用戶，還是外部顧客所需要的功能，都由很多細分的應用提供支持，需要提供portal，集成相關應用，為不同用戶提供統一視圖，頂層變成一個AOA的架構（application orientated architecture）。

隨著業務和系統不斷進化，最後一個比較完善的大型互聯網應用架構如下圖所示：

最終整個系統化整為零，形神兼備，支持積木式拼裝，支持開發敏捷和業務敏捷。應用架構，需要站在業務和技術中間，在正確的時間點做正確的架構選擇，保證系統有序進化。

觀點1：好的架構是進化來的，不是設計來的

以58同城的架構演進為例

對很多創業公司而言，在初期的時候，我們很難在初期就預估到流量十倍以後、百倍以後、一千倍以後網站的架構會變成什麼樣。當然，如果在最初的時期，就設計一個千萬級併發的流量架構，那樣的話，成本是也是非常之高的，估計很難有公司會這樣做。所以，我們主要來講架構是如何進行演化的。我們在每個階段，找到對應該階段網站架構所面臨的問題，然後在不斷解決這些問題的過程中，整個戰略的架構就是在不斷的演進了。

其實，在 58 同城建立之初，站點的流量非常小，可能也就是是十萬級別，這也就意味著，平均每秒鐘也就是幾次的訪問。此時網站架構的特點：請求量是比較低，數據量比較小，代碼量也比較小。可能找幾個工程師，很容易就做一個這樣的站點，根本沒什麼「架構」可言。

這也是很多創業公司初期面臨的問題，最開始58同城的站點架構用一個詞概括就是「ALL IN ONE」，如下圖所示：

就像一個單機系統，所有的東西都部署在一台機器上，包括站點、資料庫、文件等等。而工程師每天的核心工作就是 CURD，前端傳過來一些數據，然後業務邏輯層拼裝成一些 CURD 訪問資料庫，資料庫返回數據，數據拼裝成頁面，最終返回到瀏覽器。相信很多創業團隊，初期做的工作也是類似，每天寫代碼，寫 SQL、介面參數、訪問數據等等。

這裡需要說明一個問題，大家都知道目前 58 同城使用的是 Windows、iis、SQL-Sever、C# 這條路。現在很多創業公司可能就不會這麼做。58 同城為什麼當時選擇了這條路？原因是公司招聘的第一個工程師和第二個工程師只會這個，所以只能走這條路。

如果可以重來？那麼會選擇LAMP

很多創業的同學可能會想，如果我們初期希望做一個產品的話，我們應該使用什麼架構？ 如果讓我們重來，可能我們現在會選 LAMP，為什麼？首先是無須編譯，而且快速發布功能強大，從前端到後端、資料庫訪問、業務邏輯處理等等全部可以搞定，最重要的是因為開源產品，是完全免費的。如果使用 LAMP 搭建一個論壇，兩天的時間就很足夠了。所以，如果在創業初期，就盡量不要再使用 Windows 的技術體系了。

中等規模：流量跨過十萬的階段，資料庫成為瓶頸

隨著 58 同城的高速增長，我們很快跨越了十萬流量的階段。主要需求是什麼？網站能夠正常訪問，當然速度更快點就好了。而此時系統面臨問題包括：在流量的高峰期容易宕機，因為大量的請求會壓到資料庫上，所以資料庫成為新的瓶頸，而且人多的時候，訪問速度會很慢。這時，我們的機器數量也從一台變成了多台。現在的架構就採用了分散式，如下圖所示：

首先，我們使用了一些非常常見的技術，一方面是動靜分離，動態的頁面通過 Web-Servre 訪問，靜態的像圖片等就單獨放到了一些伺服器上。另外一點就是讀寫分離。其實，對 58 同城或者說絕大部分的站點而言，一般來說都是讀多寫少。對 58 同城來說，絕大部分用戶是訪問信息，只有很少的用戶過來發貼。那麼如何擴展整個站點架構的讀請求呢？常用的是主從同步，讀寫分離。我們原來只有一個資料庫，現在使用多個不同的資料庫提供服務，這樣的話，就擴展了讀寫，很快就解決了中等規模下數據訪問的問題。

大流量：將整個 Windows 技術體系轉向了 Java 體系

流量越來越大，當流量超過一千多萬時，58 同城面對最大的問題就是性能和成本。此前，我提到58同城最初的技術選型是 Windows，應該是在 2006 年的時候，整個網站的性能變得非常之低。即使進行了業務拆分和一些優化，但是依然解決不了這個問題，所以我們當時做了一個非常艱難的決定，就是轉型：將整個 Windows 技術體系轉向了 Java 體系，這涵蓋了操作系統、資料庫等多個維度。

其實，現在很多大的互聯網公司在流量從小到大的過程中都經歷過轉型，包括京東、淘寶等等。對技術的要求越來越高，任何一個站點都不能掛，對站點的可用性要求也是越來越高。

如何提供整個架構的可用性？首先，在上層我們進行了一些改進和優化，再做進一步的垂直拆分，同時我們引入了 Cache，如下圖所示：

當架構變成「蜘蛛網」，人肉已很難搞定！

隨著用戶量、數據量併發量進一步的增長，58同城也拓展了很多的新業務，那麼對產品迭代速度要求就非常高，整體的架構對自動化的要求越來越高。

為了支撐業務的發展，技術團隊對架構做了進一步的解耦，另外就是引入了配置中心。另一點就是關於資料庫，當某一點成為一個業務線重點的時候，我們就會集中解決這個點的問題。最後一點就是效率矛盾，此時很多問題，靠「人肉」已經很難進行搞定了。這就需要自動化，包括回歸、測試、運維、監控等等都要回歸到自動化。

網站在不同的階段遇到的問題不一樣，而解決這些問題使用的技術也不一樣，流量小的時候，我們主要目的是提高開發效率，在早期要引入 ORM，DAO 這些技術。隨著流量變大，使用動靜分離、讀寫分離、主從同步、垂直拆分、CDN、MVC 等方式不斷提升網站的穩定性。面對更大的流量時，通過垂直拆分、服務化、反向代理、開發框架（站點/服務）等等，不斷提升高可用。在面對上億級的更大流量時，通過中心化、柔性服務、消息匯流排、自動化（回歸，測試，運維，監控）來迎接新的挑戰。未來的就是繼續實現 移動化，大數據實時計算，平台化…

觀點2：好的架構需要精心設計，千萬別把問題留給進化

以Google的經驗為例

我認為好的架構，都需要經過這麼幾個過程：設計 – 進化 – 進化 …… – 被推翻 – 再設計，是這樣循環往複的過程。最開始的架構，肯定是從無到有，根據產品的需求和當時業務的需求設計出來的。

我覺得，一個系統的演化，一般會經過這樣的階段：第一個系統肯定是under-engineer的，從無到有被設計出來后，肯定是不完善的；第二個版本，一般是over-engineer的，因為隨著之前那個版本的使用，積累了一定量需求后，會發現想要增加很多內容在上面；到第三個版本，應該是最恰當的，減去了一些沒必要的設計之後，更合適。但當到了某一個時間點，發現現有的系統架構已經沒有辦法再維持下去，跟不上需求增長時，就需要推倒再重新設計。

拿谷歌的廣告系統來說，我03年加入了Google，當時的架構還是比較簡單的，只分為兩層，web serving層和存儲層。所有的數據都存在MySInfoQL里，前端的web server會把用戶搜索的關鍵詞轉化成一個資料庫的query，然後把所有的查詢結果做聚合和排序。

但很快就遇到了問題。我們有兩個customer，一個是eBay、一個是Amazon，他們什麼關鍵詞都買，所以他們一家就要佔用一個獨立的資料庫，他們的量還不斷往上漲 當時的解決方案呢，就是多做一層分離，把存儲數據和需要響應在線搜索的數據通過分開，增加一層cache server。

後來很快用customer做分片也不足夠了。我們就轉為了用keyword的fingerprint做shard key，從增長最快的數據著手解決。其他還做了的包括異地容災，多套primary數據中心同時運行等等，都是後來的升級了。架構的演進，一般是這樣一個周而復始的循環過程。

Google AdWords 經歷的重大調整和優化

除了上面提到的，還有過一次升級，大概是在04年到05年之間。這一次在結構上有更加根本的改變，主要是考慮了geographical的redundancy。因為那時候賺的錢已經很多了，服務一旦down掉後果是非常嚴重的。雖然我們是從數據存儲上有很多replica，但是primary還是很容易down掉的。我們後來就建了兩套primary，在primary的更新會被push到其他所有的replica datacenter去。

一旦某一個primary DC出了問題，比如地震之類的，我們可以很快switch到另一個DC去，正常情況下兩套系統會同時運行。我們的每個replica datacenter也會有兩套不同的stream，data也分別來自於不同的primary。這兩套stream是完全獨立的，一旦一個stream出現問題，可以很快的switch上另一個stream上去。

當時也沒有成熟的Auto failover的機制。當時能買到的就是Oracle，但是沒辦法scale到那種程度的 。理論好像有了很多年了，但是真正在實踐中一個在很多Master中投票，選出winner的演算法也是沒有的。這個也是Google當時才實現出來的。其實還有很多底層問題，也有一些比較有意思的事情。

比如說當你有五十個datacenter的時候，你怎麼把data push過去，也是一個挺大的問題，因為數據量很大。當時我們也沒有用現成的solution，也沒有任何的現成的solution可以用，我們就自己研究了一套。說白了它就是一個pub-sub或者說是一個multi-cast的問題吧。

一開始的時候，data push的latency是用小時來計算的，就有人利用了這個延時長的缺陷刷了很多廣告的impressions。因為我們的replica DC需要幾個小時才能知道某個customer的預算已經用完了。後來經過了一系列的優化，我們才把跨DC的latency做到了分鐘級別，如果是同一個DC，那就是秒級別了。

這些年在架構方面積累的經驗

我覺得沒有一種general purpose solution是可以拿過來就能用的。尤其在Google我們當時很清楚地意識到我們將會面臨的挑戰是其他人都沒有遇到過的，而且用那樣的方式一定是行不通的。但是，Google的經驗確實可以幫助把握好大的技術方向。

比如說，從一個rule-based的推薦系統切換成一個model-based的系統，一定會有一個比較大的提升。之後的演算法還可以優化，也會帶來提升，但可能很難再超越之前的提升幅度。具體的演算法實現、優化就得靠團隊里的這群年輕人了。

你的看法是？

一個

技術領導者們參加的大會

作為技術領導者，技術、管理之外，還需要什麼？業務、產品、心理、商業、資本……陌生的領域、全新的知識體系，帶來全新的挑戰與探索的激情。2017年7月，GTLC全球技術領導力峰會將在上海舉辦，並將以「探索圓外的世界」為主題，與參會CTO們一起探尋技術之外，更廣袤的未知世界。點擊 「 閱讀原文 」了解更多詳情，聆聽更多技術領導力實踐，與更多CTO交流碰撞！

程序員，這是你想要的技術leader嗎？