【正文】 體應(yīng)用。因此一個(gè)監(jiān)控系統(tǒng)就變得必不可少了。對(duì)于數(shù)據(jù)的擴(kuò)展性來講，最傳統(tǒng)也是最簡(jiǎn)單有效的模式是數(shù)據(jù)庫的 分庫分表。開始實(shí)施后一段時(shí)間，又仔細(xì)回想了一下商品的整體需求，突然發(fā)現(xiàn)商品其實(shí)不需要和訂單同等的要求，一定要采用高成本的主數(shù)據(jù)庫嗎？ 全部采用低成本的普通服務(wù)器來做數(shù)據(jù)庫是否可行？經(jīng)過仔細(xì)的評(píng)估，發(fā)現(xiàn)是可以接受的，而這樣就導(dǎo)致之前已經(jīng)啟動(dòng)的商品讀寫分離項(xiàng)目的一部分工作白做了！ 故事講完了總是要有點(diǎn)總結(jié)，來點(diǎn)虛的先：對(duì)于原始需求的清晰了解是系統(tǒng)決策的前提，否則彎路肯定要走，而對(duì)原始需求的了解并不容易，中間會(huì)有很多干擾和阻力，前面的實(shí)例看 起來很簡(jiǎn)單，但是在一個(gè)運(yùn)行了 5 年的系統(tǒng)上來了解本質(zhì)，來進(jìn)行變更，并沒那么容易。究其根本，是對(duì)人的關(guān)注不夠，缺少的產(chǎn)品化的服務(wù)運(yùn)維，缺少服務(wù)治理。幾乎所有的框架都會(huì)說自己的擴(kuò)展性多高，性能多好，而很少會(huì)提到監(jiān)控有多強(qiáng)、排錯(cuò)有多容易，很少提到在故障時(shí)怎么做隔離，怎么做降級(jí)；從這個(gè)角度看，商用的產(chǎn)品確實(shí)做得好很多；關(guān)于性能相關(guān)的文章搜索一下，很多，各種優(yōu)化策略，各種優(yōu)化方法，而可用性方面，找到的系統(tǒng)性的知識(shí)真的很少；希望是我了解的不多。 第 14 頁 頁頭 Head、 菜單 Menu、 頁腳 Foot，這些通常是變化不大的，都可以做成 control 小控件； 頁中 Middle，這塊通常是變化比較大的，可以做成 screen。如圖： 其中 ，有個(gè)目錄是主要的 。可以看做 webx 框架的總控文件。 分析 URL 的成分，取得 target： / 具體過稱如下： 1） fuwuxian 稱為 Context Path。 1）如果存在 layout 布局，則渲染 layout，執(zhí)行 screen 類，并渲染 screen 模板 2）根據(jù) target 查找 layout 模板 渲染 layout 模板 渲染在 layout 模板中引用的兩個(gè) control： ： 在 中查找 /control/ ：在 中查找 /control/ 通過上面的步驟，一個(gè)請(qǐng)求就得到響應(yīng)。 if (executingIndex = executedIndex) { throw new IllegalStateException(descCurrentValve() + has already been invoked: + valves[executingIndex])。 } } if (executedIndex amp。 prepareForTurbine / ! 預(yù)備 webx 所需的對(duì)象。 plconditions:pathcondition name=/petstore/images/(.+) / getResource name=/petstore/images/$1 / /when otherwise ! 將控制交還給 servlet engine。 webx 要達(dá)到的效果是開發(fā)者開發(fā)的 Action和 Screen 是簡(jiǎn)單無累贅的 POJO，類似于 webwork。 第 23 頁 try { value = resolvers[i].resolve()。 } args[i] = value。 // 確保 field 存在 fieldName = getFieldConfig(groupName, ()).getName()。 return field。 其開發(fā)分三部分，頁面層（ web）、業(yè)務(wù)處理層 (biz)、數(shù)據(jù)處理層 (dao)。 import 。 /** * 類目相關(guān)操作的 action * * author argan * */ public class CategoryAction extends TemplateAction {//0. 繼承基類 /** 。 import 。其他 Resolver 的實(shí)現(xiàn)類似，就不在累述。 boolean valid = ()。 } 它的實(shí)現(xiàn)類有以下幾種： FormResolver：解析整個(gè) Form GroupResolver：解析一個(gè) group GroupsResolver：解析一組 group FieldResolver：用來解析 單個(gè)參數(shù) FieldsResolver：用來解析一組字段 ParameterResolver：用來解析單個(gè)參數(shù) ParametersResolver：用來解析一組參數(shù) TurbineRunDataResolver：用來注入各種環(huán)境信息，比如 request 和 response 具體的實(shí)現(xiàn)的基本思路就是通過 Annotation 得到各個(gè)參數(shù)的結(jié)構(gòu)和配置，然后從 request 里組裝成需要注入的對(duì)象，以 FiledResolver 為例，源碼如下： public FieldResolver(DataResolverContext context, Class? paramType, FormField fieldAnnotation) { super(FieldResolver, context)。amp。 i 。 透過細(xì)節(jié)看本質(zhì)， webx3 在這兩塊的架構(gòu)核心可以歸結(jié)為以下幾個(gè)點(diǎn) 。 plconditions:targetextensioncondition extension=null, vm, jsp / performAction / performTemplateScreen / renderTemplate / /when when ! 執(zhí)行不帶模板的 screen，默認(rèn)無 layout。使得下一個(gè) valve 能得力執(zhí)行，以上代碼細(xì)節(jié)無需太多解析，思路與 j2ee的 filter 和 webwork 的 interceptor 如出一轍 。 } catch (Exception e) { throw new PipelineException(Failed to invoke + descCurrentValve() + : + valve, e)。 if (broken) { return。 根據(jù) target 查找 screen 模板： /screen/ 假如 target 的值為： /xxx/yyy/ ，那么， valve 會(huì)： 1）在 /templates/screen 目錄下，找到 /xxx/yyy/ 模板。 Screen 和 control 都可以有 java 類來驅(qū)動(dòng)，但不是必須的， 第 17 頁 也就是說可以先寫模板，后寫類，也可以只寫模板，不用構(gòu)造對(duì)應(yīng)類。這個(gè)文件定義了 Webx 所用到的所有 services 的配置。 淘寶的一個(gè)系統(tǒng)一般會(huì)有多個(gè)子工程，有個(gè)工程是 web 的，我們要做的接口測(cè)試就是在src/main/java/… /module 下 面，有 action 與 screen。有興趣的 同學(xué)可以去研究下，官方網(wǎng)站： 淘寶內(nèi)部 Web 應(yīng)用的層次是這樣的，如下圖 大家可以看出本質(zhì)是一樣的， Webx 框架其實(shí)就是把頁面與 Service 層之間的一些 Servlet 等公共的東西抽象出來，提供相應(yīng)的服務(wù)以提高開發(fā)效率，所以我們就必須有針對(duì) Webx框架的一套自己的測(cè)試解決方案， itest 就誕生了。），否則還是要多關(guān)注系統(tǒng)和人的交互。曾經(jīng)一次 DBA 發(fā)現(xiàn)數(shù)據(jù)庫上一個(gè)查詢耗費(fèi)太多資源，把優(yōu)化后的 SQL 給開發(fā)人員改進(jìn)，開發(fā)人員好幾天沒找到具體是哪個(gè)查詢。 另外一個(gè)有意思的案例是商品的數(shù)據(jù)擴(kuò)容，商品的水平分割非 常容易，按照賣家進(jìn)行拆分即可。 09 年一年，大部分時(shí)間都在數(shù)據(jù)的擴(kuò)展性上努力。 . 監(jiān)控、預(yù)警系統(tǒng) 對(duì)于大型的系統(tǒng)來說，唯一可靠的就是系統(tǒng)的各個(gè)部分是不可靠。 那么下一步我們說說異步能給系統(tǒng)帶來什么樣子的好處。此時(shí)，咱們搞技術(shù)的哥們，就去看看究竟是啥原因，我們查了查以后，發(fā)現(xiàn)原來是數(shù)據(jù)庫讀取壓力太大了，此時(shí)咱們都清楚是到了讀寫分離的時(shí)候，這個(gè)時(shí)候我們會(huì)配置一個(gè) server 為 master節(jié)點(diǎn)，然后配幾個(gè) salve 節(jié)點(diǎn)，這樣以來通過讀寫分離，使得讀取數(shù)據(jù)的壓力分?jǐn)偟搅瞬煌?salve 節(jié)點(diǎn)上面，系統(tǒng)終于又恢復(fù)了正常，開始正常運(yùn)行了。 在這個(gè)演變的過程中，我們所說的拆分就出現(xiàn) 和 之間。 系統(tǒng)剛上線初期，用戶數(shù)并不多，所有的邏輯也許都是放在一個(gè)系統(tǒng)中的，所有邏輯跑到一個(gè)進(jìn)程或者一個(gè)應(yīng)用當(dāng)中，這個(gè)時(shí)候因?yàn)楸容^用戶少，系統(tǒng)訪問量低，因此將全部的邏輯都放在一個(gè)應(yīng)用未嘗不可。 第 5 頁 . 有效使用緩存 做互聯(lián)網(wǎng)應(yīng)用的兄弟應(yīng)該都清楚，緩存對(duì)于一個(gè)互聯(lián)網(wǎng)應(yīng)用是多么的重要，從瀏覽器緩存，反向 代理緩存，頁面緩存，局部頁面緩存，對(duì)象緩存等等都是緩存應(yīng)用的場(chǎng)景。 . 高性能可伸縮 . 應(yīng)用無狀態(tài) 一個(gè)系統(tǒng)的伸縮性的好壞取決于應(yīng)用的狀態(tài)如何管理。 在今后的發(fā)展中，我們還是會(huì)一如既往的關(guān)注開源軟件的發(fā)展，也還會(huì)根據(jù)需要采用不同的開源軟件 。這對(duì)于應(yīng)用設(shè)計(jì)、開發(fā)、查錯(cuò)、優(yōu)化都是非常有幫助的。其實(shí)淘寶網(wǎng)的 Web 展現(xiàn)層的框架用的不是 struts，不是 webwork，不是 spring mvc 等等?？梢赃@么說，在關(guān)系數(shù)據(jù)庫管理系統(tǒng)的選擇上，可以考慮應(yīng)用本身的情況來決定。并且使用 IIS的話，基本上也就是選擇了 ISAPI、 ASP 或者 進(jìn)行 Web 應(yīng)用的開發(fā)了。這邊就 不在贅述。我們的選擇是 JBoss Applcation Server。如果不準(zhǔn)備采用微軟的一系列產(chǎn)品構(gòu)建應(yīng)用，并且有能力維護(hù) Linux 或者 FreeBSD，再加上成本的考慮，那么還是應(yīng)該在 Linux 和 FreeBSD之間進(jìn)行選擇。對(duì)于像淘寶網(wǎng)這樣規(guī)模的網(wǎng)站而言，就是應(yīng)用也分成很多組。 對(duì)于規(guī)模稍大的網(wǎng)站來說，其 IT 必然是一個(gè)服務(wù)器集群來提供網(wǎng)站服務(wù)，數(shù)據(jù)庫也必然要和應(yīng)用服務(wù)分開，有單獨(dú)的數(shù)據(jù)庫服務(wù)器。硬件上我們選擇 PC Server而不是小型機(jī)，那么 Server 的操作系統(tǒng)供我們選擇的一般也就是 Linux， FreeBSD, windows 2020 Server 或者 Windows Server 2020。那么我們要選擇一款實(shí)現(xiàn)了 JEE 規(guī)范的應(yīng)用服務(wù)器。具體對(duì)于目前 JEE 應(yīng)用服務(wù)器的比較。 而微軟的 IIS，就只能工作在 Windows 的系統(tǒng)上了。用多臺(tái) PC Server 安裝 MySQL組成一個(gè)存儲(chǔ)節(jié)點(diǎn)陣列，通過 MySQL 自身的 Replication 或者應(yīng)用自身的處理，可以很好的保證容錯(cuò) (允許部分節(jié)點(diǎn)失效 )，保證應(yīng)用的健壯性和可靠性。我告訴他說不是的。 另外一個(gè)好處 (我覺得最大的好處 )是你可以看到軟件的源碼，你可以研究了解軟件內(nèi)部的工作過程、原理。軟件本身的發(fā)展應(yīng)該是不會(huì)成為問題的，不太會(huì)出現(xiàn)軟件突然停止發(fā)展的情況。而作為淘寶網(wǎng)，我們也會(huì)非常積極的參與到開源的活動(dòng)中，也會(huì)努力為開源的發(fā)展做出我們應(yīng)有的貢獻(xiàn)。 除了公司目前的 session 框架的實(shí)現(xiàn)方式以外，其實(shí)集中式 session 管理來完成，說具體點(diǎn)就是多個(gè)無狀態(tài)的應(yīng)用節(jié)點(diǎn)連接一個(gè) session 服務(wù)器 ， session 服務(wù)器將 session 保存到緩存中， session 服務(wù)器后端再配有底層持久性數(shù)據(jù)源，比如數(shù)據(jù)庫，文件系統(tǒng)等等。 . 應(yīng)用拆分 首先，在說明應(yīng)用拆分之前，我們先來回顧一下一個(gè)系統(tǒng)從小變大的過程中遇到的一些問題，通過這些 問題我們會(huì)發(fā)現(xiàn)拆分對(duì)于構(gòu)建一個(gè)大型系統(tǒng)是如何的重要。 既然明白了拆分的重要性，我們看看隨著公司的發(fā)展，公司本身是如何拆分系統(tǒng)的。 系統(tǒng)剛開始的時(shí)候，因?yàn)橄到y(tǒng)剛上線，用戶不多，那個(gè)時(shí)候，所有的數(shù)據(jù)都放在了同一個(gè)數(shù)據(jù)庫中，這個(gè)時(shí)候因?yàn)橛脩羯賶毫π。粋€(gè)數(shù)據(jù)庫完全可以應(yīng)付的了，但是隨著運(yùn)營(yíng)那些哥們辛苦的吶喊和拼命的 推廣以后，突然有一天發(fā)現(xiàn)， oh,god,用戶數(shù)量突然變多了起來，隨之而來的就是數(shù)據(jù)庫這哥們受不了，它終于在某一天大家都和愜意的時(shí)候掛掉啦。 說到異步通信，我們需要關(guān)注的一點(diǎn)是這里的異步一定是根據(jù)業(yè)務(wù)特點(diǎn)來的，一定是針對(duì)業(yè) 務(wù)的異步，通常適合異步的場(chǎng)合是一些松耦合的通信場(chǎng)合，而對(duì)于本身業(yè)務(wù)上關(guān)聯(lián)度比較大的業(yè)務(wù)系統(tǒng)之間，我們還是要采用同步通信比較靠譜。目前公司也在研 究和使用一些成熟的 NOSQL 產(chǎn)品。當(dāng)一個(gè)網(wǎng)站從百萬、千萬記錄的數(shù)據(jù)規(guī)模，增長(zhǎng)到億、十億、幾十億記錄的數(shù)據(jù)規(guī)模時(shí)，是一個(gè)量變到質(zhì)變的過程，單純的硬件升級(jí)已經(jīng)達(dá)到了瓶頸，而需要在整體結(jié)構(gòu)上做文章。有些時(shí)候我們想問題不妨直接一點(diǎn)，既然壓力大，能不能減小壓力呢？通過對(duì)訂單訪問情況的了解，發(fā)現(xiàn)昂貴的主數(shù)據(jù)庫，有 80%以上的壓力給了不重要的需求，這個(gè)就是