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