作者：楊波，LVMH集團(tuán)中國(guó)區(qū)首席架構(gòu)師

大概在7~8年前，我曾經(jīng)有一個(gè)美國(guó)對(duì)口的架構(gòu)師導(dǎo)師，他對(duì)我講架構(gòu)其實(shí)是發(fā)現(xiàn)利益相關(guān)者（stakeholder），然后解決他們的關(guān)注點(diǎn)（concerns），后來(lái)我讀到一本書《軟件系統(tǒng)架構(gòu):使用視點(diǎn)和視角與利益相關(guān)者合作》，里面提到的理念也是這樣說(shuō)：系統(tǒng)架構(gòu)的目標(biāo)是解決利益相關(guān)者的關(guān)注點(diǎn)。

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

1. 每個(gè)系統(tǒng)都有一個(gè)架構(gòu)

2. 架構(gòu)由架構(gòu)元素以及相互之間的關(guān)系構(gòu)成

3. 系統(tǒng)是為了滿足利益相關(guān)者（stakeholder）的需求而構(gòu)建的

4. 利益相關(guān)者都有自己的關(guān)注點(diǎn)（concerns）

5. 架構(gòu)由架構(gòu)文檔描述

6. 架構(gòu)文檔描述了一系列的架構(gòu)視角

7. 每個(gè)視角都解決并且對(duì)應(yīng)到利益相關(guān)者的關(guān)注點(diǎn)。

架構(gòu)系統(tǒng)前，架構(gòu)師的首要任務(wù)是盡最大可能找出所有利益相關(guān)者，業(yè)務(wù)方，產(chǎn)品經(jīng)理，客戶/用戶，開發(fā)經(jīng)理，工程師，項(xiàng)目經(jīng)理，測(cè)試人員，運(yùn)維人員，產(chǎn)品運(yùn)營(yíng)人員等等都有可能是利益相關(guān)者，架構(gòu)師要充分和利益相關(guān)者溝通，深入理解他們的關(guān)注點(diǎn)和痛點(diǎn)，并出架構(gòu)解決這些關(guān)注點(diǎn)。

架構(gòu)師常犯錯(cuò)誤是漏掉重要的利益相關(guān)者，溝通不充分，都會(huì)造成架構(gòu)有欠缺，不能滿足利益相關(guān)者的需求。利益相關(guān)者的關(guān)注點(diǎn)是有可能沖突的，比如管理層（可管理性）vs技術(shù)方（性能），業(yè)務(wù)方（多快好省）vs 技術(shù)方（可靠穩(wěn)定），這需要架構(gòu)師去靈活平衡，如何平衡體現(xiàn)了架構(gòu)師的水平和價(jià)值。

關(guān)于架構(gòu)的第二點(diǎn)定義是說(shuō)架構(gòu)主要關(guān)注非功能性需求（non-functional requirements），即所謂的-abilities。

這個(gè)是我上次公司內(nèi)分享的一個(gè)圖。

這個(gè)是slideshare一個(gè)ppt里頭截取的，兩個(gè)圖都是列出了架構(gòu)的非功能性關(guān)注點(diǎn)；關(guān)于架構(gòu)的水平該如何衡量，去年我看到一句話，對(duì)我影響很大。

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

翻譯為中文就是，架構(gòu)表示對(duì)一個(gè)系統(tǒng)的成型起關(guān)鍵作用的設(shè)計(jì)決策，架構(gòu)定系統(tǒng)基本就成型了，這里的關(guān)鍵性可以由變化的成本來(lái)決定。這句話是Grady Booch說(shuō)的，他是UML的創(chuàng)始人之一。

進(jìn)一步展開講，架構(gòu)的目標(biāo)是用于管理復(fù)雜性、易變性和不確定性，以確保在長(zhǎng)期的系統(tǒng)演化過(guò)程中，一部分架構(gòu)的變化不會(huì)對(duì)架構(gòu)的其它部分產(chǎn)生不必要的負(fù)面影響。這樣做可以確保業(yè)務(wù)和研發(fā)效率的敏捷，讓應(yīng)用的易變部分能夠頻繁地變化，對(duì)應(yīng)用的其它部分的影響盡可能的小。

我剛?cè)胲浖_發(fā)這個(gè)行業(yè)之初，談的架構(gòu)主要是性能，高可用等等?，F(xiàn)在，見過(guò)無(wú)數(shù)遺留系統(tǒng)，特別是國(guó)內(nèi)企業(yè)IT的現(xiàn)狀，無(wú)數(shù)高耦合的遺留系統(tǒng)，不良的架構(gòu)像手銬一樣牢牢地限制住業(yè)務(wù)，升級(jí)替換成本非常巨大， 所以我更加關(guān)注可理解，可維護(hù)性，可擴(kuò)展性，成本 。我想補(bǔ)充一句，創(chuàng)業(yè)公司創(chuàng)業(yè)之初獲得好的架構(gòu)師或技術(shù)CTO非常重要。

軟件是人類活動(dòng)的虛擬，業(yè)務(wù)架構(gòu)是生產(chǎn)活動(dòng)的體現(xiàn)，應(yīng)用架構(gòu)是具體分工合作關(guān)系的體現(xiàn)。

單體應(yīng)用類似原始氏族時(shí)代，氏族內(nèi)部有簡(jiǎn)單分工，氏族之間沒(méi)有聯(lián)系；分布式架構(gòu)類似封建社會(huì)，每個(gè)家庭自給自足，家庭之間有少量交換關(guān)系；SOA架構(gòu)類似工業(yè)時(shí)代，企業(yè)提供各種成品服務(wù)，我為人人，人人為我，相互依賴。微內(nèi)核的SOA架構(gòu)類似后工業(yè)時(shí)代，有些企業(yè)聚焦提供水電煤等基礎(chǔ)設(shè)施服務(wù)，其他企業(yè)在之上提供生活服務(wù)，依賴有層次。

業(yè)務(wù)架構(gòu)是生產(chǎn)力，應(yīng)用架構(gòu)是生產(chǎn)關(guān)系，技術(shù)架構(gòu)是生產(chǎn)工具。業(yè)務(wù)架構(gòu)決定應(yīng)用架構(gòu)，應(yīng)用架構(gòu)需要適配業(yè)務(wù)架構(gòu)，并隨著業(yè)務(wù)架構(gòu)不斷進(jìn)化，同時(shí)應(yīng)用架構(gòu)依托技術(shù)架構(gòu)最終落地。

企業(yè)一開始業(yè)務(wù)比較簡(jiǎn)單，比如進(jìn)銷存，此時(shí)面向內(nèi)部用戶，提供簡(jiǎn)單的信息管理系統(tǒng)（MIS），支持?jǐn)?shù)據(jù)增刪改查即可，單體應(yīng)用可以滿足要求。

隨著業(yè)務(wù)深入，進(jìn)銷存每塊業(yè)務(wù)都變復(fù)雜，同時(shí)新增客戶關(guān)系管理，以更好支持營(yíng)銷，業(yè)務(wù)的深度和廣度都增加，這時(shí)需要對(duì)系統(tǒng)按照業(yè)務(wù)拆分，變成一個(gè)分布式系統(tǒng)。

更進(jìn)一步，企業(yè)轉(zhuǎn)向互聯(lián)網(wǎng)+戰(zhàn)略，拓展在線交易，線上系統(tǒng)和內(nèi)部系統(tǒng)業(yè)務(wù)類似，沒(méi)必要重做一套，此時(shí)把內(nèi)部系統(tǒng)的邏輯做服務(wù)化改造，同時(shí)供線上線下系統(tǒng)使用，變成一個(gè)簡(jiǎn)單的SOA架構(gòu)。

緊接著業(yè)務(wù)模式越來(lái)越復(fù)雜，訂單、商品、庫(kù)存、價(jià)格每塊玩法都很深入，比如價(jià)格區(qū)分會(huì)員等級(jí)，訪問(wèn)渠道（無(wú)線還是PC），銷售方式（團(tuán)購(gòu)還是普通）等，還有大量的價(jià)格促銷，這些規(guī)則很復(fù)雜，容易相互沖突，需要把分散到各個(gè)業(yè)務(wù)的價(jià)格邏輯進(jìn)行統(tǒng)一管理，以基礎(chǔ)價(jià)格服務(wù)的方式透明地提供給上層應(yīng)用，變成一個(gè)微內(nèi)核的SOA架構(gòu)。

同時(shí)不管是企業(yè)內(nèi)部用戶，還是外部顧客所需要的功能，都由很多細(xì)分的應(yīng)用提供支持，需要提供portal，集成相關(guān)應(yīng)用，為不同用戶提供統(tǒng)一視圖，頂層變成一個(gè)AOA的架構(gòu)（application orientated architecture）。

隨著業(yè)務(wù)和系統(tǒng)不斷進(jìn)化，最后一個(gè)比較完善的大型互聯(lián)網(wǎng)應(yīng)用架構(gòu)如下圖所示：

最終整個(gè)系統(tǒng)化整為零，形神兼?zhèn)洌С址e木式拼裝，支持開發(fā)敏捷和業(yè)務(wù)敏捷。應(yīng)用架構(gòu)，需要站在業(yè)務(wù)和技術(shù)中間，在正確的時(shí)間點(diǎn)做正確的架構(gòu)選擇，保證系統(tǒng)有序進(jìn)化。

以58同城的架構(gòu)演進(jìn)為例

對(duì)很多創(chuàng)業(yè)公司而言，在初期的時(shí)候，我們很難在初期就預(yù)估到流量十倍以后、百倍以后、一千倍以后網(wǎng)站的架構(gòu)會(huì)變成什么樣。當(dāng)然，如果在最初的時(shí)期，就設(shè)計(jì)一個(gè)千萬(wàn)級(jí)并發(fā)的流量架構(gòu)，那樣的話，成本是也是非常之高的，估計(jì)很難有公司會(huì)這樣做。所以，我們主要來(lái)講架構(gòu)是如何進(jìn)行演化的。我們?cè)诿總€(gè)階段，找到對(duì)應(yīng)該階段網(wǎng)站架構(gòu)所面臨的問(wèn)題，然后在不斷解決這些問(wèn)題的過(guò)程中，整個(gè)戰(zhàn)略的架構(gòu)就是在不斷的演進(jìn)了。

其實(shí)，在 58 同城建立之初，站點(diǎn)的流量非常小，可能也就是是十萬(wàn)級(jí)別，這也就意味著，平均每秒鐘也就是幾次的訪問(wèn)。此時(shí)網(wǎng)站架構(gòu)的特點(diǎn)：請(qǐng)求量是比較低，數(shù)據(jù)量比較小，代碼量也比較小?？赡苷?guī)讉€(gè)工程師，很容易就做一個(gè)這樣的站點(diǎn)，根本沒(méi)什么「架構(gòu)」可言。

這也是很多創(chuàng)業(yè)公司初期面臨的問(wèn)題，最開始58同城的站點(diǎn)架構(gòu)用一個(gè)詞概括就是「ALL IN ONE」，如下圖所示：

就像一個(gè)單機(jī)系統(tǒng)，所有的東西都部署在一臺(tái)機(jī)器上，包括站點(diǎn)、數(shù)據(jù)庫(kù)、文件等等。而工程師每天的核心工作就是 CURD，前端傳過(guò)來(lái)一些數(shù)據(jù)，然后業(yè)務(wù)邏輯層拼裝成一些 CURD 訪問(wèn)數(shù)據(jù)庫(kù)，數(shù)據(jù)庫(kù)返回?cái)?shù)據(jù)，數(shù)據(jù)拼裝成頁(yè)面，最終返回到瀏覽器。相信很多創(chuàng)業(yè)團(tuán)隊(duì)，初期做的工作也是類似，每天寫代碼，寫 SQL、接口參數(shù)、訪問(wèn)數(shù)據(jù)等等。

這里需要說(shuō)明一個(gè)問(wèn)題，大家都知道目前 58 同城使用的是 Windows、iis、SQL-Sever、C# 這條路?，F(xiàn)在很多創(chuàng)業(yè)公司可能就不會(huì)這么做。58 同城為什么當(dāng)時(shí)選擇了這條路？原因是公司招聘的第一個(gè)工程師和第二個(gè)工程師只會(huì)這個(gè)，所以只能走這條路。

很多創(chuàng)業(yè)的同學(xué)可能會(huì)想，如果我們初期希望做一個(gè)產(chǎn)品的話，我們應(yīng)該使用什么架構(gòu)？ 如果讓我們重來(lái)，可能我們現(xiàn)在會(huì)選 LAMP，為什么？首先是無(wú)須編譯，而且快速發(fā)布功能強(qiáng)大，從前端到后端、數(shù)據(jù)庫(kù)訪問(wèn)、業(yè)務(wù)邏輯處理等等全部可以搞定，最重要的是因?yàn)殚_源產(chǎn)品，是完全免費(fèi)的。如果使用 LAMP 搭建一個(gè)論壇，兩天的時(shí)間就很足夠了。所以，如果在創(chuàng)業(yè)初期，就盡量不要再使用 Windows 的技術(shù)體系了。

隨著 58 同城的高速增長(zhǎng)，我們很快跨越了十萬(wàn)流量的階段。主要需求是什么？網(wǎng)站能夠正常訪問(wèn)，當(dāng)然速度更快點(diǎn)就好了。而此時(shí)系統(tǒng)面臨問(wèn)題包括：在流量的高峰期容易宕機(jī)，因?yàn)榇罅康恼?qǐng)求會(huì)壓到數(shù)據(jù)庫(kù)上，所以數(shù)據(jù)庫(kù)成為新的瓶頸，而且人多的時(shí)候，訪問(wèn)速度會(huì)很慢。這時(shí)，我們的機(jī)器數(shù)量也從一臺(tái)變成了多臺(tái)。現(xiàn)在的架構(gòu)就采用了分布式，如下圖所示：

首先，我們使用了一些非常常見的技術(shù)，一方面是動(dòng)靜分離，動(dòng)態(tài)的頁(yè)面通過(guò) Web-Servre 訪問(wèn)，靜態(tài)的像圖片等就單獨(dú)放到了一些服務(wù)器上。另外一點(diǎn)就是讀寫分離。其實(shí)，對(duì) 58 同城或者說(shuō)絕大部分的站點(diǎn)而言，一般來(lái)說(shuō)都是讀多寫少。對(duì) 58 同城來(lái)說(shuō)，絕大部分用戶是訪問(wèn)信息，只有很少的用戶過(guò)來(lái)發(fā)貼。那么如何擴(kuò)展整個(gè)站點(diǎn)架構(gòu)的讀請(qǐng)求呢？常用的是主從同步，讀寫分離。我們?cè)瓉?lái)只有一個(gè)數(shù)據(jù)庫(kù)，現(xiàn)在使用多個(gè)不同的數(shù)據(jù)庫(kù)提供服務(wù)，這樣的話，就擴(kuò)展了讀寫，很快就解決了中等規(guī)模下數(shù)據(jù)訪問(wèn)的問(wèn)題。

流量越來(lái)越大，當(dāng)流量超過(guò)一千多萬(wàn)時(shí)，58 同城面對(duì)最大的問(wèn)題就是性能和成本。此前，我提到58同城最初的技術(shù)選型是 Windows，應(yīng)該是在 2006 年的時(shí)候，整個(gè)網(wǎng)站的性能變得非常之低。即使進(jìn)行了業(yè)務(wù)拆分和一些優(yōu)化，但是依然解決不了這個(gè)問(wèn)題，所以我們當(dāng)時(shí)做了一個(gè)非常艱難的決定，就是轉(zhuǎn)型：將整個(gè) Windows 技術(shù)體系轉(zhuǎn)向了 Java 體系，這涵蓋了操作系統(tǒng)、數(shù)據(jù)庫(kù)等多個(gè)維度。

其實(shí)，現(xiàn)在很多大的互聯(lián)網(wǎng)公司在流量從小到大的過(guò)程中都經(jīng)歷過(guò)轉(zhuǎn)型，包括京東、淘寶等等。對(duì)技術(shù)的要求越來(lái)越高，任何一個(gè)站點(diǎn)都不能掛，對(duì)站點(diǎn)的可用性要求也是越來(lái)越高。

如何提供整個(gè)架構(gòu)的可用性？首先，在上層我們進(jìn)行了一些改進(jìn)和優(yōu)化，再做進(jìn)一步的垂直拆分，同時(shí)我們引入了 Cache，如下圖所示：

隨著用戶量、數(shù)據(jù)量并發(fā)量進(jìn)一步的增長(zhǎng)，58同城也拓展了很多的新業(yè)務(wù)，那么對(duì)產(chǎn)品迭代速度要求就非常高，整體的架構(gòu)對(duì)自動(dòng)化的要求越來(lái)越高。

為了支撐業(yè)務(wù)的發(fā)展，技術(shù)團(tuán)隊(duì)對(duì)架構(gòu)做了進(jìn)一步的解耦，另外就是引入了配置中心。另一點(diǎn)就是關(guān)于數(shù)據(jù)庫(kù)，當(dāng)某一點(diǎn)成為一個(gè)業(yè)務(wù)線重點(diǎn)的時(shí)候，我們就會(huì)集中解決這個(gè)點(diǎn)的問(wèn)題。最后一點(diǎn)就是效率矛盾，此時(shí)很多問(wèn)題，靠「人肉」已經(jīng)很難進(jìn)行搞定了。這就需要自動(dòng)化，包括回歸、測(cè)試、運(yùn)維、監(jiān)控等等都要回歸到自動(dòng)化。

網(wǎng)站在不同的階段遇到的問(wèn)題不一樣，而解決這些問(wèn)題使用的技術(shù)也不一樣，流量小的時(shí)候，我們主要目的是提高開發(fā)效率，在早期要引入 ORM，DAO 這些技術(shù)。隨著流量變大，使用動(dòng)靜分離、讀寫分離、主從同步、垂直拆分、CDN、MVC 等方式不斷提升網(wǎng)站的穩(wěn)定性。面對(duì)更大的流量時(shí)，通過(guò)垂直拆分、服務(wù)化、反向代理、開發(fā)框架（站點(diǎn)/服務(wù)）等等，不斷提升高可用。在面對(duì)上億級(jí)的更大流量時(shí)，通過(guò)中心化、柔性服務(wù)、消息總線、自動(dòng)化（回歸，測(cè)試，運(yùn)維，監(jiān)控）來(lái)迎接新的挑戰(zhàn)。未來(lái)的就是繼續(xù)實(shí)現(xiàn) 移動(dòng)化，大數(shù)據(jù)實(shí)時(shí)計(jì)算，平臺(tái)化…

以Google的經(jīng)驗(yàn)為例

我認(rèn)為好的架構(gòu)，都需要經(jīng)過(guò)這么幾個(gè)過(guò)程：設(shè)計(jì) – 進(jìn)化 – 進(jìn)化 …… – 被推翻 – 再設(shè)計(jì)，是這樣循環(huán)往復(fù)的過(guò)程。最開始的架構(gòu)，肯定是從無(wú)到有，根據(jù)產(chǎn)品的需求和當(dāng)時(shí)業(yè)務(wù)的需求設(shè)計(jì)出來(lái)的。

我覺(jué)得，一個(gè)系統(tǒng)的演化，一般會(huì)經(jīng)過(guò)這樣的階段：第一個(gè)系統(tǒng)肯定是under-engineer的，從無(wú)到有被設(shè)計(jì)出來(lái)后，肯定是不完善的；第二個(gè)版本，一般是over-engineer的，因?yàn)殡S著之前那個(gè)版本的使用，積累了一定量需求后，會(huì)發(fā)現(xiàn)想要增加很多內(nèi)容在上面；到第三個(gè)版本，應(yīng)該是最恰當(dāng)?shù)?，減去了一些沒(méi)必要的設(shè)計(jì)之后，更合適。但當(dāng)?shù)搅四骋粋€(gè)時(shí)間點(diǎn)，發(fā)現(xiàn)現(xiàn)有的系統(tǒng)架構(gòu)已經(jīng)沒(méi)有辦法再維持下去，跟不上需求增長(zhǎng)時(shí)，就需要推倒再重新設(shè)計(jì)。

拿谷歌的廣告系統(tǒng)來(lái)說(shuō)，我03年加入了Google，當(dāng)時(shí)的架構(gòu)還是比較簡(jiǎn)單的，只分為兩層，web serving層和存儲(chǔ)層。所有的數(shù)據(jù)都存在MySInfoQL里，前端的web server會(huì)把用戶搜索的關(guān)鍵詞轉(zhuǎn)化成一個(gè)數(shù)據(jù)庫(kù)的query，然后把所有的查詢結(jié)果做聚合和排序。

但很快就遇到了問(wèn)題。我們有兩個(gè)customer，一個(gè)是eBay、一個(gè)是Amazon，他們什么關(guān)鍵詞都買，所以他們一家就要占用一個(gè)獨(dú)立的數(shù)據(jù)庫(kù)，他們的量還不斷往上漲 當(dāng)時(shí)的解決方案呢，就是多做一層分離，把存儲(chǔ)數(shù)據(jù)和需要響應(yīng)在線搜索的數(shù)據(jù)通過(guò)分開，增加一層cache server。

后來(lái)很快用customer做分片也不足夠了。我們就轉(zhuǎn)為了用keyword的fingerprint做shard key，從增長(zhǎng)最快的數(shù)據(jù)著手解決。其他還做了的包括異地容災(zāi)，多套primary數(shù)據(jù)中心同時(shí)運(yùn)行等等，都是后來(lái)的升級(jí)了。架構(gòu)的演進(jìn)，一般是這樣一個(gè)周而復(fù)始的循環(huán)過(guò)程。

除了上面提到的，還有過(guò)一次升級(jí)，大概是在04年到05年之間。這一次在結(jié)構(gòu)上有更加根本的改變，主要是考慮了geographical的redundancy。因?yàn)槟菚r(shí)候賺的錢已經(jīng)很多了，服務(wù)一旦down掉后果是非常嚴(yán)重的。雖然我們是從數(shù)據(jù)存儲(chǔ)上有很多replica，但是primary還是很容易down掉的。我們后來(lái)就建了兩套primary，在primary的更新會(huì)被push到其他所有的replica datacenter去。

一旦某一個(gè)primary DC出了問(wèn)題，比如地震之類的，我們可以很快switch到另一個(gè)DC去，正常情況下兩套系統(tǒng)會(huì)同時(shí)運(yùn)行。我們的每個(gè)replica datacenter也會(huì)有兩套不同的stream，data也分別來(lái)自于不同的primary。這兩套stream是完全獨(dú)立的，一旦一個(gè)stream出現(xiàn)問(wèn)題，可以很快的switch上另一個(gè)stream上去。

當(dāng)時(shí)也沒(méi)有成熟的Auto failover的機(jī)制。當(dāng)時(shí)能買到的就是Oracle，但是沒(méi)辦法scale到那種程度的 。理論好像有了很多年了，但是真正在實(shí)踐中一個(gè)在很多Master中投票，選出winner的算法也是沒(méi)有的。這個(gè)也是Google當(dāng)時(shí)才實(shí)現(xiàn)出來(lái)的。其實(shí)還有很多底層問(wèn)題，也有一些比較有意思的事情。

比如說(shuō)當(dāng)你有五十個(gè)datacenter的時(shí)候，你怎么把data push過(guò)去，也是一個(gè)挺大的問(wèn)題，因?yàn)閿?shù)據(jù)量很大。當(dāng)時(shí)我們也沒(méi)有用現(xiàn)成的solution，也沒(méi)有任何的現(xiàn)成的solution可以用，我們就自己研究了一套。說(shuō)白了它就是一個(gè)pub-sub或者說(shuō)是一個(gè)multi-cast的問(wèn)題吧。

一開始的時(shí)候，data push的latency是用小時(shí)來(lái)計(jì)算的，就有人利用了這個(gè)延時(shí)長(zhǎng)的缺陷刷了很多廣告的impressions。因?yàn)槲覀兊膔eplica DC需要幾個(gè)小時(shí)才能知道某個(gè)customer的預(yù)算已經(jīng)用完了。后來(lái)經(jīng)過(guò)了一系列的優(yōu)化，我們才把跨DC的latency做到了分鐘級(jí)別，如果是同一個(gè)DC，那就是秒級(jí)別了。

我覺(jué)得沒(méi)有一種general purpose solution是可以拿過(guò)來(lái)就能用的。尤其在Google我們當(dāng)時(shí)很清楚地意識(shí)到我們將會(huì)面臨的挑戰(zhàn)是其他人都沒(méi)有遇到過(guò)的，而且用那樣的方式一定是行不通的。但是，Google的經(jīng)驗(yàn)確實(shí)可以幫助把握好大的技術(shù)方向。

比如說(shuō)，從一個(gè)rule-based的推薦系統(tǒng)切換成一個(gè)model-based的系統(tǒng)，一定會(huì)有一個(gè)比較大的提升。之后的算法還可以優(yōu)化，也會(huì)帶來(lái)提升，但可能很難再超越之前的提升幅度。具體的算法實(shí)現(xiàn)、優(yōu)化就得靠團(tuán)隊(duì)里的這群年輕人了。