【正文】 們以后努力解決的問題。交易系統(tǒng)會與很多其它的業(yè)務系統(tǒng)交互，如果在一次交易過程中采用同步調(diào)用的話，這就要求要向交易成功，必須依賴的所有系統(tǒng)都可用，而如果采用異步通信以后，交易系統(tǒng)借助于消息中間件 Notify 和其它的系統(tǒng)進行了解耦，這樣以來當其它的系統(tǒng)不可用的時候，也 不會影響到某此交易，從而提高了系統(tǒng)的可用性。當訂單和分庫分表相遇，會有什么火花迸發(fā)出來？ 09年初碰撞了很久，結果產(chǎn)生的火花很小。 上面的兩個例子都是對人的關注缺失，技術人員做系統(tǒng)，大部分都更關注技術，而忽視技術的創(chuàng)造者和使用者 —— 人。 上圖是大家都十分熟悉的淘寶登錄頁面，填入相應信息后，點擊登錄按鈕，這個動作就是 action。 ：日志系統(tǒng)配置文件。 第 18 頁 . pipeline 與 valve 項目組在 MVC 這塊會轉(zhuǎn)向使用公司內(nèi)部 web 框架 webx3，今日讀了讀它的源代碼，做一定源碼和架構的解析。amp。 exit / /otherwise /choose ! 假如 ()被設置，則循環(huán)，否則退出循環(huán)。 } catch (SkipModuleExecutionException e) { if (skippable) { (: {}, {}, fastMethod, tMessage())。 groupInstanceKey = trimToNull(())。 WEB 層開發(fā)規(guī)范 作用和目的： web 層是直接和用戶交互的，包括界面展示，提交數(shù)據(jù)的處理，數(shù)據(jù)的獲取等功能塊；需開發(fā)的組件：在 web 層中，常見的有 Screen、 Control、 Action 這三類 web 端組件需要開發(fā)，他們的職責只限于 web 端，比如提交組據(jù)的驗證，調(diào)用 biz 層程序來處理業(yè)務邏輯，并提供模板渲染需要的數(shù)據(jù)等。 import 。 } } 在構造函數(shù)里通過 Annotation 得到 groupName 和 fieldName，在 resolve 方法里，通過request 組裝成 form 對象，再通過 groupName 和 fieldName 取到相應的 Field。 webx 是通過一個個 DataResolver 來完成對各種參數(shù)的解析和注入， DataResolver 的源碼如下： public interface DataResolver{Object resolve()。 for (int i = 0。 checkCsrfToken / ! 檢查頁面的授權，如果當前用戶無權訪問該頁面，則跳轉(zhuǎn)到 petstoreLogin 頁面 webx2valve class=e / loop choose when ! 執(zhí)行帶模板的 screen，默認有 layout。 } catch (PipelineException e) { throw e。根據(jù) webx 默認的映射規(guī)則， / 被轉(zhuǎn)換成 /。 ：這幾乎是每一個 web 項目都會有的配置文件，在 webx 框架下，只定義了一個核心的 servlet： WebxController ：每個 webx 應用，都需要有一個 配置文件。 一般基本 web 應用的層次是這樣的，如下圖 Apache公司有個開源項目 Cactus，是專門針對上面的 Servlet來做接口測試的一個框架。上線后發(fā)現(xiàn)一個非常痛苦的問題，無法和 SQL 對應，排錯非常難。當一個網(wǎng)站從百萬、千萬記錄的數(shù)據(jù)規(guī)模，增長到億、十億、幾十億記錄的數(shù)據(jù)規(guī)模時，是一個量變到質(zhì)變的過程，單純的硬件升級已經(jīng)達到了瓶頸，而需要在整體結構上做文章。 說到異步通信，我們需要關注的一點是這里的異步一定是根據(jù)業(yè)務特點來的，一定是針對業(yè) 務的異步，通常適合異步的場合是一些松耦合的通信場合，而對于本身業(yè)務上關聯(lián)度比較大的業(yè)務系統(tǒng)之間，我們還是要采用同步通信比較靠譜。 既然明白了拆分的重要性，我們看看隨著公司的發(fā)展，公司本身是如何拆分系統(tǒng)的。 除了公司目前的 session 框架的實現(xiàn)方式以外，其實集中式 session 管理來完成，說具體點就是多個無狀態(tài)的應用節(jié)點連接一個 session 服務器 ， session 服務器將 session 保存到緩存中， session 服務器后端再配有底層持久性數(shù)據(jù)源，比如數(shù)據(jù)庫，文件系統(tǒng)等等。軟件本身的發(fā)展應該是不會成為問題的，不太會出現(xiàn)軟件突然停止發(fā)展的情況。我告訴他說不是的。 而微軟的 IIS，就只能工作在 Windows 的系統(tǒng)上了。那么我們要選擇一款實現(xiàn)了 JEE 規(guī)范的應用服務器。 對于規(guī)模稍大的網(wǎng)站來說，其 IT 必然是一個服務器集群來提供網(wǎng)站服務，數(shù)據(jù)庫也必然要和應用服務分開，有單獨的數(shù)據(jù)庫服務器。如果不準備采用微軟的一系列產(chǎn)品構建應用，并且有能力維護 Linux 或者 FreeBSD，再加上成本的考慮，那么還是應該在 Linux 和 FreeBSD之間進行選擇。這邊就 不在贅述?？梢赃@么說，在關系數(shù)據(jù)庫管理系統(tǒng)的選擇上，可以考慮應用本身的情況來決定。這對于應用設計、開發(fā)、查錯、優(yōu)化都是非常有幫助的。 . 高性能可伸縮 . 應用無狀態(tài) 一個系統(tǒng)的伸縮性的好壞取決于應用的狀態(tài)如何管理。 系統(tǒng)剛上線初期，用戶數(shù)并不多，所有的邏輯也許都是放在一個系統(tǒng)中的，所有邏輯跑到一個進程或者一個應用當中，這個時候因為比較用戶少，系統(tǒng)訪問量低，因此將全部的邏輯都放在一個應用未嘗不可。此時，咱們搞技術的哥們，就去看看究竟是啥原因，我們查了查以后，發(fā)現(xiàn)原來是數(shù)據(jù)庫讀取壓力太大了，此時咱們都清楚是到了讀寫分離的時候，這個時候我們會配置一個 server 為 master節(jié)點，然后配幾個 salve 節(jié)點，這樣以來通過讀寫分離，使得讀取數(shù)據(jù)的壓力分攤到了不同的 salve 節(jié)點上面，系統(tǒng)終于又恢復了正常，開始正常運行了。 . 監(jiān)控、預警系統(tǒng) 對于大型的系統(tǒng)來說，唯一可靠的就是系統(tǒng)的各個部分是不可靠。 另外一個有意思的案例是商品的數(shù)據(jù)擴容，商品的水平分割非 常容易，按照賣家進行拆分即可。），否則還是要多關注系統(tǒng)和人的交互。 淘寶的一個系統(tǒng)一般會有多個子工程，有個工程是 web 的，我們要做的接口測試就是在src/main/java/… /module 下 面，有 action 與 screen。 Screen 和 control 都可以有 java 類來驅(qū)動，但不是必須的， 第 17 頁 也就是說可以先寫模板，后寫類，也可以只寫模板，不用構造對應類。 if (broken) { return。使得下一個 valve 能得力執(zhí)行，以上代碼細節(jié)無需太多解析，思路與 j2ee的 filter 和 webwork 的 interceptor 如出一轍 。 透過細節(jié)看本質(zhì)， webx3 在這兩塊的架構核心可以歸結為以下幾個點 。amp。 boolean valid = ()。 import 。 import 。 return field。 } args[i] = value。 webx 要達到的效果是開發(fā)者開發(fā)的 Action和 Screen 是簡單無累贅的 POJO，類似于 webwork。 prepareForTurbine / ! 預備 webx 所需的對象。 if (executingIndex = executedIndex) { throw new IllegalStateException(descCurrentValve() + has already been invoked: + valves[executingIndex])。 分析 URL 的成分，取得 target： / 具體過稱如下： 1） fuwuxian 稱為 Context Path。如圖： 其中 ，有個目錄是主要的 。幾乎所有的框架都會說自己的擴展性多高，性能多好，而很少會提到監(jiān)控有多強、排錯有多容易，很少提到在故障時怎么做隔離，怎么做降級；從這個角度看，商用的產(chǎn)品確實做得好很多；關于性能相關的文章搜索一下，很多，各種優(yōu)化策略，各種優(yōu)化方法，而可用性方面，找到的系統(tǒng)性的知識真的很少；希望是我了解的不多。開始實施后一段時間，又仔細回想了一下商品的整體需求，突然發(fā)現(xiàn)商品其實不需要和訂單同等的要求，一定要采用高成本的主數(shù)據(jù)庫嗎？ 全部采用低成本的普通服務器來做數(shù)據(jù)庫是否可行？經(jīng)過仔細的評估，發(fā)現(xiàn)是可以接受的，而這樣就導致之前已經(jīng)啟動的商品讀寫分離項目的一部分工作白做了！ 故事講完了總是要有點總結，來點虛的先：對于原始需求的清晰了解是系統(tǒng)決策的前提，否則彎路肯定要走，而對原始需求的了解并不容易，中間會有很多干擾和阻力，前面的實例看 起來很簡單，但是在一個運行了 5 年的系統(tǒng)上來了解本質(zhì)，來進行變更，并沒那么容易。因此一個監(jiān)控系統(tǒng)就變得必不可少了。但是是不是這樣，我們就可以高枕無憂了呢？ NO,這個 NO，不是我說的，是前輩們通過經(jīng)驗總結出來的，隨著用戶量的不斷增加，你會發(fā)現(xiàn)系統(tǒng)中的某些表會變的異常龐大，比如好友關系 表，店鋪的參數(shù)配置表等，這個時候 無論是寫入還是讀取這些表的數(shù)據(jù)，對數(shù)據(jù)庫來說都是一個很耗費精力的事情，因此此時就需要我們進行 “ 水平分區(qū) ” 了（這就是俗話說的分表，或者說 sharding） 。那么這個時候我們?nèi)绾谓鉀Q這 些問題呢？明智的辦法就是拆分（這也算是一種解耦），我們需要將原來的系統(tǒng)根據(jù)一定的標準，比如業(yè)務相關性等分為不同的子系統(tǒng)，不同的系統(tǒng)負責不同的功能，這樣切分以后，我們可以對單獨的子系統(tǒng)進行擴展和維護，從而提高系統(tǒng)的擴展性和可維護性，同時我們系統(tǒng)的水平伸縮性 scale out 大大的提升了，因為我們可以有針對性的對壓力大的子系統(tǒng)進行水平擴展而不會影響到其它的子系統(tǒng)，而不會像拆分以前，每次系統(tǒng)壓力變大的時候，我們都 需要對整 個大系統(tǒng) 第 6 頁 進行伸縮，而這樣的成本是比較大的，另外經(jīng)過切分，子系統(tǒng)與子系統(tǒng)之間的耦合減低了，當 某個子系統(tǒng)暫時不可用的時候，整體系統(tǒng)還是可用的，從而整體系統(tǒng)的可用性也大大增強了。 上面說了無狀態(tài)的重要性，那么具體如何實現(xiàn)無狀態(tài)呢？此時一個 session 框架就會發(fā)揮作用了。對于質(zhì)量的問題 ，我想現(xiàn)在很多的開源軟件尤其是一些很著名的開源軟件都有很完善的組織，有完善的開發(fā)、測試、發(fā)布流程。在淘寶網(wǎng)，這些系統(tǒng)都是自主開發(fā)的，沒有采用目前商業(yè)的或者開源的產(chǎn)品。幾年前， Apache 幾乎是 Linux 系統(tǒng)上開源 Web Server 的唯一選擇。那么在選擇的時候有一個因素就是企業(yè)的技術人員對于哪種系統(tǒng)更加的熟悉，這個熟悉一方面是系統(tǒng)管理方面，另外一方面是對于內(nèi)核的熟悉，對內(nèi)核的熟悉對于性能調(diào)優(yōu)和對 操作系統(tǒng)進行定制剪裁會有很大的幫助。那么對于淘寶網(wǎng)這樣大規(guī)模的一個網(wǎng)站，整個網(wǎng)站都采用了什么樣的技術、產(chǎn)品和架構，是否采用了開源的軟件或者是完全采用的商業(yè)軟件。淘寶網(wǎng)有很多業(yè)務系統(tǒng)應用是基于 JEE 規(guī)范的系統(tǒng)。 Lighty 是一個非常輕量級、占用內(nèi)存資源也比較少的 Web Server。 前面談的都是系統(tǒng)級的產(chǎn)品，下面我們說說開發(fā)框架的使用。并且因為代碼公開，反而更加的容易發(fā)現(xiàn)錯誤，提高質(zhì)量。但是采用客戶端 cookie 的方式來保存狀態(tài)也會遇到限制，比如每個 cookie 一般不能超過 4K的大小，同時很多瀏覽器都限制一個站點最多保存 20個 cookie。既然需要通信，這個時候一個高性能的遠程調(diào)用框架就顯得非?？傄玻虼嗽蹅児疽灿辛俗约旱?HSF 框架。 . 異步通信 在 “ 遠程調(diào)用框架 ” 的介紹中 ， 我們說了一個大型的系統(tǒng)為了擴展性和伸縮性方面的需求 ， 肯定是要進行拆分 ， 但是拆分了以后 ， 子系統(tǒng)之間如何通信就成了我們首要的問題 ， 在“ 遠程調(diào)用框架 ” 小節(jié)中 ， 我們說了同步通信在一個大型分布式系統(tǒng)中的應用 ， 那么這一小節(jié)我們就來說說異步通信 。另外很多時候集群中的很多系統(tǒng)的配置都是一樣的，如果不進行統(tǒng)一的配置管理，就需要 在 所有的系統(tǒng)上維護一份配置，這樣會造成配置的管理維護很麻煩，而通過一個統(tǒng)一的配置管理可以使得這些問題得到很好的解決，當有新的節(jié)點加入或者刪 除的時候，配置管理系統(tǒng)可以通知各個節(jié)點更新配置，從而達到所有節(jié)點的配置一致性，這樣既方便也不會出錯。 再來點稍微實際一點的，對于大型分布式系統(tǒng)的數(shù)據(jù)訪問，一個統(tǒng)一的數(shù)據(jù)層是非常必要的，封裝水平、垂直的數(shù)據(jù)分割，封裝讀寫分離，封裝數(shù)據(jù)訪問的路由、復制、合并、搬遷、熱點處理等功能，并且要對應用透明，應用針對性的，可以在 JDBC 層面包裝，數(shù)據(jù)庫針對性的，可以在數(shù)據(jù)庫協(xié)議層包裝，比如 Amoeba。 Webx 頁面使用了 velocity 模板， WEB 層使用的是 WEBX 框架里面的 TemplateAction,TemplateScreen,AbstractModule,TemplateControl，解決了操作和頁面的跳轉(zhuǎn)。除了標準的 以外，還有了 、 pi 和 等幾個文件。在 中把 *.htm 映射到 Webx Controlle