從100PV到1億級(jí)PV網(wǎng)站架構(gòu)演變
一個(gè)網(wǎng)站就像一個(gè)人，存在一個(gè)從小到大的過(guò)程。養(yǎng)一個(gè)網(wǎng)站和養(yǎng)一個(gè)人一樣，不同時(shí)期需要不同的方法，不同的方法下有共同的原則。本文結(jié)合我自已14年網(wǎng)站人的經(jīng)歷記錄一些架構(gòu)演變中的體會(huì)。
1：積累是必不可少的
架構(gòu)師不是一天練成的。
1999年，我作了一個(gè)個(gè)人主頁(yè)，在學(xué)校內(nèi)的虛擬空間，參加了一次主頁(yè)大賽，幾個(gè)DREAMWEAVER的頁(yè)面，幾個(gè)TABLE作布局，一個(gè)DB連接，幾行PHP的代碼嵌入在HTML中，再用FTP傳到服務(wù)器上就可以給別人展示一個(gè)網(wǎng)站。
2000年，個(gè)人主頁(yè)已經(jīng)不能滿(mǎn)足好奇，在當(dāng)時(shí)的網(wǎng)管中心管起幾臺(tái)機(jī)器，作起網(wǎng)線(xiàn)水晶頭，用ALL PEOPLE SEEMS TO NEED DATA PROCESS的理論開(kāi)始認(rèn)識(shí)了7層網(wǎng)絡(luò)模塊（面試技術(shù)員工時(shí)，經(jīng)常會(huì)問(wèn)這些網(wǎng)絡(luò)基礎(chǔ)知識(shí)的理解）。有了基礎(chǔ)理論的武裝，我也開(kāi)始配置各種服務(wù)來(lái)玩 LINUX，AIX和FREEBSD這些系統(tǒng)。面對(duì)各種原理不懂的系統(tǒng)，目的只是想盡辦法去解決網(wǎng)站需要的各種基礎(chǔ)服務(wù)。當(dāng)時(shí)搭建了REALSERVER 流媒體服務(wù)，各種開(kāi)源FTP下載服務(wù)，BATTLENET游戲網(wǎng)關(guān)，APACHE（keepalive等配置，http報(bào)頭相關(guān)的知識(shí) 也是面試的老客戶(hù)），DNS，QMAIL等服務(wù)給學(xué)校的學(xué)生使用；
網(wǎng)站有近10萬(wàn)PV的時(shí)候，開(kāi)始考慮如何作擴(kuò)展拆分，MYSQL的MASTER SLAVE作讀寫(xiě)分離，MYSQL的索引優(yōu)化是當(dāng)時(shí)唯一會(huì)使用的DB性能優(yōu)化方法。這個(gè)階段基本上能解決需求，同時(shí)也遇到瓶頸，不知道訪(fǎng)問(wèn)量再大一個(gè)數(shù)量級(jí)，怎么辦?明顯感到技術(shù)能力不夠。當(dāng)時(shí)受限于網(wǎng)站的量一直沒(méi)有新的數(shù)量級(jí)的突破，導(dǎo)致了幾年內(nèi)技術(shù)工作以維護(hù)為主，體驗(yàn)著網(wǎng)站日常運(yùn)維的各種糾結(jié)，體力活。而這時(shí)期網(wǎng)站的2層架構(gòu)方法也一再被重復(fù)應(yīng)用到后續(xù)的N個(gè)網(wǎng)站的搭建過(guò)程中，2001年開(kāi)始的JSP與PHP之爭(zhēng)好像對(duì)我沒(méi)什么感覺(jué)，因?yàn)槲疫€是只會(huì)用那種很土的2層架構(gòu)作著網(wǎng)站：頁(yè)面中嵌入JSP，連接后端的MYSQL進(jìn)行數(shù)據(jù)的CRUD，沒(méi)有事務(wù)，沒(méi)有考慮數(shù)據(jù)庫(kù)讀寫(xiě)錯(cuò)誤，沒(méi)有考慮兩層系統(tǒng)不可用，因?yàn)橛袉?wèn)題只需要重啟，有報(bào)錯(cuò)只需要改JSP后刷新頁(yè)面。作網(wǎng)站確實(shí)是體力活。
2005年，在道富參與了FXCNG項(xiàng)目，用MULE ESB，接觸到MULE的前幾個(gè)月還沒(méi)有意識(shí)到這個(gè)系統(tǒng)在架構(gòu)中的位置。直到半年后，在與第三方系統(tǒng)集成的應(yīng)用中，才發(fā)現(xiàn)，這樣的一個(gè)系統(tǒng)就是傳說(shuō)中的中間件，他可以專(zhuān)業(yè)的解決一部份系統(tǒng)的職能，比如當(dāng)時(shí)的消息和遠(yuǎn)程調(diào)用代理。這時(shí)候我逐步有了一些架構(gòu)觀點(diǎn)，一個(gè)大型的應(yīng)用系統(tǒng)中，是需要隔離一部份技術(shù)職能，讓系統(tǒng)責(zé)任單一，方便技術(shù)維護(hù)和團(tuán)隊(duì)擴(kuò)展，專(zhuān)人辦專(zhuān)事。
2006年，阿里軟件，一個(gè)全新的開(kāi)始。進(jìn)入阿里軟件的前三個(gè)月在馬總的老家，淘寶的發(fā)源地：湖畔花園小區(qū)，2樓的4室兩廳里進(jìn)行了封閉式開(kāi)發(fā)，很累，但很興奮。這段時(shí)間，我參與了一個(gè)全新外貿(mào)ERP系統(tǒng)的搭建。雖然只作為一名普通的JAVA開(kāi)發(fā)工程師，僅負(fù)責(zé)一個(gè)很小的模塊開(kāi)發(fā)，但還是正式體會(huì)到一個(gè)大型系統(tǒng)的初創(chuàng)過(guò)程。這段時(shí)間對(duì)MVC的架構(gòu)理論有了深刻的理解。MVC三層架構(gòu)比2層架構(gòu)帶來(lái)的更好的技術(shù)擴(kuò)展與團(tuán)隊(duì)擴(kuò)展能力讓我映像深刻。M層負(fù)責(zé)DB 邏輯的CRUD，架構(gòu)師們開(kāi)發(fā)出了大量的中間層JAR包，完成了DAO層，DO的封裝，M層也完成了SERVICE層，完成了BO的封裝，接口包的封裝，系統(tǒng)使用了最常用的工廠、單例、FACACE等模式（直到現(xiàn)在，我面試人還是常常只會(huì)問(wèn)這些基本的模式）。V層的模板隔離，前端開(kāi)發(fā)可以在這一層和后端開(kāi)發(fā)一起修改界面（之后，更大規(guī)模的團(tuán)隊(duì)連這一層都可以再分離）。C層完成輸入輸出的基本校驗(yàn)和檢查然后調(diào)用后面的服務(wù)層功能或作轉(zhuǎn)發(fā)。 簡(jiǎn)潔樸素的結(jié)構(gòu)生命力是比較持久的。直到現(xiàn)在，MVC還是具有很強(qiáng)的生命力，在更種大型網(wǎng)站中承擔(dān)重要架構(gòu)骨架。
07年，我對(duì)應(yīng)用層，服務(wù)中心層，持久層三層架構(gòu)并沒(méi)有多少的實(shí)踐應(yīng)用和理解。因?yàn)镸VC對(duì)于初創(chuàng)系統(tǒng)或中小型網(wǎng)站，20人左右的團(tuán)隊(duì)規(guī)模來(lái)講，已經(jīng)適用。換個(gè)角度看，當(dāng)時(shí)在3個(gè)月內(nèi)作出一個(gè)完整的ERP系統(tǒng)也只用使用MVC，再選進(jìn)的架構(gòu)也需要考慮網(wǎng)站發(fā)展的階段。用戶(hù)一邊使用，工程師一邊迭代改進(jìn)架構(gòu)，這個(gè)方式是作網(wǎng)站，不是傳統(tǒng)應(yīng)用軟件開(kāi)發(fā)。ERP本身源自傳統(tǒng)應(yīng)用軟件領(lǐng)域，我們?cè)谟没ヂ?lián)網(wǎng)的方式作管理軟件，最大的挑戰(zhàn)應(yīng)該是這種邊作邊改進(jìn)架構(gòu)的理念。07年，這個(gè)理念之爭(zhēng)逐步在團(tuán)隊(duì)內(nèi)達(dá)成了一致，架構(gòu)師們小心的平衡著業(yè)務(wù)和架構(gòu)，這個(gè)網(wǎng)站高峰時(shí)，也支撐到了日訪(fǎng)問(wèn)量近千萬(wàn)的級(jí)別，沒(méi)有閃架。
08年，阿里軟件開(kāi)放平臺(tái)，又是一個(gè)新系統(tǒng)。全新的系統(tǒng)架構(gòu)總是可以得到足夠的時(shí)間來(lái)考慮末來(lái)1到3年的增漲。實(shí)際上，互聯(lián)網(wǎng)系統(tǒng)，我們感覺(jué)只能考慮到一年的架構(gòu)。這一年，我參與架構(gòu)設(shè)計(jì)，開(kāi)始理解了三層架構(gòu)的價(jià)值與擴(kuò)展能理，服務(wù)中心開(kāi)始搭建，因?yàn)檫@個(gè)系統(tǒng)將接受的幾百萬(wàn)在線(xiàn)的旺旺用戶(hù)訪(fǎng)問(wèn)，所以部份系統(tǒng)開(kāi)始考慮服務(wù)中心，想把業(yè)務(wù)邏輯聚合到服務(wù)層，由統(tǒng)一的團(tuán)隊(duì)進(jìn)行擴(kuò)展維護(hù)。另外，隨著兩年下來(lái)小的業(yè)務(wù)系統(tǒng)越來(lái)越多，小機(jī)上的oracle連接數(shù)也吃緊了，服務(wù)中心的需求越來(lái)越大。首先進(jìn)行的是用戶(hù)中心，想法是集成整個(gè)集團(tuán)隊(duì)賬號(hào)體系，基于『旺號(hào)』體系。這個(gè)用戶(hù)中心項(xiàng)目有個(gè)響亮的名字：UDB，項(xiàng)目過(guò)程可以寫(xiě)一本書(shū)。這里不再展開(kāi)。
《SAAS架構(gòu)設(shè)計(jì)》這本書(shū)，針對(duì)的是軟件平臺(tái)的早期ISV用戶(hù)?，F(xiàn)在的眼光來(lái)看，這書(shū)寫(xiě)的過(guò)于簡(jiǎn)單，正如十年后再來(lái)看今天我的寫(xiě)的這個(gè)筆記一樣。
09年，加盟了剛剛成立的aliexpress部門(mén)。經(jīng)歷了兩三個(gè)應(yīng)用的小系統(tǒng)到億級(jí)PV的在線(xiàn)交易系統(tǒng)。遇到了很多問(wèn)題，體會(huì)到一個(gè)小系統(tǒng)與大網(wǎng)站不同階段架構(gòu)的演變過(guò)程有不同的難處。
下文從不同維度分享億級(jí)PV網(wǎng)站架構(gòu)下我的體會(huì)和觀點(diǎn)。
2：知識(shí)結(jié)構(gòu)
網(wǎng)站架構(gòu)師有很多，有科班出身的，有美術(shù)專(zhuān)業(yè)的，有生物專(zhuān)業(yè)的，有學(xué)物理的，有派出所警察出身的，我覺(jué)得都是OK的。我也接觸到了這些架構(gòu)師，非常有特點(diǎn)，在很多技術(shù)領(lǐng)域有自已專(zhuān)深的。英雄不問(wèn)出路，好漢不提當(dāng)年勇。架構(gòu)師知識(shí)背景可以不同，個(gè)人看法是不同領(lǐng)域的人作網(wǎng)站架構(gòu)可以帶入很多交叉的思路。就像種樹(shù)的人再去種花，其實(shí)也是可以看到一些共性的總結(jié)抽象。
網(wǎng)站架構(gòu)師需要有編程的經(jīng)驗(yàn)，從基本的算法，常用的設(shè)計(jì)模式，多線(xiàn)程開(kāi)發(fā)，遠(yuǎn)程調(diào)用，不同類(lèi)型數(shù)據(jù)源使用，這些是面試的時(shí)候看得基本功。我認(rèn)為一個(gè)資深的測(cè)試專(zhuān)家一定是開(kāi)發(fā)高手，一個(gè)架構(gòu)師必須也是有長(zhǎng)期的開(kāi)發(fā)經(jīng)驗(yàn)，很多性能優(yōu)化是要從一行行代碼優(yōu)化起的。試想在一個(gè)被調(diào)用1000萬(wàn)次次每天的頁(yè)面，一行代碼如果每次都走到，每次少運(yùn)算1ns,也可以節(jié)省不少的電力。我為環(huán)保作貢獻(xiàn)，我驕傲。
網(wǎng)站架構(gòu)師需要對(duì)網(wǎng)絡(luò)環(huán)境有很好的知識(shí)理解。架構(gòu)問(wèn)題是需要考慮網(wǎng)絡(luò)部署。比如系統(tǒng)因不可用而發(fā)生切換的時(shí)候，從一個(gè)機(jī)房切到另一個(gè)機(jī)房，要考慮網(wǎng)站的服務(wù)對(duì)用戶(hù)訪(fǎng)問(wèn)速度上會(huì)有多大影響。這時(shí)候的技術(shù)方案可能是切DNS，也可能是切前端的跳轉(zhuǎn)機(jī)，或是底層部份服務(wù)調(diào)用到另一個(gè)機(jī)房。對(duì)于這類(lèi)切換的方案，架構(gòu)師需要計(jì)算網(wǎng)絡(luò)時(shí)間的開(kāi)銷(xiāo)帶來(lái)的QPS影響，和用戶(hù)體驗(yàn)上的延遲，每個(gè)請(qǐng)求估算需要精確到ms級(jí)。如果是全球范圍內(nèi)DNS切換，需要知道DNS刷新的時(shí)間經(jīng)驗(yàn)周期，比如：全球更新在1小時(shí)左右，而80%的地區(qū)用戶(hù)會(huì)在20分鐘內(nèi)刷新，這樣系統(tǒng)帶來(lái)的業(yè)務(wù)影響會(huì)有多大。
網(wǎng)站架構(gòu)師需要對(duì)網(wǎng)絡(luò)協(xié)議有深入的理解。HTTP協(xié)議是最基礎(chǔ)的，無(wú)論是SESSION還是COOKIE在HTTP協(xié)議基礎(chǔ)上怎么應(yīng)用，COOKIE的大小，數(shù)量，瀏覽器是怎么處理HTTP協(xié)議的。這些基礎(chǔ)有關(guān)鍵時(shí)候會(huì)影響業(yè)務(wù)的進(jìn)行。比如，SAFRI瀏覽器對(duì)第三方COOKIE是禁用的，某功能跨域?qū)?COOKIE的時(shí)候每次都會(huì)重新生成COOKIE，直接導(dǎo)致系統(tǒng)統(tǒng)計(jì)用戶(hù)UV的時(shí)候，數(shù)量增大，影響各種轉(zhuǎn)化率的計(jì)算。HTTP協(xié)議還需要考慮本身的連接管理池大小和連接是否KEEPALIVE，這些細(xì)節(jié)很多時(shí)候成為架構(gòu)上擴(kuò)展能力的瓶頸。一個(gè)靜態(tài)頁(yè)面服務(wù)的HTTP MAXCLIENT設(shè)置 為2500，機(jī)器只有10臺(tái)，很可能在一次中小型活動(dòng)中連接數(shù)到頂，用戶(hù)部份請(qǐng)求無(wú)法滿(mǎn)足。
架構(gòu)師需要考慮數(shù)據(jù)格式帶來(lái)的性能影響。很多遠(yuǎn)程系統(tǒng)調(diào)用走的是HTTP協(xié)議為基礎(chǔ)，數(shù)據(jù)格式為純文本或JSON，或XML等，這類(lèi)調(diào)用需要考慮數(shù)據(jù)的序列化和反序列化，這個(gè)工作是CPU開(kāi)銷(xiāo)型的，對(duì)性能優(yōu)化上需要有針對(duì)性。QPS高的系統(tǒng)RT一定會(huì)短，但RT短的系統(tǒng)不一定比RT高的系統(tǒng)能表現(xiàn)更好的 QPS。
架構(gòu)師需要有很好的數(shù)學(xué)能力，計(jì)算一個(gè)QPS里系統(tǒng)從網(wǎng)絡(luò)請(qǐng)求發(fā)出，到網(wǎng)絡(luò)的IO時(shí)間，DB的磁盤(pán)讀寫(xiě)時(shí)間，CPU運(yùn)算時(shí)間，再到數(shù)據(jù)庫(kù)連接數(shù)，數(shù)據(jù)分庫(kù)分表容量規(guī)劃，都需要有精確的計(jì)算。因?yàn)槿萘坑?jì)算不正確帶來(lái)問(wèn)題也是非常多的。比如一臺(tái)小機(jī)上ORACLE的連接數(shù)開(kāi)了2000個(gè)，而應(yīng)用系統(tǒng)由于不斷的擴(kuò)展，小業(yè)務(wù)系統(tǒng)不斷加入，大型促銷(xiāo)活動(dòng)前，臨時(shí)機(jī)器的不斷上線(xiàn)，很快就把DB連接數(shù)用完，引起業(yè)務(wù)部份不可用。架構(gòu)師需要去合理估算每種應(yīng)用的服務(wù)能力，以及他對(duì)DB等資源的合理連接數(shù)。
加構(gòu)師對(duì)JVM的內(nèi)存分區(qū)及管理策略要有深入的了解，GC的頻率可以發(fā)現(xiàn)很多系統(tǒng)容量的問(wèn)題。一個(gè)OLD區(qū)不斷加大的系統(tǒng)，伴隨YGC高頻發(fā)生，加上 TCP機(jī)器連接數(shù)很可能高，可能是要是機(jī)器了。一個(gè)業(yè)務(wù)功能不斷疊加的系統(tǒng)，很可能PERM區(qū)會(huì)需要加大設(shè)置，否則容易OUT OF MEMORY。
加構(gòu)師需要精讀《數(shù)據(jù)庫(kù)系統(tǒng)概念》這類(lèi)書(shū)，對(duì)不同DB的索引原理和庫(kù)表存儲(chǔ)結(jié)構(gòu)有了解，我們可以不是ORACLE ACE，但一定要聽(tīng)得懂ACE的DB架構(gòu)和性能優(yōu)化方面的建議。并且在原則上，前端用戶(hù)系統(tǒng)架構(gòu)上不要出現(xiàn)直連DB的設(shè)計(jì)，這是億級(jí)PV架構(gòu)的基礎(chǔ)設(shè)計(jì)保障，特別是一些營(yíng)銷(xiāo)類(lèi)功能系統(tǒng)，短時(shí)并發(fā)大的頁(yè)面不能有DB直連，一些小應(yīng)用可例外對(duì)待。
架構(gòu)師需要很好的學(xué)習(xí)能力，技術(shù)是不斷變化的，昨天用DUBBO，明天可能要換HSF；今天MEMCACHE，明天可能REDIS；今天剛剛把應(yīng)用拆分，明天可能就要合并。公司外的技術(shù)社區(qū)還不斷有一些好的開(kāi)源中間件和框架出來(lái)，需要不斷學(xué)習(xí)，關(guān)注。大網(wǎng)站的架構(gòu)模式不一定合適小網(wǎng)站，新中間件和框架實(shí)施需要考慮運(yùn)維成本和學(xué)習(xí)推廣成本，架構(gòu)上要選合適當(dāng)前階段的。架構(gòu)師需要和不同類(lèi)型的專(zhuān)業(yè)人才溝通，所以要能快速理解并學(xué)習(xí)不同專(zhuān)業(yè)的知識(shí)去補(bǔ)充自身的知識(shí)結(jié)構(gòu)不足。
架構(gòu)師需要理解業(yè)務(wù)，在一些業(yè)務(wù)系統(tǒng)型的網(wǎng)站，業(yè)務(wù)架構(gòu)師也顯得異常關(guān)鍵，比如像交易型系統(tǒng)，支付型系統(tǒng)。業(yè)務(wù)架構(gòu)師需要解決業(yè)務(wù)層次結(jié)構(gòu)，業(yè)務(wù)邊界劃分，業(yè)務(wù)優(yōu)先級(jí)與技術(shù)優(yōu)先級(jí)的平衡。傳統(tǒng)軟件的系統(tǒng)分析師不知道是否也干這角色？但互聯(lián)網(wǎng)的業(yè)務(wù)架構(gòu)師要求更高，應(yīng)該是建立在系統(tǒng)架構(gòu)師的基礎(chǔ)上再看高一層，通過(guò)業(yè)務(wù)和技術(shù)的綜合影響力去幫助網(wǎng)站取得合理的架構(gòu)，更好得拿到業(yè)務(wù)結(jié)果。
網(wǎng)站架構(gòu)師的知識(shí)結(jié)構(gòu)是寬又深的。
3：設(shè)計(jì)理念
每個(gè)架構(gòu)師都會(huì)有一些自已原設(shè)計(jì)理念和原則。我的基本思路是：架構(gòu)要作到至少1年的預(yù)見(jiàn)性（半年不叫預(yù)見(jiàn)性，因?yàn)榉桨笇?shí)施要半年）。設(shè)計(jì)的目標(biāo)是盡量讓系統(tǒng)可以水平擴(kuò)展，并利于。當(dāng)然，有些業(yè)務(wù)處在生存的邊緣，可能架構(gòu)方案只有幾個(gè)月的生命力。但一些成本不高收益穩(wěn)定的架構(gòu)理念，不管什么時(shí)候都是值得優(yōu)先考慮的。以下是架構(gòu)設(shè)計(jì)的一些常用手段。
1>：異步換同步：系統(tǒng)中的很多調(diào)用是可以異步化的，包括WEB界面上的AJAX異步，還有服務(wù)端的消息型異步；AJAX調(diào)用的應(yīng)用要注意把這種類(lèi)型的應(yīng)用集中到一個(gè)隔離的服務(wù)系統(tǒng)中，以方便在必要的時(shí)候進(jìn)行服務(wù)降級(jí)。
AJAX調(diào)用一般都是界面上非同步非強(qiáng)依賴(lài)的功能點(diǎn)；服務(wù)端異步的系統(tǒng)可以讓服務(wù)端的請(qǐng)求RT變短，提升服務(wù)器QPS，同時(shí)減少應(yīng)用強(qiáng)依賴(lài)。
一個(gè)小型系統(tǒng)（峰值萬(wàn)級(jí)消息per second）的服務(wù)端異步消息可以借助RMDB的表實(shí)現(xiàn)，當(dāng)網(wǎng)站規(guī)模變大時(shí)（峰值百萬(wàn)級(jí)消息每秒），消息系統(tǒng)需要有一個(gè)中間件，負(fù)責(zé)消息持久化及數(shù)據(jù) CRUD管理；再大點(diǎn)的時(shí)候，消息中間件的分布式與可用性會(huì)有更高要求，需要綜合使用多種架構(gòu)設(shè)計(jì)理念；
同步換異步對(duì)軟件工程上的好處是，可以把一個(gè)子系統(tǒng)的不同模塊分別由不同的人開(kāi)發(fā)維護(hù)，調(diào)試期間，兩個(gè)模塊也不會(huì)有很強(qiáng)的依賴(lài)。提高開(kāi)發(fā)并發(fā)性。
2>: 集中變分布：
一個(gè)網(wǎng)站小的時(shí)候，很多業(yè)務(wù)都會(huì)在一兩個(gè)應(yīng)用系統(tǒng)中實(shí)現(xiàn)。比如一個(gè)電子商務(wù)網(wǎng)站，從登錄，到首頁(yè)，到搜索，到產(chǎn)品DETAIL，到購(gòu)物車(chē)，下單支付，風(fēng)控，訂單管理，用戶(hù)中心到售后用戶(hù)糾紛流程。網(wǎng)站小的時(shí)候，這種一體化的業(yè)務(wù)架構(gòu)模式在網(wǎng)站規(guī)模小的時(shí)候，無(wú)論是研發(fā)團(tuán)隊(duì)規(guī)模還是硬件成本都是比較低的。這個(gè)時(shí)期的擴(kuò)展性一般只需要作到LB后面掛一片集群。服務(wù)器資源利用率這時(shí)候也是比較高的。
隨著業(yè)務(wù)規(guī)模擴(kuò)大，需要把系統(tǒng)獨(dú)立分拆出來(lái)，基本原則是：不同維護(hù)策略和服務(wù)等級(jí)的頁(yè)面和服務(wù) 不要放在一個(gè)應(yīng)用容器中，最好不要放在一個(gè)虛擬機(jī)或物理機(jī)上。發(fā)生過(guò)很多次緊急事件。因?yàn)榇罅髁宽?yè)面上帶著一個(gè)小的AJAX請(qǐng)求，把提供AJAX服務(wù)的 WEB應(yīng)用壓死。而這種AJAX應(yīng)用平時(shí)又是比較容易在容量評(píng)估的時(shí)候被忽略的。也比較難以管理AJAX，因?yàn)橐粋€(gè)前端開(kāi)發(fā)工程師很可能因?yàn)橐淮涡〉倪\(yùn)營(yíng)活動(dòng)加上一個(gè)調(diào)用。服務(wù)器端不同服務(wù)類(lèi)型的功能也需要分拆到不同服務(wù)中，服務(wù)的聚合一定要有一定的原則，并不斷的調(diào)整治理聚合服務(wù)內(nèi)容。如果把一個(gè)文件生成類(lèi)的業(yè)務(wù)功能（比如用戶(hù)批量導(dǎo)入導(dǎo)單）和一個(gè)下單的服務(wù)放在一起，很容易讓下單這類(lèi)核心主干邏輯功能受批量導(dǎo)出功能影響，當(dāng)架構(gòu)師需要作服務(wù)降級(jí)時(shí)，不得不侵入代碼層作服務(wù)功能的隔離。
架構(gòu)上的基礎(chǔ)設(shè)施也需要有隔離策略。比如一個(gè)功能先后需要完成讀數(shù)據(jù)，再生成文件，再發(fā)消息，再寫(xiě)數(shù)據(jù)庫(kù)，寫(xiě)CACHE，再把數(shù)據(jù)同步到另一個(gè)機(jī)房。這一串邏輯中，除了異步化策略之外，還需要考慮一些基礎(chǔ)職能的隔離，比如把生成文件的功能封裝成一個(gè)服務(wù)，文件存儲(chǔ)也需要從集中式變成分布式。T級(jí)可以考慮 NAS類(lèi)的集中式存儲(chǔ)方案，P級(jí)和Z級(jí)的文件容量一般是需要考慮分布式文件系統(tǒng)方案，開(kāi)源的也比較多。數(shù)據(jù)庫(kù)與從集中式變分布式是現(xiàn)在流行的方案，之前我們小網(wǎng)站的時(shí)候常用MASTER SLAVE，然后再大點(diǎn)搞雙MASTER寫(xiě)，多SLAVE讀；再大點(diǎn)流量或者應(yīng)用系統(tǒng)過(guò)多時(shí)，數(shù)據(jù)庫(kù)的連接數(shù)也會(huì)受到考驗(yàn)，這時(shí)候分布式的分庫(kù)分表方案是必須的。當(dāng)然對(duì)架構(gòu)師來(lái)講，如果能用上一種云方案，不需要業(yè)務(wù)架構(gòu)師考慮分庫(kù)分表方案，那會(huì)更有幸福感。同步系統(tǒng)也需要考慮集中變分布的策略，兩個(gè)機(jī)房或同一機(jī)房?jī)蓚€(gè)系統(tǒng)進(jìn)行數(shù)據(jù)鏡像同步，需要考慮多通道，分表，分字段，分庫(kù)進(jìn)行同步，有時(shí)候還需加入一些商業(yè)邏輯作為同步數(shù)據(jù)的判斷。非鏡像同步的時(shí)候，同步系統(tǒng)還需要考慮業(yè)務(wù)邏輯之間的事務(wù)特性。
#p#
3>: 架構(gòu)層次化：
早期網(wǎng)站一般是兩層架構(gòu)，應(yīng)用層+數(shù)據(jù)庫(kù)層；現(xiàn)在大型網(wǎng)站經(jīng)常采用三層架構(gòu)，應(yīng)用+服務(wù)中心+持久層，這三層分別在不斷的增強(qiáng)可用性和可擴(kuò)展性；理論上增強(qiáng)后的三層可以稱(chēng)為saas+ paas +iaas。
我把saas層看作現(xiàn)在淘寶開(kāi)放平臺(tái)上的第三方ISV應(yīng)用，獨(dú)立發(fā)展，互不影響，SAAS層數(shù)據(jù)隔離，運(yùn)維隔離。SAAS層還可以自建分布式CACHE，集中式CACHE或簡(jiǎn)單的本機(jī)CACHE。電子商務(wù)網(wǎng)站本身的系統(tǒng)也可以把這個(gè)當(dāng)成架構(gòu)設(shè)計(jì)的目標(biāo)之一，把自已的應(yīng)用層作成像第三方APP一樣的存在，這樣發(fā)展效率和擴(kuò)展性都會(huì)高很好。
paas層是我理解中的服務(wù)中心，具有應(yīng)用邏輯的一個(gè)業(yè)務(wù)層服務(wù)中心，比如UIC用戶(hù)中心，IC商品中心，TC交易中心等等 ，一般這樣的一個(gè)服務(wù)中心會(huì)被多個(gè)上層SAAS應(yīng)用所調(diào)用依賴(lài)。對(duì)一只被一個(gè)SAAS應(yīng)用依賴(lài)的服務(wù)中心是否值得建立，這個(gè)要看投入產(chǎn)出比，一般小網(wǎng)站可以直接讓?xiě)?yīng)用連著DB，而中型網(wǎng)站也可以考慮在一個(gè)應(yīng)用內(nèi)部分為兩層，先從JAR包層面隔離，PHP的話(huà)可以用代碼目錄結(jié)構(gòu)上來(lái)隔離。網(wǎng)站更大規(guī)模的時(shí)候，1：1的依賴(lài)也是值得建服務(wù)中心的，因?yàn)檫@樣可以隔離下面的持久層和上面的應(yīng)用層，并且可以在PAAS層隔離考慮緩存等職能，可以考慮在這一層實(shí)現(xiàn)流控，隔離對(duì)DB連接數(shù)量的依賴(lài)。PAAS層要盡量實(shí)現(xiàn)自已的水平擴(kuò)展，服務(wù)無(wú)狀態(tài)。
iaas層負(fù)責(zé)實(shí)現(xiàn)持久層，一般數(shù)據(jù)源都在這一層，常見(jiàn)網(wǎng)站的數(shù)據(jù)源不外呼這四種：RMDB（這個(gè)玩轉(zhuǎn)了近20年了），KV（最近10年比較熱，KV可以分為內(nèi)存型或持久型，對(duì)于持久型的KV，可以把數(shù)據(jù)掛到各類(lèi)存儲(chǔ)中），inverted index or file(倒排索引類(lèi)），F(xiàn)ILE SYSTEM（各類(lèi)傳統(tǒng)文件存儲(chǔ)或自已實(shí)施的小文件中間件，普通文件中間件）。
這三次之間是1：1：1的關(guān)系建立，還是N:1:1，或是N：N：N，都是需綜合考慮的。曾經(jīng)有一次，我在設(shè)計(jì)一個(gè)系統(tǒng)的時(shí)候，為應(yīng)用層界面設(shè)計(jì)了一個(gè)用戶(hù)列表的頭像顯示功能就引發(fā)了一個(gè)調(diào)用比例考慮不全的重大問(wèn)題。當(dāng)時(shí)，用戶(hù)有個(gè)旺旺的第三方游戲插件，插件主界面上有個(gè)好友列表，每個(gè)好友都有個(gè)頭像讀取的請(qǐng)求。假設(shè)用戶(hù)每天9點(diǎn)左右登錄旺旺的人中會(huì)有10%的人馬上去玩這個(gè)游戲，9點(diǎn)左右在線(xiàn)按100萬(wàn)人算，每個(gè)人的好友有平均50個(gè)，則每天9點(diǎn)左右用戶(hù)頭像URL的HTTP請(qǐng)求量會(huì)有50*10萬(wàn)，產(chǎn)生近500萬(wàn)個(gè)突發(fā)的HTTP請(qǐng)求。雖然有CDN，依然存在很大的頭像請(qǐng)求容量的不足，并且服務(wù)端獲取用戶(hù)好友列表信息的接口調(diào)用并發(fā)量也會(huì)很大，如果沒(méi)有提前對(duì)第三方應(yīng)用進(jìn)行接口調(diào)用限制和設(shè)計(jì)上的規(guī)范化，調(diào)用比例很可能帶來(lái)極大的系統(tǒng)傷害。
應(yīng)用層與服務(wù)層之間的調(diào)用與依賴(lài)會(huì)隨著網(wǎng)站規(guī)模變得越來(lái)越復(fù)雜，當(dāng)網(wǎng)站小的時(shí)候，這兩層直接的固定協(xié)議調(diào)用是可以接受的，調(diào)用方知道服務(wù)端的IP LIST，也知道調(diào)用的SOCKET，還有調(diào)用的協(xié)議；規(guī)模更大的時(shí)候，調(diào)用變成N：N的方式，隨然有層次，但已經(jīng)成網(wǎng)狀結(jié)構(gòu)，這時(shí)候需要服務(wù)治理與服務(wù)依賴(lài)的監(jiān)控，流控等基礎(chǔ)設(shè)施。對(duì)于服務(wù)治理，引入服務(wù)中間件，比如阿里的DUBBO和HSF是比較成熟的可以處理每天億級(jí)的服務(wù)調(diào)用量并作好配置維護(hù)，調(diào)用統(tǒng)計(jì)，分布式，名稱(chēng)服務(wù)，流控，路由等基礎(chǔ)職責(zé)，業(yè)界開(kāi)源的也有很多；服務(wù)層還需要處理異步消息調(diào)用與消息通知的機(jī)制，這時(shí)候需還要配全一些消息中間件。
4>: 功能分解化
網(wǎng)站的應(yīng)用級(jí)功能在網(wǎng)站小的時(shí)候一般都在一個(gè)物理機(jī)上，但在網(wǎng)站發(fā)展過(guò)程中，有些模塊經(jīng)常因業(yè)務(wù)原因發(fā)生變化和升級(jí)，有些模塊流量和調(diào)用量比較大，有些模塊處理的及時(shí)性和異步性要求不同，有些模塊與外部調(diào)用特別多；有些模塊經(jīng)常報(bào)異常，有些模塊IO多，有些模塊偏CPU計(jì)算型。不同的模塊需要隨網(wǎng)站規(guī)模發(fā)展進(jìn)展不斷的分解。
架構(gòu)師之道在于庖丁解牛一般的理解業(yè)務(wù)系統(tǒng)的復(fù)雜度和結(jié)構(gòu)關(guān)系，進(jìn)行合適的分解和聚合，這是我理解業(yè)務(wù)架構(gòu)的核心貢獻(xiàn)之一。一個(gè)業(yè)務(wù)架構(gòu)師首先是一個(gè)技術(shù)架構(gòu)師，沒(méi)有技術(shù)背景無(wú)法理解系統(tǒng)內(nèi)的技術(shù)邊界，沒(méi)有業(yè)務(wù)能理無(wú)法預(yù)見(jiàn)架構(gòu)變化的趨勢(shì)，也無(wú)法預(yù)見(jiàn)業(yè)務(wù)系統(tǒng)的流量變化。
5>:服務(wù)中心化
服務(wù)化有很多方式，三層網(wǎng)站架構(gòu)下，億級(jí)PV的網(wǎng)站最好能把同一業(yè)務(wù)邏輯被多方使用，邊界清楚的功能隔離出來(lái)作為服務(wù)。服務(wù)中心可以封裝對(duì)持久層的訪(fǎng)問(wèn)，形成帶有業(yè)務(wù)邏輯的一種原子性服務(wù)，加上一些事務(wù)性控制的多個(gè)原子服務(wù)。服務(wù)中心不要有界面，管理好服務(wù)的粒度，可用性，高并發(fā)下的性能，以及服務(wù)路由，監(jiān)控為主要任務(wù)。
6>:結(jié)點(diǎn)監(jiān)控化
億級(jí)PV網(wǎng)站的監(jiān)控是非常關(guān)鍵的，很多系統(tǒng)問(wèn)題，服務(wù)問(wèn)題，流量問(wèn)題，性能問(wèn)題，業(yè)務(wù)異動(dòng)都需要通過(guò)監(jiān)控來(lái)發(fā)現(xiàn)。監(jiān)控可以分為幾類(lèi)，一類(lèi)是快照型的，像搞活動(dòng)的時(shí)候特別需要一個(gè)大盤(pán)監(jiān)控。可以看全局的流量，交易量，訪(fǎng)客分布，來(lái)源分布，系統(tǒng)LOAD，DB連接數(shù)，CPU和網(wǎng)卡口子的狀態(tài)；一類(lèi)是基線(xiàn)型，可以看到每小時(shí)，分天同一個(gè)指標(biāo)的變化歷史。看到一個(gè)頁(yè)面響應(yīng)速度，服務(wù)器RT時(shí)間的變化；一類(lèi)是關(guān)鍵業(yè)務(wù)邏輯結(jié)點(diǎn)的按需統(tǒng)計(jì)，比如需要看一下某頁(yè)面改動(dòng)后某個(gè)頁(yè)面點(diǎn)擊量和原來(lái)的差別。
監(jiān)控會(huì)帶來(lái)系統(tǒng)的性能損失，特別是在線(xiàn)打點(diǎn)，不管你是在容器層面作的，還是在業(yè)務(wù)邏輯侵入方式實(shí)現(xiàn)的；另一種是通過(guò)日志分析，可能實(shí)時(shí)性差一些，比如有3 分鐘延遲；還有一類(lèi)是基于RMDB直連的分析，一般會(huì)在備庫(kù)上把數(shù)據(jù)導(dǎo)出來(lái)作分析，實(shí)時(shí)性好一些，但對(duì)備庫(kù)或主庫(kù)DB有壓力。還有一類(lèi)是基于消息的分析來(lái)實(shí)現(xiàn)監(jiān)控。讓一些關(guān)鍵結(jié)點(diǎn)有動(dòng)作時(shí)，發(fā)現(xiàn)異步消息到消息隊(duì)列上，然后監(jiān)控系統(tǒng)的抓取模塊和正常 業(yè)務(wù)邏輯一樣去訂閱消費(fèi)這些消息。這種方式需要監(jiān)控團(tuán)隊(duì)與業(yè)務(wù)邏輯有協(xié)同，這對(duì)長(zhǎng)期運(yùn)維有挑戰(zhàn)。
4：基礎(chǔ)架構(gòu)
億級(jí)網(wǎng)站的基礎(chǔ)架構(gòu)是較多時(shí)間投入的一個(gè)工作，小網(wǎng)站一般沒(méi)有中間件的概念，基礎(chǔ)架構(gòu)投入精力不多，但一樣可以運(yùn)行的很好。對(duì)于小網(wǎng)站，DB也像是一個(gè)中間件。一個(gè)億級(jí)PV的網(wǎng)站，要看PV，也要看UV。這兩個(gè)數(shù)字的規(guī)模對(duì)系統(tǒng)的技術(shù)架構(gòu)挑戰(zhàn)點(diǎn)是不同的。PV流過(guò)的系統(tǒng)和UV經(jīng)過(guò)的系統(tǒng)路徑不同，比例可能也有所不同。
架構(gòu)師需要分析這個(gè)路徑，好比庖丁解牛般的分析。在合適的節(jié)點(diǎn)引入中間件。比如一個(gè)億級(jí)商品量的系統(tǒng)，需要從商品的POST服務(wù)性能，圖片存儲(chǔ)空間，圖片縮圖處理服務(wù)，多語(yǔ)言商品信息翻譯，商品信息與圖片在不同系統(tǒng)之間同步的服務(wù)，圖片CDN服務(wù)，商品信息更新的通知和提醒服務(wù)，商品搜索服務(wù)，商品統(tǒng)計(jì)類(lèi)信息服務(wù)等不同階段和信息模塊的CRUD中引入中間件，讓系統(tǒng)可擴(kuò)展，可承受高并發(fā)。
在合適的時(shí)間點(diǎn)引入中間件提升架構(gòu)水平擴(kuò)展能力，只是關(guān)心可擴(kuò)展是不夠的?；A(chǔ)架構(gòu)不只是要關(guān)心系統(tǒng)的可擴(kuò)展能力，還需要關(guān)心可用性。系統(tǒng)達(dá)到億級(jí)PV 后，每停機(jī)1分鐘損失的流量都都是很大的。系統(tǒng)架構(gòu)師預(yù)見(jiàn)并規(guī)劃好系統(tǒng)容量。對(duì)于預(yù)料之外的超過(guò)容量的PV進(jìn)行服務(wù)降級(jí)，限流，針對(duì)系統(tǒng)不可用時(shí)提供組織保障機(jī)制，用提前制定的緊急響應(yīng)流程讓不可用時(shí)間盡可能變短，這也是很重要的架構(gòu)師職責(zé)。異地機(jī)房容災(zāi)或是同一機(jī)房的系統(tǒng)切換也應(yīng)該有定期不定期的演習(xí)。對(duì)于不同國(guó)家之間的機(jī)房災(zāi)備，系統(tǒng)必須考慮機(jī)房之間的調(diào)用延遲，國(guó)內(nèi)同步系統(tǒng)一般在10MS之內(nèi)的延遲是可以接受的，對(duì)于非同步系統(tǒng)，延遲可適當(dāng)放大，這種延遲的時(shí)間需要根據(jù)業(yè)務(wù)特性進(jìn)行評(píng)估。對(duì)于中美之間的200ms級(jí)別的延遲，系統(tǒng)需要有合理的評(píng)估，盡可能不要有中美服務(wù)同步調(diào)用。這個(gè)200ms的延遲來(lái)自網(wǎng)絡(luò)物理傳輸，來(lái)自路由器路由算法的延遲，也有來(lái)自機(jī)房本地的信息號(hào)交換過(guò)程，是剛性的，很多大型電商網(wǎng)站都面臨這一問(wèn)題的挑戰(zhàn)。EBAY， AMAZON，alibaba和GOOGLE這類(lèi)的網(wǎng)站架構(gòu)設(shè)計(jì)時(shí)，一定會(huì)有很多系統(tǒng)不得不討論這一延遲帶來(lái)的系統(tǒng)方案區(qū)別。有時(shí)候網(wǎng)站會(huì)因業(yè)務(wù)原因考慮建完全獨(dú)立分站，有時(shí)候會(huì)灰這種架構(gòu)問(wèn)題的影響考慮作單寫(xiě)還是雙寫(xiě)。如果是全球機(jī)房，則這一問(wèn)題會(huì)變得更復(fù)雜。數(shù)據(jù)同步和分發(fā)會(huì)是一個(gè)關(guān)鍵的中間件和可用性設(shè)施。
性能是大規(guī)模網(wǎng)站的重要基礎(chǔ)架構(gòu)問(wèn)題。網(wǎng)站應(yīng)用層，我們關(guān)心系統(tǒng)的關(guān)鍵頁(yè)面的QPS值，比如在100并發(fā)下，系統(tǒng)某頁(yè)面能接受每秒幾次正常調(diào)用；綜合頁(yè)面的QPS也是需要關(guān)注的，特別是當(dāng)一個(gè)前臺(tái)應(yīng)用內(nèi)的界面比較多的時(shí)候。WEB應(yīng)用的QPS可以通過(guò)服務(wù)端日志中的COOKIE來(lái)回放，進(jìn)行線(xiàn)上線(xiàn)下的壓測(cè)來(lái)取得一個(gè)有信心的數(shù)字。前臺(tái)的WEB應(yīng)用原則上不要有直接的DB層訪(fǎng)問(wèn)，小規(guī)模網(wǎng)站者需要平衡投入產(chǎn)出比，有時(shí)候作一些TRADE OFF也是值得的。對(duì)于服務(wù)層的應(yīng)用，一般關(guān)心TPS，因?yàn)檎{(diào)用都來(lái)自WEB應(yīng)用系統(tǒng)，所以通過(guò)COOKIE回放這種調(diào)用是不可能。持久層的TPS和上兩層的QPS，TPS量之間存在一個(gè)比例。多個(gè)數(shù)據(jù)庫(kù)的TPS可能對(duì)應(yīng)一個(gè)服務(wù)層的一個(gè)TPS。這對(duì)于系統(tǒng)的容量和機(jī)器的擴(kuò)容估主也非常關(guān)鍵，需要維護(hù)這么一個(gè)狀態(tài)的快照。架構(gòu)師才能讓這個(gè)狀態(tài)時(shí)刻保持胸有成竹。發(fā)現(xiàn)關(guān)鍵資源瓶頸對(duì)于分析QPS和TPS是非常 關(guān)鍵的。
服務(wù)治理除了作抽應(yīng)用層服務(wù)中心的工作和JAR包之間的依賴(lài)管理之外，服務(wù)強(qiáng)弱依賴(lài)也是需要有一個(gè)系統(tǒng)來(lái)監(jiān)控和管理的。隨時(shí)知道一個(gè)新上的系統(tǒng)在依賴(lài)哪個(gè)服務(wù)，或被哪個(gè)應(yīng)用依賴(lài)，這是架構(gòu)師工作的必要工具。架構(gòu)師從輸出經(jīng)驗(yàn)，到提供工具平臺(tái)，是一個(gè)必然的過(guò)程。小網(wǎng)站需要一個(gè)架構(gòu)師的經(jīng)驗(yàn)快速搭建，大規(guī)模網(wǎng)站則不可能靠一個(gè)人的經(jīng)驗(yàn)來(lái)進(jìn)行判斷，需要更多的數(shù)據(jù)采集和分析生成規(guī)則。監(jiān)控系統(tǒng)是一個(gè)網(wǎng)站健康狀態(tài)的指示儀。
部署架構(gòu)是網(wǎng)站進(jìn)入10億級(jí)規(guī)劃，99.99%可用性要求下必然關(guān)注的問(wèn)題。無(wú)論是EBAY還是AMAZON都在部署上有很多投入。單一的機(jī)房由于電力，機(jī)柜等問(wèn)題，經(jīng)常出現(xiàn)部署上的硬件約束；容災(zāi)與不同地區(qū)訪(fǎng)問(wèn)體驗(yàn)要求異地機(jī)房能提供在線(xiàn)同時(shí)的服務(wù)。部署上需要考慮是全機(jī)房的對(duì)稱(chēng)部署，或是應(yīng)用不同分級(jí)的分區(qū)部署。比如持久層統(tǒng)一，服務(wù)層與應(yīng)用層多機(jī)房對(duì)稱(chēng)部署；或是持久層與應(yīng)用層服務(wù)層完全對(duì)稱(chēng)，但數(shù)據(jù)分區(qū)；這種分區(qū)需要考慮買(mǎi)家維度、賣(mài)家維度，或是 IP區(qū)域分區(qū)，不同區(qū)生成的數(shù)據(jù)通過(guò)同步系統(tǒng)實(shí)現(xiàn)各區(qū)的最終一致。以訂單為例，分區(qū)是可以讓美國(guó)買(mǎi)家創(chuàng)新的訂單寫(xiě)在美國(guó)分區(qū)數(shù)據(jù)持久層，然后異步消息生成同步任務(wù)，數(shù)據(jù)同步到賣(mài)家所在的分區(qū)。
基礎(chǔ)架構(gòu)的工作還有很多，架構(gòu)師責(zé)無(wú)龐待。if not me, who?
5：軟件工程
架構(gòu)師除了作經(jīng)驗(yàn)，工具和代碼輸出之外，還需要關(guān)注工作機(jī)制的建立和人員的傳幫帶。發(fā)布流程，可重復(fù)使用的灰度發(fā)布ABtest方案，代碼管理規(guī)范，代碼開(kāi)發(fā)規(guī)范，人員梯隊(duì)，業(yè)務(wù)優(yōu)先級(jí)判斷，中間件和平臺(tái)化工作推進(jìn)都是每一天的日常工作。有時(shí)候幫測(cè)式工程師去搭好并維護(hù)一套測(cè)試環(huán)境，也算是本職工作。
有些架構(gòu)師被稱(chēng)為PM型架構(gòu)師，也有被感覺(jué)像RA型的，偏咨詢(xún)師型的架構(gòu)，偏業(yè)務(wù)型的，偏算法型的，偏性能調(diào)優(yōu)的，偏中間件和服務(wù)治理的，偏基礎(chǔ)架構(gòu)型的，這個(gè)是看網(wǎng)站發(fā)展階段的需要，缺什么，作什么。關(guān)鍵是看架構(gòu)在軟件工程過(guò)程中對(duì)產(chǎn)品，對(duì)團(tuán)隊(duì)的輸出是否能解決問(wèn)題，拿到結(jié)果！eat what, what strong。
6：不同類(lèi)型業(yè)務(wù)系統(tǒng)技術(shù)架構(gòu)的差異化
每個(gè)網(wǎng)站架構(gòu)都有不同，完全復(fù)制是不科學(xué)的。哪怕現(xiàn)在想再作一個(gè)淘寶網(wǎng)，光靠把淘寶全部幾萬(wàn)臺(tái)機(jī)器搬去是不行的，搭不出一個(gè)淘寶網(wǎng)。完全復(fù)制淘寶網(wǎng)的建設(shè)過(guò)程也不是靠譜的?？梢詮?fù)制或參考的是架構(gòu)的原則和經(jīng)驗(yàn)教訓(xùn)。不同類(lèi)型的業(yè)務(wù)系統(tǒng)有不同的業(yè)務(wù)發(fā)展過(guò)程，業(yè)務(wù)架構(gòu)發(fā)展演變過(guò)程不同；技術(shù)架構(gòu)發(fā)展過(guò)程也不同，技術(shù)解決問(wèn)題的重點(diǎn)不同，有些網(wǎng)站一開(kāi)始需要解決的問(wèn)題是如何從一個(gè)老網(wǎng)站中改版和分拆，有些則是全新的搭建。有些網(wǎng)站自建物流系統(tǒng)，有些則是與多家物流第三方對(duì)接系統(tǒng)。比如：有些網(wǎng)站交易模式簡(jiǎn)單，有些則需要去支持各種不同交易模式，像多次付款，預(yù)售，批發(fā)，團(tuán)批，階梯價(jià)格。。有些網(wǎng)站只需要解決支付 寶對(duì)接，有些則自建網(wǎng)銀與支付系統(tǒng)，風(fēng)控系統(tǒng)。
架構(gòu)師要小心經(jīng)驗(yàn)的慣性。大網(wǎng)站的方法不一定合適小網(wǎng)站。小網(wǎng)站的格局也不可能適用大規(guī)模。時(shí)代在變，地點(diǎn)在變，因時(shí)制宜，因地制宜。
7:小趨勢(shì)的生命力
開(kāi)放平臺(tái)是胸懷: 06年，我們都談開(kāi)放平以。其實(shí)這個(gè)理念最初考驗(yàn)的是網(wǎng)站擁有者的胸懷。你是否愿意讓其它人進(jìn)來(lái)操作你的數(shù)據(jù)，是否愿意看到別人作出比你理好的應(yīng)用層系統(tǒng)？甚至是一些服務(wù)層的系統(tǒng)？
FB與微博是社會(huì)化：07年，我們都講SNS。SNS無(wú)處不在，因?yàn)樗举|(zhì)上是一個(gè)社會(huì)化的思路下的技術(shù)系統(tǒng)表示。愿意接受UGC，能否以社會(huì)化的方式讓系統(tǒng)內(nèi)的數(shù)據(jù)產(chǎn)生和管理發(fā)生。原意為這些社會(huì)化的小數(shù)據(jù)作系統(tǒng)，才可以最終生成大數(shù)據(jù)的擁有者。
電商團(tuán)購(gòu)是心理：09年，GROUPON火了，大家都團(tuán)購(gòu)。團(tuán)購(gòu)本身是沒(méi)有什么技術(shù)創(chuàng)新的。有人說(shuō)O2O是他的模式創(chuàng)新，可是，難道在原來(lái)的C2C網(wǎng)上不能實(shí)現(xiàn)嗎？就像超市里把促銷(xiāo)的商品放在貨架邊上的花車(chē)上，和放在貨架里有本質(zhì)區(qū)別嗎？區(qū)別在于心理，用戶(hù)體驗(yàn)上的區(qū)別。有時(shí)候這也會(huì)是一種竟?fàn)幜?，是一種常態(tài)化的經(jīng)營(yíng)思路，但不會(huì)主流。
移動(dòng)PC平板是體驗(yàn)：10年，平板熱。這種比手機(jī)屏大，比筆記本屏小的東西，滿(mǎn)足了某些場(chǎng)景的方便性需求，體驗(yàn)創(chuàng)新很有機(jī)會(huì)。
Pinterest電商導(dǎo)購(gòu)是基尼：11年，導(dǎo)購(gòu)網(wǎng)站火了。瀑布流熱了，國(guó)內(nèi)的蘑菇街，美麗說(shuō)火了。從根本上來(lái)看，導(dǎo)購(gòu)是解決 了網(wǎng)站商品與用戶(hù)流量之間的基尼關(guān)系，把基尼指數(shù)變得更小一些。否則80%的流量一直放在20%的熱門(mén)商品和大賣(mài)家的店里，市場(chǎng)規(guī)模會(huì)有影響。作生態(tài)圈好一些，有活路的人多了，市場(chǎng) 才穩(wěn)定。
外貿(mào)電商是庫(kù)存：12年，外貿(mào)電商預(yù)熱了，GOOGLE TRENDS里顯示，才作兩年的ALIEXPRESS的指數(shù)超過(guò)了DHGATE這個(gè)作了五六年跨境電商B2B網(wǎng)站，也越來(lái)越接近ALIBABA。COM這個(gè)老牌SOURCING網(wǎng)站。外貿(mào)從批發(fā)變小單是什么背景？我想本質(zhì)上他的銷(xiāo)售鏈變了。MIC基本還沒(méi)變，沒(méi)有變成快速反應(yīng)能力的供應(yīng)商，但出品商變成了擁有小單外貿(mào)客服能力的80后；進(jìn)口商變成了國(guó)外的RETAILER，國(guó)外的超市變成了最終消費(fèi)者。
體感外設(shè)是物聯(lián)：13年，各類(lèi)體感設(shè)備越來(lái)越豐富。什么手勢(shì)，什么隨身拍，什么位置設(shè)備，拍照設(shè)備。好玩。按馬斯少理論來(lái)講，工作是生存需求，買(mǎi)房子是安全需求，買(mǎi)車(chē)和大房子是社交需求，體現(xiàn)在的單位和職位是尊重需求，買(mǎi)體感設(shè)備，那是自我實(shí)現(xiàn)。
BARABASI預(yù)見(jiàn)了末來(lái)，小趨勢(shì)改變末來(lái)的本質(zhì)是一種叫冪律的無(wú)形之手，像我們所熟知的長(zhǎng)尾。據(jù)說(shuō)人類(lèi)行為90%是可以預(yù)測(cè)的，人類(lèi)的90%的形為是可以采集的。架構(gòu)師從不同觀察者的角度理解他們的觀點(diǎn)有時(shí)候會(huì)有更多的預(yù)見(jiàn)性。
8：LAST BUT NOT THE LEAST
作網(wǎng)站如作人。架構(gòu)的是人的骨架，人還需要配一個(gè)好的心態(tài)：心胸+態(tài)度。心胸是裝進(jìn)不同聲音采集到信息的基礎(chǔ)，態(tài)度是推廣服務(wù)他人的手段。一個(gè)新架構(gòu)方案下去，一定會(huì)有反對(duì)的聲音。如何去說(shuō)服別人現(xiàn)在就啟動(dòng)架構(gòu)升級(jí)或轉(zhuǎn)型方案，是需要帶著心態(tài)去的。畢竟一個(gè)大的架構(gòu)方案是需要很多人一起努力才能拿到結(jié)果，不是一兩個(gè)英雄人物能造就的。架構(gòu)師的工作方式是主動(dòng)的，而不是問(wèn)題驅(qū)動(dòng)的。能解決問(wèn)題的架構(gòu)師是牛B的，能預(yù)見(jiàn)問(wèn)題或提前準(zhǔn)備的架構(gòu)師是稱(chēng)職的，這才是技術(shù)促進(jìn)業(yè)務(wù)。
沒(méi)圖片寫(xiě)貼子就是比較快？不過(guò)讀起來(lái)是會(huì)費(fèi)點(diǎn)眼力。
