本系列是極客時間《從0開始學架構》的讀書筆記。我們已經知道了架構設計的定義、歷史源流、**等等背景知識。
對應《08 | 架構設計三原則》既然架構設計關鍵在於取捨，那取捨的依據原則是什麼？
作者提出了三條原則：合適、簡單、演化。合適優於業界領先。簡單優於複雜。演化優於一步到位。
這三條看起來簡單，但想想還真就是這麼一回事。
對應《09 | 架構設計原則案例》
對應《10 | 架構設計流程：識別複雜度》我們已經知道複雜度的**有高效能、高可用、高擴充套件等多個方面。針對不同的業務場景，肯定有不同的側重，各個**的優先順序也肯定不同。所謂「要抓主要矛盾」，先解決最突出的問題。此篇中，作者舉例「前浪微博」，分析其業務，分別就高效能、高可用等多方面進行定量分析，找到關鍵的複雜度**，並採用合適的技術。
「對於架構師來說，常見系統的效能量級需要爛熟於心，例如nginx負載均衡效能是3萬左右，mc的讀取效能5萬左右，kafka號稱百萬級，zookeeper寫入讀取2萬以上，http請求訪問大概在2萬左右。除了這些比較通用的外，其他系統就需要我們自己去測量，並定義指標了。另外，已知的指標肯定是和資料型別，或者業務場景所繫結的，如果這兩者有較大的變化，也需要再次測量。具體的數值和機器配置以及測試案例有關，但大概的量級不會變化很大。
如果是業務系統，由於業務複雜度差異很大，有的每秒500請求可能就是高效能了，因此需要針對業務進行效能測試，確立效能基線，方便後續架構設計做比較。」
架構師需要知道通用技術的各項指標外，更需要有測量指標的能力。
除了能夠找到關鍵點外，定量分析後還可增加架構選型的說服力。
對應《11 | 架構設計流程：設計備選方案》識別複雜度後，就可以設計方案了。
架構設計的本質是取捨，那理論上是不存在最完美的方案。
而對於三原則的著重點不同，也可設計出多個方案。一般來講需要做3到5個備選方案。這些備選方案間要有足夠明顯的差異。值得一提的是，這些方案都是可行的，只是側重點不同而已，不可行的話不可以作為備選方案。
如果是多個架構師來設計，那肯定沒有完全相同的。
那如果是乙個架構師呢？這裡其實對架構師提出了兩個要求。第乙個是不能偷懶，只提出乙個方案。第二個是不能侷限於熟悉的技術，應該選擇更合適的技術，而且對於一項技術，需要對基本使用、關鍵技術、優缺點、關鍵效能指標都有了解。可見，這兩點要求是讓架構師跳出舒適區，是反人性的。
如果只有乙個方案，有可能會有以下問題：沒有想全面，出現盲區；架構師會為方案設計過度辯護；架構師本身經驗和技能有侷限性，有可能是不準確的；著重與細節。
可見，對於架構師的要求還是挺高的。不僅要能夠跳出舒適區，還需要對常見的技術都有數。這樣才能夠在設計備選方案階段，能夠對不同的場景，挑選出合適的技術，並將它們組合起來，進行修改或調整，形成方案。
當然，如果最終的方案還是不符合要求，那就需要創新了。
對應《12 | 架構設計流程：評估和選擇備選方案》找出評估點，比如效能、可用性、成本（硬體+人工+軟體）、技術棧、擴充套件性、安全、時間……然後按照優先順序選擇。
理論步驟就這樣，但是如何討論決定就涉及各個團隊之間的均衡了。
對應《13 | 架構設計流程：詳細方案設計》在此步，需要將方案涉及的關鍵技術落地。也就是各個技術細節。
1、傳送端和消費端如何定址利用zookeeper做註冊中心，把broker的位址註冊到zk上，傳送端和消費端只要配置註冊中心的位址即可獲取集群所有broker位址，當有broker下線時，傳送端和消費端能及時更新broker位址。
2、傳送端訊息重試
當傳送訊息發生網路異常時（不包括超時異常），可以重新選擇下一台broker來重試傳送，重試策略可以自定義。
3、訊息消費採用pull還是push？
考慮push模式會更複雜，故放棄，採用pull模式，消費端主動去拉，為了達到與push模式相同的低延遲效果，可以採用長輪詢的方式，消費端輪詢拉取訊息消費，當有訊息可消費時，返回訊息，如果沒有可消費的訊息，掛起當前執行緒，直到超時或者有可消費的訊息為止。
4、訊息重複問題
訊息中介軟體不解決訊息重複的問題，有業務系統自己根據業務的唯一id去重。
5、順序訊息
傳送端在發生順序訊息時，只傳送到相同broker的相同佇列，消費端消費時，順序訊息只能由同乙個消費端訊息。
6、定時訊息
傳送端指定訊息延時多長時間消費，broker端定時掃瞄定時訊息，達到延時時間的訊息加入到消費佇列。
7、事務訊息
傳送端分兩步，先預傳送訊息，broker端只記錄訊息為預傳送狀態，再執行本地事務，然後再根據本地事務的成功或者失敗傳送確認訊息（回滾還是提交），這步如果發生異常，broker啟動定時任務，把未確認的訊息傳送給傳送端回查事務狀態（需要傳送端提供回查介面）。
《從0開始學架構》 什麼是架構設計
本系列是極客時間 從0開始學架構 的讀書筆記。對應 01 架構到底是指什麼？架構是頂層設計 框架是面向程式設計或配置的半成品 元件是從技術維度上的復用 模組是從業務維度上職責的劃分 系統是相互協同可執行的實體。按照我的理解，架構的維度是最大的，一般我們會講業務架構和技術架構兩類。而框架重在提供一種約...
從0開始學架構 推薦
程式設計師的成長繞不開架構設計，有時架構設計就像鴻溝一樣擋在程式設計師晉公升之路上，只要跨過去就可以海闊天空。但不少技術能力很強的程式設計師依然不能完全掌握架構設計，這與架構設計的思維方式和訓練機制與寫 有很大差異有關，加之人們對架構設計存在很多誤區，缺乏一套行之有效的架構設計方 就可能導致在實踐過...
學習 從0開始學架構 5
儲存高可用方案的本質都是通過將資料複製到多個儲存裝置，通過資料冗餘的方式來實現高可用，其複雜性主要體現在如何應對複製延遲和中斷導致的資料不一致問題 主備 讀寫主機，備機 主要還是起到乙個備份作用，並不承擔實際的業務讀寫操作 主從 主機讀寫，從機讀 雙機切換 狀態判斷 切換決策 中介式 主機和備機不再...