英國著名哲學家培根說：
“求知可以改進人性，而實驗又可以改進知識本身。人的天性猶如野生的花草，求知學習好比修剪移栽。”
我買的第一本技術書是<
後來我買了很多技術書，有的書買完之後，簡單翻了翻就束之高閣，有的書像寶貝一樣 ，來來回回翻了十幾次，書頁都磨破了。 接下里我列舉對我影響最大的幾本技術書，以及閱讀的體驗，與諸君分享。
1。 Javascript聖經
這是我學習JavaScript的第一本“
英文
”書。
彼時，Ajax技術已經興起了，ie瀏覽器佔據了大部分的市場份額，但不思進取，firefox悄悄崛起，findbug外掛剛剛流行起來，chrome剛出生不久。第一代前端js框架Prototype已經慢慢跟不上時代，Jquery初露鋒芒。 在Javaeye網站上，富客戶端技術的討論如火如荼，佔據了相當多的篇幅。
當時的網際網路世界並不像現在這樣學習資源豐富，很多資源只有英文版本，javascript聖經是最有名的學習資料之一。
那個時候的我對前端產生了強烈的興趣。但對JavaScript一無所知，也不知道入何入手，就找了JavaScript聖經這部大部頭的英文書來看。
翻開這本書，那滿眼的英文就像是天書一般，而且書中有接近1000個例子，和大量的英文術語。看一眼就讓我頓感氣餒。可是放棄了，就什麼都學不會了，於是我一邊開啟金山詞霸，另一邊開啟英文pdf。一個例子，一個例子的在Eclipse上把程式碼copy下來，並逐行寫下我對程式碼的註釋。每天至少有十次想要放棄。可是學習哪能中途，這樣堅持了1個月，一共寫了500個例子。
這次1個月的瘋狂閱讀，讓我成長頗多。
給我打下的較的js基礎
可以寫一些基礎的js基礎元件，如彈窗，批次上傳等
英文閱讀能力提升
後來，公司準備用Extjs來做一個專案。
說實話，那個時候，我真的沒有想到用純碎的JavaScript可以實現這樣美觀的介面。下圖是一個用
Ext
做的類windows的web應用。
但也正是因為js的能力快速提升，我很快融入了公司的
Ext
專案。經過三個月的艱苦奮鬥，國家藥典委專案順利交付。
至今，JavaScript聖經依然在心裡，佔據了很大的分量，並不僅僅是書裡的內容，更多的是他見證了我小小努力的過程。當我失落沮喪的時候，想起原來的自己，又有了一些前進的勇氣。
2。 淘寶技術這十年
這本書的作者是前淘寶技術大學校長子柳。 2013年左右我服務的彩票公司訂單量激增，高併發下系統遇到各種瓶頸。而技術團隊面對高併發並沒有應對經驗，也沒有大牛給我們指導。我的困惑在於：我知道當前的系統有瓶頸了，但我不知道未來的路該如何走，怎樣的技術才能滿足日益增長業務需求。
恰巧，我在新浪部落格上讀到«淘寶技術那十年»，如獲至寶，酣暢淋漓的讀起來。這本書以工程師的視角，講述了淘寶這個超大型的網際網路系統的成長經歷。這本書可以說真正讓我對技術的理解擺脫了“井底之蛙”的階段。
接下來我從如下三個方面談談我的收穫。
1、中介軟體
2、思維升級
3、事業成就人
2。1 中介軟體
▍ rpc框架
2013年，我接觸到的服務間呼叫主要是透過http（xml/json）呼叫。 http呼叫圖類似：
從呼叫方式來看，確實很簡單。但是服務與服務之間的協議可能也不相同，導致需要編寫大量冗餘的加解密程式碼。
工程師只需要在配置檔案配置服務的域名即可呼叫。 但當時需要在每個服務端自己定義加解密方法，另外服務與服務之間協議可能也不太相同，導致服務間呼叫，需要編寫大量冗餘的加解密程式碼。
同時，業務的激增，服務間的呼叫越來越複雜，就算是公司的老程式設計師也很難梳理服務間的呼叫關係。
我常常想： “有沒有一種優秀的理念能讓服務間呼叫更加簡單，更加清晰”！
從這本書裡，我第一次聽到HSF，這個在阿里巴巴廣泛使用的分散式RPC服務框架。
書中寫到：
還有一些系統是透過 WebService、Socket甚至是HTTP請求來相互呼叫的。每種呼叫方 式都涉及各種超時、資訊的加解/密、引數的定義等問題，由此可 見，在沒有HSF之前，系統之間的呼叫是錯綜複雜的。而隨著系 統拆分得越來越多，必須由一個統一的中間層來處理這種問題， HSF正是在這種背景下誕生的。
HSF的設計思路是： 服務的提供者啟動時透過HSF框架 向ConfigServer註冊服務資訊（介面、版 本、超時時間、序列化方式等），這樣ConfigServer上面就定義 了所有可供呼叫的服務（同一個服務也可能有不同的版本）。
看了hsf這一節，我才第一次接觸到註冊中心，生產者，消費者，服務治理這些概念。 後來阿里開源的dubbo，這個業界最有名的RPC框架。
從hsf和dubbo兩者的架構圖來看，兩者的思想大同小異。
在最近這幾年，我做的應用都是基於類似的架構。只不過註冊中心可以有更多選擇，比如zookeeper，nacos等。
▍ 分庫分表
我很早就對分庫分表感興趣。讀完TDDL這一篇，感觸良多。
1）萬丈高樓平地起
書中寫到：
淘寶主要在使用 ibatis作為訪問資料庫的DAO層，所以，CommonDAO的作用就是 對ibatis層做了一個很淺的封裝，允許你透過商品字串ID的第一個 字元來訪問兩臺資料庫中的一臺。比如，如果字串ID的第一個字元是0~7，那麼走到資料庫1 去，如果是8~f，則走到資料庫2去。同時，也允許使用者直接給定 資料庫的名字來訪問資料庫。這應該是最早的資料層原型。
當我第一次讀到這段話的時候，嘴角不禁上揚，原來淘寶網的DAL層和我們設計一樣“屌絲”呀。
2）異構資料複製思想
華黎帶著我和念冰，坐在那裡討論了一個半月，還是沒想出來……於是決定先動起手來。名字是我起的——Taobao Distributed Data layer（TDDL，後來有人對它取了個外號 ：“頭都大了”）。找到的目標應用是“收藏夾”，首先要做的兩個關鍵的特性是：分庫分表和異構資料庫的資料複製。開始本來希望和B2B的團隊合作，因為我們覺得獨立的Proxy沒有太大必要。而SQL解析器因為有淘寶特殊的需求，所以也需要重寫。
其實tddl的模式都是client模式，現在業界廣泛使用的sharding-jdbc也是這種模式。 也有mycat這種proxy模式的，還有類似藝龍網client+proxy混合模式的。
但是都逃不掉的是“
異構資料庫的資料複製
” 這個概念。
基於訂單資料的分庫分表場景，按照使用者id取模雖然很好地滿足了訂單資料均勻地儲存在資料庫中，但在賣家檢視自己訂單的業務場景中，就出現了全表掃描的情況，若賣家檢視自己訂單的請求是非常頻繁的，必然給資料庫帶來擴充套件和效能的問題，有違“儘量減少事務邊界”這一原則。
針對這類場景問題，最常用的是採用“異構索引表”的方式解決，即採用非同步機制將原表的每一次建立或更新，都換另一個維度儲存一份完整的資料表或索引表。這是另一種解決思路：拿空間換時間。
業界有很多開源的產品 canal，otter，神州開源自己的工具datalink。
2）最終形態的不成熟思考
很多對分庫分表原理不瞭解的同學都有一種樸素的想法：“我寫我的sql就可以了，為什麼非要讓我關注分割槽關鍵字？”
說實話，我一直認為分庫分表的中介軟體是一種臨時解決方案。很多中小企業，甚至大公司的新興業務也經常使用分庫分表這種模式，因為它足夠簡單和易於工程化。 但這種方式總看起來那麼不自然，擴容縮容非常麻煩，而且某些情況下還需要做大量異構複製的操作。 後來，oceanbase，tidb進入我的視野， 資料庫進入了新的紀元。
也許有一天資料庫具備了真正的人工智慧，可以自動伸縮，可以指導工程師對程式進行優，甚至能智慧判斷複雜多變的業務場景，做出比人腦更精準的指令。 相信那一天很快就會到來。
2。2 思維升級
▍ 模組化重構
淘寶網最開始是php寫的，後來慢慢的遷移到java。那麼他們是怎麼遷移的呢？
現在擺在他們面前的問題是用什麼辦法把一個龐大的網站從PHP語言遷移到Java？而且要求在遷移的過程中，不停止服務，原來系統的bugfix和功能改進不受影響。親，你要是架構師，你怎麼做？。。。。。他們的大致方案是給業務分模組，一個模組一個模組地漸進式替換。使用者模組，老的member。taobao。com繼續維護，不新增新功能，新功能在新的模組上開發，跟老的模組共用一個數據庫，開發完畢之後放到不同的應用叢集上，另開一個域名member1。taobao。com，同時再替換老的功能，替換一個，就把老的模組上的功能關閉一個，逐漸把使用者引導到member1。taobao。com，等所有的功能都替換完之後，關閉member。taobao。com上。
時隔多年過去了，我依然清晰得記住這段話。就像是在我的心裡刻下了印記一般。
在我重構的時候， 我也會採取類似的方案，一個模組一個模組的替換。
在我做架構設計的時候，我會考慮功能是否可以模組化，邊界是否清晰。
在我上線的時候，假如上線內容過多，我會想是否可以一個一個模組上線，減少風險。。。。
▍ 服務中心化
我們把交易的底層業務拆分出來，叫交易中心（Trade Center，TC），所謂底層業務，就如建立訂單、減庫存、修改訂單狀態等
原子型
的操作；交易的上層業務叫交易管理（Trade Manager，TM），例如，拍下一件普通商品要對訂單、庫存、物流進行操作，拍下虛擬商品不需要對物流進行操作，這些在TM中完成。 類目屬性、使用者中心、交易中心，隨著這些模組的逐步拆分 和服務化改造，我們在系統架構方面也積累了不少經驗。到2008 年年底就做了一個更大的專案，把淘寶所有的業務都模組化，這是繼2004年從LAMP架構到Java架構之後的第二次脫胎換骨。
我談談我的體驗。 京東是大家經常用的購物網站。現在的訂單列表如下：
我們可以看到當前訂單列表裡不僅可以查詢實物訂單，也可以查詢各種虛擬訂單， 而且訂單也可以按照時間範圍來查詢。
可是大家知道嗎？ 在2012年左右可不是這樣子的。 我在京東呆過短暫的三個月，當時是負責酒店機票業務。 當時的機票酒店的訂單和實物訂單是分隔開的，只不過左側導航頁和header都是相同的。
2012年的“6·18年中大促”，我們親眼目睹了“什麼是宕機”。
我相信2012年之後，京東訂單必定會做了服務中心化。交易中心化支援各種不同的訂單型別，無論是實物的還是虛擬的，當有新的業務訂單產生的時候，可以完美的支撐業務快速的前進。
2。3 事業成就人
多隆是也許是程式設計師心目中的神。
淘寶商品詳情頁面”每天的流量在10億次以上，其中的內容都是放在快取裡的， 做“招財進寶”的時候，我們要給賣家顯示他的商品被瀏覽的次數，這個數字必須實時更新，而用快取一般都是非同步更新的。於是商品表中增加了這樣一個欄位，每增加一個PV，這個欄位就要更新一次，釋出上去一個小時後，資料庫就掛掉了，撐不住這麼高的更新。資料庫撐不住怎麼辦？一般的快取策略是不支援實時更新的，這時候多隆大神想了個辦法，在Apache上面寫了一個模組，這個數字根本不經過下層的Web容器（只經過Apache）就寫入一個集中式的快取區了，這個快取區的資料再非同步更新到資料庫。好像什麼問題到了多隆手裡，總能迎刃而解。
我對技術大牛很崇拜，欽佩他們的技術，看到他們在淘寶網業務爆炸的場景下披荊斬棘，克服萬難，解決了各種技術問題， 心想： “要是自己能經歷一番多好！”。
從世俗角度來看，多隆大神是成功者，是阿里合夥人。他選擇了阿里，他在阿里奮鬥，他見證了阿里從小到大的過程，然後他就成功了。
選擇大於能力， 事業成就人，做創造價值的事情。
3。 分散式java應用
這本書的作者是阿里畢玄老師。書的脈絡如下：
1、jvm知識
2、集合包
3、併發包
4、效能調優
5、高可用方案
6、構建可伸縮系統
這本書可用說真正從技術體系層面打通了我的任督二脈，層層推進，由淺入深，讓我領略到不同高度的風景。
有時候，我甚至把這本書當做面試寶典來看。
4。 大型網站系統與JAVA中介軟體實踐
這本書的作者是前淘寶曾憲傑老師。 讀完這本書後，我對rpc，分庫分表，訊息佇列，註冊中心（配置中心）有了更深入的認識，也為我後來在架構部中介軟體團隊做的事情打下了基礎。
很感謝曾老師，我在閱讀這本書的時候，曾就書中jdbc名詞的釋義有疑問，給他發了一封郵件。本以為是很小的問題，曾老師也許不會回覆。但他快速很真誠的回覆我說是書中有筆誤了。
所以，在我後來的職業生涯裡面，我也儘量告訴我自己： 對待新手要有耐心，也許你不經意的善意，會對別人的職業生涯產生積極的影響。
寫在最後
故不積跬步，無以至千里；不積小流，無以成江海。騏驥一躍，不能十步；駑馬十駕，功在不捨。鍥而舍之，朽木不折；鍥而不捨，金石可鏤。
JavaScript聖經讓我學會堅忍，淘寶技術這十年讓我擺脫井底之蛙的狀態，分散式java應用讓我體系化的學習java這門語言，大型網站系統與JAVA中介軟體實踐讓我深刻的理解java中介軟體的原理。
2019年，我離開北京，回到武漢。 臨行前，我把在北京買的技術書一部分送給了小夥伴們，希望他們能夠成長為更加優秀的工程師，職業生涯更絢麗點。
有點遺憾是，我在北京沒有培養更多的技術人員，讓他們技術的起點更高點。
明天就是2021年了，別了艱難而又充滿希望的2020年，需要多讀點書。。。。。
