2009年是挑戰和機遇並存的一年，對大部分人來說，已經習慣了金融危機，並努力解決危機。在技術圈子也一樣，被裁員的肯定也找到了工作，所以都在踏實做技術。言歸正傳，先念叨念叨2009年的一些故事，尋個回憶，找個樂子。
數據擴展性探討和總結
金融危機是電子商務的機遇，所以09年是淘寶高速發展的一年。當一個網站從百萬、千萬記錄的數據規模，增長到億、十億、幾十億記錄的數據規模時，是一個量變到質變的過程，單純的硬件升級已經達到了瓶頸，而需要在整體結構上做文章。09年一年，大部分時間都在數據的擴展性上努力。
對於一個電子商務網站來講，訂單是最核心的數據，也是增長最快的數據。對於數據的擴展性來講，最傳統也是最簡單有效的模式是數據庫的分庫分表。當訂單和分庫分表相遇，會有什麼火花迸發出來？09年初碰撞了很久，結果產生的火花很小。最大的問題在於數據分割的規則，無規則的水平分割肯定會帶來數據合並的開銷，而按照業務規則拆分，會因為買家和賣家的查詢需求不同而導致數據不能分割，唯一可行的火花是把訂單雙份保存，買家賣家各自一份，只是成本比較高，而且對數據同步的要求非常高。
於是我們初步決定按照雙份保存的方式拆分訂單，而有一天，仔細查看了訂單訪問的情況，發現訂單數據庫90%以上的壓力來自於查詢，而查詢中90%以上的壓力來自於非核心業務，僅僅是訂單數據的展現，對一致性和實時性的要求很低。
因為數據量大，造成數據庫壓力大，天然想到的是分散壓力，其辦法就是分庫分表。有些時候我們想問題不妨直接一點，既然壓力大，能不能減小壓力呢？通過對訂單訪問情況的了解，發現昂貴的主數據庫，有80%以上的壓力給了不重要的需求，這個就是我們優化的關鍵，所以訂單最後采用了讀寫分離的方案，高成本的主數據庫解決事務和重要的查詢業務，80%以上不重要的讀，交給了低成本的數據庫服務器來解決，同時對數據復制的要求也很低，實現無太大難度。
另外一個有意思的案例是商品的數據擴容，商品的水平分割非常容易，按照賣家進行拆分即可。有了訂單的先例，首先想到了讀寫分離，因為成本可以做低。開始實施後一段時間，又仔細回想了一下商品的整體需求，突然發現商品其實不需要和訂單同等的要求，一定要采用高成本的主數據庫嗎？ 全部采用低成本的普通服務器來做數據庫是否可行？經過仔細的評估，發現是可以接受的，而這樣就導致之前已經啟動的商品讀寫分離項目的一部分工作白做了！
故事講完了總是要有點總結，來點虛的先：對於原始需求的清晰了解是系統決策的前提，否則彎路肯定要走，而對原始需求的了解並不容易，中間會有很多干擾和阻力，前面的實例看起來很簡單，但是在一個運行了5年的系統上來了解本質，來進行變更，並沒那麼容易。另外，經驗有些時候會成為系統決策的障礙，這個很矛盾，所以需要有歸零的心態來思考問題。說到底，回歸本源。
再來點稍微實際一點的，對於大型分布式系統的數據訪問，一個統一的數據層是非常必要的，封裝水平、垂直的數據分割，封裝讀寫分離，封裝數據訪問的路由、復制、合並、搬遷、熱點處理等功能，並且要對應用透明，應用針對性的，可以在JDBC層面包裝，數據庫針對性的，可以在數據庫協議層包裝，比如Amoeba。
關注系統和人的交互
還有一個故事，在數據層的前期版本，為了做到透明的路由，曾經采用無SQL的方式，所有的數據庫訪問都是寫代碼來做。上線後發現一個非常痛苦的問題，無法和SQL對應，排錯非常難。曾經一次DBA發現數據庫上一個查詢耗費太多資源，把優化後的SQL給開發人員改進，開發人員好幾天沒找到具體是哪個查詢。
另外一個在2009年的感觸是業界服務化的實施情況，很多組織都在實施服務化，系統層面都很成功，通信、負載均衡、消息系統、服務容器等都有很多成果，但是實施一段時間以後的效果並不是非常好，依賴復雜，變更混亂，效率低下。究其根本，是對人的關注不夠，缺少的產品化的服務運維，缺少服務治理。
上面的兩個例子都是對人的關注缺失，技術人員做系統，大部分都更關注技術，而忽視技術的創造者和使用者——人。軟件或服務的可測試性是對測試人員的關注、可維護性和可管理性是對運維人員的關注，而一個框架的易用性是對所有使用人員的關注。除非能做出自己進化的Skynet（注：Skynet（天網）出現在《終結者》系列電影中，是一個人類於20世紀後期創造的以計算機為基礎的人工智能防御系統，最初是研究用於軍事的發展。），否則還是要多關注系統和人的交互。
關注可用性
還有一個感觸是業界對可用性這個基本指標的關注度不夠。幾乎所有的框架都會說自己的擴展性多高，性能多好，而很少會提到監控有多強、排錯有多容易，很少提到在故障時怎麼做隔離，怎麼做降級；從這個角度看，商用的產品確實做得好很多；關於性能相關的文章搜索一下，很多，各種優化策略，各種優化方法，而可用性方面，找到的系統性的知識真的很少；希望是我了解的不多。
回顧過去，展望未來。2010年，很多可以做的事情，面向服務系統的隔離和降級、系統可維護性的提高、協程和異步模式在web應用的全面使用……
免責聲明：我很現實，為解決問題和完成工作不擇手段，並且不懂架構是什麼意思，以上觀點如有雷同，純屬巧合！如有異議，歡迎拍磚！
個人簡介：岳旭強，淘寶網技術專家。2004年加入淘寶，見證了淘寶網業務以及技術上完整的發展過程；在過去5年的時間中，參與了淘寶幾乎所有核心系統改造，並主導了用來支撐淘寶網未來高速發展的核心業務中心的建設。岳旭強現在負責網站整體業務架構的設計和規劃，在大型交易網站的設計和調優方面有豐富的經驗。