原文地址：http://www.infoq.com/cn/articles/yuexuqiang-share-outlook

?

“一場危機贏得高度關注的時候，它已經不是危機，人們是要處理這個危機?！薄R云

2009年是挑戰和機遇并存的一年，對大部分人來說，已經習慣了金融危機，并努力解決危機。在技術圈子也一樣，被裁員的肯定也找到了工作，所以都在踏實做技術。言歸正傳，先念叨念叨2009年的一些故事，尋個回憶，找個樂子。

數據擴展性探討和總結

金融危機是電子商務的機遇，所以09年是淘寶高速發展的一年。當一個網站從百萬、千萬記錄的數據規模，增長到億、十億、幾十億記錄的數據規模時，是一個量變到質變的過程，單純的硬件升級已經達到了瓶頸，而需要在整體結構上做文章。09年一年，大部分時間都在數據的擴展性上努力。

對于一個電子商務網站來講，訂單是最核心的數據，也是增長最快的數據。對于數據的擴展性來講，最傳統也是最簡單有效的模式是數據庫的分庫分表。當訂單和分庫分表相遇，會有什么火花迸發出來？09年初碰撞了很久，結果產生的火花很小。最大的問題在于數據分割的規則，無規則的水平分割肯定會帶來數據合并的開銷，而按照業務規則拆分，會因為買家和賣家的查詢需求不同而導致數據不能分割，唯一可行的火花是把訂單雙份保存，買家賣家各自一份，只是成本比較高，而且對數據同步的要求非常高。

于是我們初步決定按照雙份保存的方式拆分訂單，而有一天，仔細查看了訂單訪問的情況，發現訂單數據庫90%以上的壓力來自于查詢，而查詢中90%以上的壓力來自于非核心業務，僅僅是訂單數據的展現，對一致性和實時性的要求很低。

因為數據量大，造成數據庫壓力大，天然想到的是分散壓力，其辦法就是分庫分表。有些時候我們想問題不妨直接一點，既然壓力大，能不能減小壓力呢？通過對訂單訪問情況的了解，發現昂貴的主數據庫，有80%以上的壓力給了不重要的需求，這個就是我們優化的關鍵，所以訂單最后采用了讀寫分離的方案，高成本的主數據庫解決事務和重要的查詢業務，80%以上不重要的讀，交給了低成本的數據庫服務器來解決，同時對數據復制的要求也很低，實現無太大難度。

另外一個有意思的案例是商品的數據擴容，商品的水平分割非常容易，按照賣家進行拆分即可。有了訂單的先例，首先想到了讀寫分離，因為成本可以做低。開始實施后一段時間，又仔細回想了一下商品的整體需求，突然發現商品其實不需要和訂單同等的要求，一定要采用高成本的主數據庫嗎？ 全部采用低成本的普通服務器來做數據庫是否可行？經過仔細的評估，發現是可以接受的，而這樣就導致之前已經啟動的商品讀寫分離項目的一部分工作白做了！

故事講完了總是要有點總結，來點虛的先：對于原始需求的清晰了解是系統決策的前提，否則彎路肯定要走，而對原始需求的了解并不容易，中間會有很多干擾和阻力，前面的實例看起來很簡單，但是在一個運行了5年的系統上來了解本質，來進行變更，并沒那么容易。另外，經驗有些時候會成為系統決策的障礙，這個很矛盾，所以需要有歸零的心態來思考問題。說到底，回歸本源。

再來點稍微實際一點的，對于大型分布式系統的數據訪問，一個統一的數據層是非常必要的，封裝水平、垂直的數據分割，封裝讀寫分離，封裝數據訪問的路由、復制、合并、搬遷、熱點處理等功能，并且要對應用透明，應用針對性的，可以在JDBC層面包裝，數據庫針對性的，可以在數據庫協議層包裝，比如Amoeba。

關注系統和人的交互

還有一個故事，在數據層的前期版本，為了做到透明的路由，曾經采用無SQL的方式，所有的數據庫訪問都是寫代碼來做。上線后發現一個非常痛苦的問題，無法和SQL對應，排錯非常難。曾經一次DBA發現數據庫上一個查詢耗費太多資源，把優化后的SQL給開發人員改進，開發人員好幾天沒找到具體是哪個查詢。

另外一個在2009年的感觸是業界服務化的實施情況，很多組織都在實施服務化，系統層面都很成功，通信、負載均衡、消息系統、服務容器等都有很多成果，但是實施一段時間以后的效果并不是非常好，依賴復雜，變更混亂，效率低下。究其根本，是對人的關注不夠，缺少的產品化的服務運維，缺少服務治理。

上面的兩個例子都是對人的關注缺失，技術人員做系統，大部分都更關注技術，而忽視技術的創造者和使用者——人。軟件或服務的可測試性是對測試人員的關注、可維護性和可管理性是對運維人員的關注，而一個框架的易用性是對所有使用人員的關注。除非能做出自己進化的Skynet（注：Skynet（天網）出現在《終結者》系列電影中，是一個人類于20世紀后期創造的以計算機為基礎的人工智能防御系統，最初是研究用于軍事的發展。天網在控制了所有的美軍的武器裝備后不久，獲得自我意識，并且認定人類是它存在的威脅。于是立刻倒戈對抗其創造者，采用大規模殺傷性武器（甚至核暴）來滅絕全人類。），否則還是要多關注系統和人的交互。

關注可用性

還有一個感觸是業界對可用性這個基本指標的關注度不夠。幾乎所有的框架都會說自己的擴展性多高，性能多好，而很少會提到監控有多強、排錯有多容易，很少提到在故障時怎么做隔離，怎么做降級；從這個角度看，商用的產品確實做得好很多；關于性能相關的文章搜索一下，很多，各種優化策略，各種優化方法，而可用性方面，找到的系統性的知識真的很少；希望是我了解的不多。

回顧過去，展望未來。2010年，很多可以做的事情，面向服務系統的隔離和降級、系統可維護性的提高、協程和異步模式在web應用的全面使用……

免責聲明：我很現實，為解決問題和完成工作不擇手段，并且不懂架構是什么意思，以上觀點如有雷同，純屬巧合！如有異議，歡迎拍磚！

---

作者簡介：岳旭強，淘寶網技術專家。2004年加入淘寶，見證了淘寶網業務以及技術上完整的發展過程；在過去5年的時間中，參與了淘寶幾乎所有核心系統改造，并主導了用來支撐淘寶網未來高速發展的核心業務中心的建設。岳旭強現在負責網站整體業務架構的設計和規劃，在大型交易網站的設計和調優方面有豐富的經驗。

轉載于:https://www.cnblogs.com/davidwang456/p/6074800.html

總結

以上是生活随笔為你收集整理的数据扩展性探讨和总结--转的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。