【文章內(nèi)容簡介】 來什么樣子的好處。首先我們想想，假如系統(tǒng)有 A和 B兩個子系統(tǒng)構(gòu)成，假如 A 和 B是同步通信的話，那么要想使得系統(tǒng)整體伸縮性提高必須同時對 A和 B 進行伸縮，這就影響了對整個系統(tǒng)進行 scale ，同步調(diào)用還會影響到可用性，從數(shù)學(xué)推理的角度來說， A 同步調(diào)用 B，如果 A 可用，那么 B 可用，逆否命題就是如果 B不可用，那么 A也不可用，這將大大影響到系統(tǒng)可用性， 再次，系統(tǒng)之間異步通信以后可以大大提高系統(tǒng)的響應(yīng)時間，使得每個請求的響應(yīng)時間變短，從而提高用戶體驗，因此異步在提高了系統(tǒng)的伸縮性以及可用性的同時，也大大的增強了請求的響應(yīng)時間（當然了，請求的總體處理時間也許不會變少）。 下面我們就以公司的業(yè)務(wù)來看看異步在公司的具體應(yīng)用。交易系統(tǒng)會與很多其它的業(yè)務(wù)系統(tǒng)交互，如果在一次交易過程中采用同步調(diào)用的話，這就要求要向交易成功，必須依賴的所有系統(tǒng)都可用，而如果采用異步通信以后，交易系統(tǒng)借助于消息中間件 Notify 和其它的系統(tǒng)進行了解耦，這樣以來當其它的系統(tǒng)不可用的時候，也 不會影響到某此交易，從而提高了系統(tǒng)的可用性。 第 9 頁 . 非結(jié)構(gòu)化數(shù)據(jù)存儲 在一個大型的互聯(lián)網(wǎng)應(yīng)用當中，我們會發(fā)現(xiàn)并不是所有的數(shù)據(jù)都是結(jié)構(gòu)化的，比如一些配置文件，一個用戶對應(yīng)的動態(tài)，以及一次交易的快照等信息，這些信息一般不適合保存到RDBMS 中，它們更符合一種 Keyvalue 的結(jié)構(gòu)，另外還有一類數(shù)據(jù)，數(shù)據(jù)量非常的大，但是實時性要求不高，此時這些數(shù)據(jù)也需要通過另外的一種存儲方式進行存儲，另外一些靜態(tài)文件，比如各個商品的圖片，商品描述等信息，這些信息因為比較大，放入 RDBMS 會引起讀取性能問題，從而影響到其它的數(shù)據(jù)讀取性 能，因此這些信息也需要和其它信息分開存儲，而一般的互聯(lián)網(wǎng)應(yīng)用系統(tǒng)都會選擇把這些信息保存到分布式文件系統(tǒng)中，因此公司目前也開發(fā)了自己的分布式文件系統(tǒng) TFS， TFS 目前限制了文件大小為 2M，適合于一些小于 2M 數(shù)據(jù)的存放。 隨著互聯(lián)網(wǎng)的發(fā)展，業(yè)界從 08年下半年開始逐漸流行了一個概念就是 NOSQL。我們都知道根據(jù) CAP 理論，一致性，可用性和分區(qū)容錯性 3者不能同時滿足，最多只能同時滿足兩個，我們傳統(tǒng)的關(guān)系數(shù)據(jù)采用了 ACID 的事務(wù)策略，而 ACID 的事務(wù)策略更加講究的是一種高一致性而降低了可用性的需求，但是互聯(lián)網(wǎng)應(yīng)用往往 對可用性的要求要略高于一致性的需求，這個時候我們就需要避免采用數(shù)據(jù)的 ACID 事務(wù)策略，轉(zhuǎn)而采用 BASE 事務(wù)策略， BASE 事務(wù)策略是基本可用性，事務(wù)軟狀態(tài)以及最終一致性的縮寫，通過 BASE 事務(wù)策略，我們可以通過最終一致性來提升系統(tǒng)的可用性，這也是目前很多 NOSQL 產(chǎn)品所采用的策略，包括 facebook 的 cassandra,apache hbase,google bigtable 等，這些產(chǎn)品非常適合一些非結(jié)構(gòu)化的數(shù)據(jù)，比如 keyvalue 形式的數(shù)據(jù)存儲，并且這些產(chǎn)品有個很好的優(yōu)點就是水平伸縮性。目前公司也在研 究和使用一些成熟的 NOSQL 產(chǎn)品。 . 監(jiān)控、預(yù)警系統(tǒng) 對于大型的系統(tǒng)來說，唯一可靠的就是系統(tǒng)的各個部分是不可靠。 因為一個大型的分布式系統(tǒng)中勢必會涉及到各種各樣的設(shè)備，比如網(wǎng)絡(luò)交換機，普通 PC機，各種型號的網(wǎng)卡，硬盤，內(nèi)存等等，而這些東東都在數(shù)量非常多的時候，出現(xiàn)錯誤的概率也會變大，因此我們需要時時刻刻監(jiān)控系統(tǒng)的狀態(tài)，而監(jiān)控也有粒度的粗細之分，粒度粗一點的話，我們需要對整個應(yīng)用系統(tǒng)進行監(jiān)控，比如目前的系統(tǒng)網(wǎng)絡(luò)流量是多少，內(nèi)存利用率是多少， IO， CPU 的負載是多少，服務(wù)的訪問壓力是多少，服務(wù)的響應(yīng)時間是多少等這 一系列的監(jiān)控，而細粒度一點的話，我們就需對比如應(yīng)用中的某個功能，某個 URL 的訪問量是 第 10 頁 多，每個頁面的 PV 是多少，頁面每天占用的帶寬是多少，頁面渲染時間是多少，靜態(tài)資源比如圖片每天占用的帶寬是多少等等進行進一步細粒度的監(jiān)控。因此一個監(jiān)控系統(tǒng)就變得必不可少了。 前面說了一個監(jiān)控系統(tǒng)的重要性，有了監(jiān)控系統(tǒng)以后，更重要的是要和預(yù)警系統(tǒng)結(jié)合起來，比如當某個頁面訪問量增多的時候，系統(tǒng)能自動預(yù)警，某臺 Server 的 CPU 和內(nèi)存占用率突然變大的時候，系統(tǒng)也能自動預(yù)警，當并發(fā)請求丟失嚴重的時候，系統(tǒng)也能自動預(yù)警等等，這樣以來通 過監(jiān)控系統(tǒng)和預(yù)警系統(tǒng)的結(jié)合可以使得我們能快速響應(yīng)系統(tǒng)出現(xiàn)的問題，提高系統(tǒng)的穩(wěn)定性和可用性。 . 配置統(tǒng)一管理 一個大型的分布式應(yīng)用，一般都是有很多節(jié)點構(gòu)成的，如果每次一個新的節(jié)點加入都要更改其它節(jié)點的配置，或者每次刪除一個節(jié)點也要更改配置的話，這樣不僅不利于系統(tǒng)的維護和管理，同時也更加容易引入錯誤。另外很多時候集群中的很多系統(tǒng)的配置都是一樣的，如果不進行統(tǒng)一的配置管理，就需要 在 所有的系統(tǒng)上維護一份配置，這樣會造成配置的管理維護很麻煩，而通過一個統(tǒng)一的配置管理可以使得這些問題得到很好的解決，當有新的節(jié)點加入或者刪 除的時候，配置管理系統(tǒng)可以通知各個節(jié)點更新配置，從而達到所有節(jié)點的配置一致性，這樣既方便也不會出錯。 . 數(shù)據(jù)擴展性探討和總結(jié) 金融危機是電子商務(wù)的機遇，所以 09 年是淘寶高速發(fā)展的一年。當一個網(wǎng)站從百萬、千萬記錄的數(shù)據(jù)規(guī)模，增長到億、十億、幾十億記錄的數(shù)據(jù)規(guī)模時，是一個量變到質(zhì)變的過程，單純的硬件升級已經(jīng)達到了瓶頸，而需要在整體結(jié)構(gòu)上做文章。 09 年一年，大部分時間都在數(shù)據(jù)的擴展性上努力。 對于一個電子商務(wù)網(wǎng)站來講，訂單是最核心的數(shù)據(jù)，也是增長最快的數(shù)據(jù)。對于數(shù)據(jù)的擴展性來講，最傳統(tǒng)也是最簡單有效的模式是數(shù)據(jù)庫的 分庫分表。當訂單和分庫分表相遇，會有什么火花迸發(fā)出來？ 09年初碰撞了很久，結(jié)果產(chǎn)生的火花很小。最大的問題在于數(shù)據(jù)分割的規(guī)則，無規(guī)則的水平分割肯定會帶來數(shù)據(jù)合并的開銷，而按照業(yè)務(wù)規(guī)則拆分，會因為買家和賣家的查詢需求不同而導(dǎo)致數(shù)據(jù)不能分割，唯一可行的火花是把訂單雙份保存，買家賣家各自一份，只是成本比較高，而且對數(shù)據(jù)同步的要求非常高。 第 11 頁 于是我們初步?jīng)Q定按照雙份保存的方式拆分訂單，而有一天，仔細查看了訂單訪問的情況，發(fā)現(xiàn)訂單數(shù)據(jù)庫 90%以上的壓力來自于查詢，而查詢中 90%以上的壓力來自于非核心業(yè)務(wù)，僅僅是訂單數(shù)據(jù) 的展現(xiàn)，對一致性和實時性的要求很低。 因為數(shù)據(jù)量大，造成數(shù)據(jù)庫壓力大，天然想到的是分散壓力，其辦法就是分庫分表。有些時候我們想問題不妨直接一點，既然壓力大，能不能減小壓力呢？通過對訂單訪問情況的了解，發(fā)現(xiàn)昂貴的主數(shù)據(jù)庫，有 80%以上的壓力給了不重要的需求，這個就是我們優(yōu)化的關(guān)鍵，所以訂單最后采用了讀寫分離的方案，高成本的主數(shù)據(jù)庫解決事務(wù)和重要的查詢業(yè)務(wù)， 80%以上不重要的讀，交給了低成本的數(shù)據(jù)庫服務(wù)器來解決，同時對數(shù)據(jù)復(fù)制的要求也很低，實現(xiàn)無太大難度。 另外一個有意思的案例是商品的數(shù)據(jù)擴容，商品的水平分割非 常容易，按照賣家進行拆分即可。有了訂單的先例，首先想到了讀寫分離，因為成本可以做低。開始實施后一段時間，又仔細回想了一下商品的整體需求，突然發(fā)現(xiàn)商品其實不需要和訂單同等的要求，一定要采用高成本的主數(shù)據(jù)庫嗎？ 全部采用低成本的普通服務(wù)器來做數(shù)據(jù)庫是否可行？經(jīng)過仔細的評估，發(fā)現(xiàn)是可以接受的，而這樣就導(dǎo)致之前已經(jīng)啟動的商品讀寫分離項目的一部分工作白做了！ 故事講完了總是要有點總結(jié)，來點虛的先：對于原始需求的清晰了解是系統(tǒng)決策的前提，否則彎路肯定要走，而對原始需求的了解并不容易，中間會有很多干擾和阻力，前面的實例看 起來很簡單，但是在一個運行了 5 年的系統(tǒng)上來了解本質(zhì)，來進行變更，并沒那么容易。另外，經(jīng)驗有些時候會成為系統(tǒng)決策的障礙，這個很矛盾，所以需要有歸零的心態(tài)來思考問題。說到底，回歸本源。 再來點稍微實際一點的，對于大型分布式系統(tǒng)的數(shù)據(jù)訪問，一個統(tǒng)一的數(shù)據(jù)層是非常必要的，封裝水平、垂直的數(shù)據(jù)分割，封裝讀寫分離，封裝數(shù)據(jù)訪問的路由、復(fù)制、合并、搬遷、熱點處理等功能，并且要對應(yīng)用透明，應(yīng)用針對性的，可以在 JDBC 層面包裝，數(shù)據(jù)庫針對性的，可以在數(shù)據(jù)庫協(xié)議層包裝，比如 Amoeba。 關(guān)注系統(tǒng)和人的交互 還有一個故事，在 數(shù)據(jù)層的前期版本，為了做到透明的路由，曾經(jīng)采用無 SQL 的方式，所有的數(shù)據(jù)庫訪問都是寫代碼來做。上線后發(fā)現(xiàn)一個非常痛苦的問題，無法和 SQL 對應(yīng)，排錯非常難。曾經(jīng)一次 DBA 發(fā)現(xiàn)數(shù)據(jù)庫上一個查詢耗費太多資源，把優(yōu)化后的 SQL 給開發(fā)人員改進，開發(fā)人員好幾天沒找到具體是哪個查詢。 另外一個在 2020 年的感觸是業(yè)界服務(wù)化的實施情況，很多組織都在實施服務(wù)化，系統(tǒng)層 第 12 頁 面都很成功，通信、負載均衡、消息系統(tǒng)、服務(wù)容器等都有很多成果，但是實施一段時間以后的效果并不是非常好，依賴復(fù)雜，變更混亂，效率低下。究其根本，是對人的關(guān)注不夠，缺少的產(chǎn)品化的服務(wù)運維，缺少服務(wù)治理。 上面的兩個例子都是對人的關(guān)注缺失，技術(shù)人員做系統(tǒng)，大部分都更關(guān)注技術(shù)，而忽視技術(shù)的創(chuàng)造者和使用者 —— 人。軟件或服務(wù)的可測試性是對測試人員的關(guān)注、可維護性和可管理性是對運維人員的關(guān)注，而一個框架的易用性是對所有使用人員的關(guān)注。除非能做出自己進化的 Sky（注： Sky（天網(wǎng)）出現(xiàn)在《終結(jié)者》系列電影中，是一個人類于 20 世紀后期創(chuàng)造的以計算機為基礎(chǔ)的人工智能防御系統(tǒng)，最初是研究用于軍事的發(fā)展。天網(wǎng)在控制了所有的美軍的武器裝備后不久，獲得自我意識，并且認定人類是它存 在的威脅。于是立刻倒戈對抗其創(chuàng)造者，采用大規(guī)模殺傷性武器（甚至核暴）來滅絕全人類。），否則還是要多關(guān)注系統(tǒng)和人的交互。 關(guān)注可用性 還有一個感觸是業(yè)界對可用性這個基本指標的關(guān)注度不夠。幾乎所有的框架都會說自己的擴展性多高，性能多好，而很少會提到監(jiān)控有多強、排錯有多容易，很少提到在故障時怎么做隔離，怎么做降級；從這個角度看，商用的產(chǎn)品確實做得好很多；關(guān)于性能相關(guān)的文章搜索一下，很多，各種優(yōu)化策略，各種優(yōu)化方法，而可用性方面，找到的系統(tǒng)性的知識真的很少；希望是我了解的不多。 回顧過去，展望未來。 2020 年，很多 可以做的事情，面向服務(wù)系統(tǒng)的隔離和降級、系統(tǒng)可維護性的提高、協(xié)程和異步模式在 web 應(yīng)用的全面使用…… 免責聲明：我很現(xiàn)實，為解決問題和完成工作不擇手段，并且不懂架構(gòu)是什么意思，以上觀點如有雷同，純屬巧合！如有異議，歡迎拍磚！ . WebX . 總述 . Webx 簡單概括 WebX 是阿里巴巴的內(nèi)部框架，“就是把頁面與 Service 層之間的一些 Servlet 等公共的東西抽象出來，提供相應(yīng)的服務(wù)以提高開發(fā)效率（《接口測試之 Webx 簡介》 — 何曉峰 ）”，可以看出， Webx 和傳統(tǒng)的 servletaction 模式的 HettpServlet 為基礎(chǔ)，對其中的公用的抽象 第 13 頁 整理后，得到一個輕量級的 web 開發(fā)框架。 Webx 頁面使用了 velocity 模板， WEB 層使用的是 WEBX 框架里面的 TemplateAction,TemplateScreen,AbstractModule,TemplateControl，解決了操作和頁面的跳轉(zhuǎn)。持久層使用 ibatis， Bean 容器使用的是 Spring。 一般基本 web 應(yīng)用的層次是這樣的，如下圖 Apache公司有個開源項目 Cactus，是專門針對上面的 Servlet來做接口測試的一個框架。有興趣的 同學(xué)可以去研究下，官方網(wǎng)站： 淘寶內(nèi)部 Web 應(yīng)用的層次是這樣的，如下圖 大家可以看出本質(zhì)是一樣的， Webx 框架其實就是把頁面與 Service 層之間的一些 Servlet 等公共的東西抽象出來，提供相應(yīng)的服務(wù)以提高開發(fā)效率，所以我們就必須有針對 Webx框架的一套自己的測試解決方案， itest 就誕生了。 Webx 里面有三個比較重要的概念， action， screen， control，下面分別來做介紹，看圖。 第 14 頁 頁頭 Head、 菜單 Menu、 頁腳 Foot，這些通常是變化不大的，都可以做成 control 小控件； 頁中 Middle，這塊通常是變化比較大的，可以做成 screen。 上圖是大家都十分熟悉的淘寶登錄頁面，填入相應(yīng)信息后，點擊登錄按鈕，這個動作就是 action。 對 webx 層做接口測試 ， 就是對 action 與 screen 來做測試，它們的區(qū)別是： (1) screen 就相當于 select 查詢，比如請求一個鏈接 ，就會有 GetUserScreen 中的 execute 方法來獲得用戶信息，然后將其渲染到 ge 顯示到頁面。 示例代碼： (2) action 就相當于 insert 或 update，比如注冊頁面，需要填寫表單信息，然后點擊注冊按鈕，請求 UserAction 中的 doRegister 方法來處理這些數(shù)據(jù)，插入到數(shù)據(jù)庫表中。 示例代碼： 按照 Webx 規(guī)范，是這么區(qū)分的，但是 action 與 screen 能做同樣的事，有時候開發(fā)可能不太會去嚴格的區(qū)別它們，有些開發(fā)主要關(guān)注能實現(xiàn)功能即可。 第 15 頁 綜上， webx 層接口測試，就是對 action 里面的 doXXX 方法，與 screen 里的 execute 方法來做測試，這些就是我們所謂的接口，接口測試并不一定要是 interface 聲明才算，對于頁面