《交易系統：更新與跨越》讀後感

十一假期，原本想找一本書讀一讀。機緣巧合就找到了這本《交易時間》。這本書主要講了上海證券交易系統在技術管理、架構設計、應用調優、切換部署、運行維護等方面的經驗和教訓。成書的時間大概是在2010年，交易系統的上線時間大概在2008年，聚如今已經接近十年了，可是書中介紹的不少開發時候的原則和思路放在今天來看也有很大的價值能夠學習。同時，這也是一本介紹大型系統開發的簡要過程的參考書目。

本書涉及了很多的證券相關知識，涉及證券知識的章節我就略讀作了解。對剩下的關於大型系統的設計，管理，架構，優化相關的章節進行了精讀，記錄相關筆記供本身回顧和思考。

大型系統的管理

團隊管理：

將整個系統自上而下的分割爲多個鬆耦合的且相對獨立的系統，這樣來避免出現整個系統級的問題，遇到問題分而治之。在系統初期設計系統時隱藏細節實現，提早發現系統整體架構上的缺陷，提早修正。各個獨立的小系統可用分別的啓動，評審，開發測試。
配合系統分制的結構，人員也分解爲小團隊。團隊目標一致，團隊內的文檔，設計，代碼均是公開的，團隊成員都是知曉的。

系統的設計和開發過程當中，團隊成員在有紀律和規則的前提下進行發散和創新。團隊中應該有一我的來確保，討論之後收斂結論，保證團隊「有序」和「規則」。無限的發散只會帶來大量內耗。

項目質量

這一部分，沒有什麼爭議，對於測試的重要性，應該已是開發人員公認的公理。

保證測試時間。

測試範疇推廣，做者指出，不但要對代碼進行測試，還須要對文檔，設計提早測試。

糾錯優於創新。

面向変更

看完做者這一部分的描寫，簡直不能贊成更多。

這一章的第一個小標題就是「爲了未來丟棄而如今建設」。大型系統的開發不是一蹴而就的，不少系統的第一版都是不太能使人滿意的，因此不斷的重構是一直貫穿到系統的生命週期之中的。做者所謂的「爲了未來丟棄而如今建設」，就是開發過程當中準備在未來用更高效的和更易於擴展的代碼來替代目前正在編寫的模塊。
重構的過程當中，要有精肯定義的需求爲指導。不然重構結果並不樂觀。
系統的不斷演進和需求不斷的增長，會致使系統代碼混亂，「熵」不斷增長。重構就是爲了減小系統的「熵」。
系統的不斷開發中，會產生「死代碼」，須要及時去除。重構中要考慮去除複製張貼的代碼，並把這些代碼抽象爲公共庫。

需求的變動是常態，開發中不該該抗拒和討厭，對變動進行管理。開發過程當中應該爲變動作好準備。可是一個系統不能「普遍參數化」。平衡度也很關鍵。

系統架構

系統設計目標

在設計開始前應當估計系統的極限，留有必定的安全餘量，進行開發。

在大型系統設計中，一直性是重要的考量，有的時候能夠犧牲不規則的特性和改進，保證一致性。同時應當保證一致性的文檔應該落地。

高內聚低耦合，這個原則應該是咱們初學編程就一直強調的原則，咱們應該保證模塊之間的正交性質。保證低耦合，咱們應該作的就是強制接口定義，隱藏實現細節，不使用公共的數據結構。所謂高內聚是指一個模塊只實現一個功能。高內聚的軟件易於維護和改進。

系統應當適當的進行「過分設計」，提高系統的靈活性。

使用「打包」提高系統的吞吐量。一個是「時間片」，定時進行打包操做一次請求。二是收集足夠多的的處理請求後打包處理。在系統優化的過程當中，一個是優化算法的實現，二是使用空間換時間的。

高可用的設計，使用「持久化」和「冗餘」提高系統的高可靠性。

系統的高擴展性，經過如下方式提高：

• 按照功能劃分模塊獨立部署
• 按照負載劃分系統
• 避免分佈式事務
• 在模塊間使用異步處理

系統設計原則

系統分層設計，系統設計成金字塔型，越核心的測系統，設備接入越少，關係越簡單，可靠性越高。

故障隔離設計。

無單點。

消息驅動模型的設計：

• 前臺發消息無ack重發
• 後臺消息處理須要冪等
• 消息在每一個界定啊都被存儲並加標記

其實這個設計，很相似Kafka的實現。

調優原則

先將單機的能力提高，再水平擴展

對大量訪問的數據，使用內存方式提升速度（如今看來就是使用緩存），結合磁盤「持久化」。

優化核心算法。

使用異步I/O。

傳輸壓縮，打包和流控技術。

後記

這本書，提出的一些系統設計和開發原則，如今看來大部分已經在我接觸過的的系統中大量的使用。可見系統的基本設計原則，通過快十年的發展也沒有太大的變化。十年前的一些原則已經有不少成熟的技術實現了。大型系統的開發逐漸變得容易，系統的設計人員能夠將更多的精力來組合各個成熟實現，快速搭建系統。推薦這本書給你們，感覺大型系統構建的各個方面細節，開闊視野。