架構師思想_證券公司IT

關於什麼是架構，一種比較通俗的說法是 “最高層次的規劃，難以改變的決定”，這些規劃和決定奠定了事物未來發展的方向和最終的藍圖。

從這個意義上說，人生規劃也是一種架構。選什麼學校、學什麼專業、進什麼公司、找什麼對象，過什麼樣的生活，都是自己人生的架構。

具體到軟體架構，維基百科是這樣定義的：“有關軟體整體結構與組件的抽象描述，用於指導大型軟體系統各個方面的設計”。系統的各個重要組成部分及其關係構成了系統的架構，這些組成部分可以是具體的功能模組，也可以是非功能的設計與決策，他們相互關係組成一個整體，共同構成了軟體系統的架構。

架構其實就是把複雜的問題抽象化、簡單化，可能你會覺得“說起來容易但做起來難”，如何能快速上手。可以多觀察，根據物質決定意識，藉助生活真實情境（使用者故事，要很多故事）來還原這一系列問題，抓住並提取核心特徵。

架構思想

CPU運算速度>>>>>記憶體的讀寫速度>>>>磁碟讀寫速度

滿足業務發展需求是最高準則
業務建模，抽象和枚舉是兩種方式，需要平衡，不能走極端
模型要能更真實的反應事物的本質，不是名詞概念的堆砌，不能過度設計
基礎架構最關鍵的是分離不同業務領域、不同技術領域，讓整個系統具有持續最佳化的能力。
分離基礎服務、商務規則、商務程序，選擇合適的工具外化商務規則和商務程序
分離業務組件和技術組件，高類聚，低耦合 - 商務資訊的執行可以分散，但商務資訊的管理要盡量集中
不要讓軟體的邏輯架構與最後物理部署綁死 - 選擇合適的技術而不是高深的技術，隨著業務的發展調整使用的技術
好的系統架構需要合適的組織架構去保障 - 團隊成員思想的轉變，漫長而艱難
業務架構、系統架構、資料模型

面對一塊新業務，如何系統架構。

業務分析：輸出業務架構圖，這個系統裡有多少個業務模組，從前台使用者到底層一共有多少層。
系統劃分：根據業務架構圖輸出系統架構圖，需要思考的是這塊業務劃分成多少個系統，可能一個系統能支援多個業務。基於什麼原則將一個系統拆分成多個系統。又基於什麼原則將兩個系統合并成一個系統。
系統分層：系統是幾層架構，基於什麼原則將一個系統進行分層，分成多少層。
模組化：系統裡有多少個模組，哪些需要模組化。基於什麼原則將一類代碼變成一個模組。

如何模組化

基於水平切分。把一個系統按照業務類型進行水平切分成多個模組，比如許可權管理模組，使用者管理模組，各種業務模組等。
基於垂直切分。把一個系統按照系統層次進行垂直切分成多個模組，如DAO層，SERVICE層，商務邏輯層。
基於單一職責。將代碼按照職責抽象出來形成一個一個的模組。將系統中同一職責的代碼放在一個模組裡。比如我們開發的系統要對接多個渠道的資料，每個渠道的對接方式和資料解析方式不一樣，為避免不同渠道代碼的相互影響，我們把各個渠道的代碼放在各自的模組裡。
基於易變和不易變。將不易變的代碼抽象到一個模組裡，比如系統的比較通用的功能。將易變的代碼放在另外一個或多個模組裡，比如商務邏輯。因為易變的代碼經常修改，會很不穩定，分開之後易變代碼在修改時候，不會將BUG傳染給不變的代碼。

提升系統的穩定性

流控
雙11期間，對於一些重要的介面（比如帳號的查詢介面，店鋪首頁）做流量控制，超過閾值直接返回失敗。 另外對於一些不重要的業務也可以考慮採用降級方案，大促—>郵件系統。根據28原則，提前將大賣家約1W左右在緩衝中預熱，並設定起止時間，活動期間內這部分大賣家不發交易寄件提醒，以減輕SA郵件伺服器的壓力。

容災
最大程度保證主鏈路的可用性，比如我負責交易的下單，而下單過程中有優惠的商務邏輯，此時需要考慮UMP系統掛掉，不會影響使用者下單（後面可以通過修改價格彌補），採用的方式是，如果優惠掛掉，重新渲染頁面，並增加ump屏蔽標記，下單時會自動屏蔽ump的代碼邏輯。 另外還會記錄ump系統不可用次數，一定時間內超過閾值，系統會自動警示。

穩定性
第三方系統可能會不穩定，存在介面逾時或宕機，為了增加系統的健壯性，調用介面時設定逾時時間以及異常捕獲處理。

容量規劃
做好容量規劃、系統間強弱依賴關係梳理。 如：冷熱資料不同處理，早期的訂單採用oracle儲存，隨著訂單的數量越來越多，查詢緩慢，考慮資料移轉，引入曆史表，將已歸檔的記錄遷移到曆史表中。當然最好的方法是分庫分表。

分布式架構

分布式系統
分布式緩衝
分布式資料
API 和樂高積木有什麼相似之處。

相信我們大多數人在兒童時期都喜歡玩樂高積木。樂高積木的真正樂趣和吸引力在於，儘管封裝盒外面都帶有示意圖片，但你最終都可以隨心所欲得搭出各種樣子或造型。

對 API 的最佳解釋就是它們像樂高積木一樣。我們可以用創造性的方式來組合它們，而不用在意它們原本的設計和實現意圖。

你可以發現很多 API 和樂高積木的相似之處：

標準化：通用、標準化的組件，作為基本的構建塊（building blocks）；
可用性：強調可用性，附有文檔或使用說明；
可定製：為不同功能使用不同的API；
創造性：能夠組合不同的 API 來創造混搭的結果；
樂高和 API 都有超簡單的介面/介面，並且藉助這樣簡單的介面/介面，它可以非常直觀、容易、快速得構建。

雖然樂高和 API 一樣可能附帶示意圖片或使用文檔，大概描述了推薦玩法或用途，但真正令人興奮的結果或收穫恰恰是通過創造力產生的。

讓我們仔細地思考下上述的提法。在很多情況下，API 的使用者構建出了 API 的構建者超出預期的服務或產品，API 使用者想要的，和 API 構建者認為使用者想要的，這二者之間通常有個斷層。事實也確實如此，在 IoT 領域，我們使用 API 創造出了一些非常有創造性的使用情境。