架構設計流程：詳細方案設計
極客時間：《從 0 開始學架構》:架構設計流程：詳細方案設計
1、引言
上一章節完成了備選方案的設計和選擇，接下來便是對備選方案進行細化，使得備選方案變成一個可以落地的設計方案。
2、架構設計第四步：詳細方案設計
詳細方案設計就是將方案涉及的關鍵技術細節確定下來
Nginx 的負載均衡策略，可按照下面的規則選擇即可。
- 輪詢（預設）
每個請求按時間順序逐一分配到不同的後端伺服器，後端伺服器分配的請求數基本一致，如果後端伺服器“down 掉”，能自動剔除。 - 加權輪詢
根據權重來進行輪詢，權重高的伺服器分配的請求更多，主要適應於後端伺服器效能不均的情況，如新老伺服器混用。 - ip_hash
每個請求按訪問 IP 的 hash 結果分配，這樣每個訪客固定訪問一個後端伺服器，主要用於解決 session 的問題，如購物車類的應用。 - fair
按後端伺服器的響應時間來分配請求，響應時間短的優先分配，能夠最大化地平衡各後端伺服器的壓力，可以適用於後端伺服器效能不均衡的情況，也可以防止某臺後端伺服器效能不足的情況下還繼續接收同樣多的請求從而造成雪崩效應。 - url_hash
按訪問 URL 的 hash 結果來分配請求，每個 URL 定向到同一個後端伺服器，適用於後端伺服器能夠將 URL 的響應結果快取的情況。
這幾個策略的適用場景區別還是比較明顯的，根據我們的業務需要，挑選一個合適的即可。例如，比如一個電商架構，由於和 session 比較強相關，因此如果用 Nginx 來做叢集負載均衡，那麼選擇 ip_hash 策略是比較合適的。
詳細設計方案階段可能遇到的一種極端情況就是在詳細設計階段發現備選方案不可行，一般情況下主要的原因是備選方案設計時遺漏了某個關鍵技術點或者關鍵的質量屬性，如開發週期。
Tips：
- 架構師不但要進行備選方案設計和選型，還需要對備選方案的關鍵細節有較深入的理解。如：架構師選擇了 Elasticsearch 作為全文搜尋解決方案，前提必須是架構師自己對 Elasticsearch 的設計原理有深入的理解，比如索引、副本、叢集等技術點；不能道聽途說Elasticsearch很牛，所以選擇它，更不能成為把“細節不討論”掛在嘴邊的“PPT架構師”
- 通過分步驟、分階段、分系統等方式，儘量降低方案複雜度，方案本身的複雜度越高，某個細節推翻整個方案的可能性就越高，適當降低複雜性，可以減少這種風險。
- 如果方案本身就很複雜，那就採取設計團隊的方式來進行設計，博採眾長，彙集大家的智慧和經驗，防止只有 1~2 個架構師可能出現的思維盲點或者經驗盲區
“前浪微博”訊息佇列的架構設計備選方案2上的的詳細設計
1、傳送端和消費端如何定址
利用zookeeper做註冊中心，把broker的地址註冊到zk上，傳送端和消費端只要配置註冊中心的地址即可獲取叢集所以broker地址，當有broker下線時，傳送端和消費端能及時更新broker地址。
2、傳送端訊息重試
當傳送訊息發生網路異常時（不包括超時異常），可以重新選擇下一臺broker來重試傳送，重試策略可以自定義。
3、訊息消費採用pull還是push？
考慮push模式會更復雜，故放棄，採用pull模式，消費端主動去拉，為了達到與push模式相同的低延遲效果，可以採用長輪詢的方式，消費端輪詢拉取訊息費，當有消費可消費時，返回訊息，如果沒有可消費的訊息，掛起當前執行緒，直到超時或者有可消費的訊息為止。
4、訊息重複問題
訊息中介軟體不解決訊息重複的問題，有業務系統自己根據業務的唯一id去重。
5、順序訊息
傳送端在發生順序訊息時，只發送到相同broker的相同佇列，消費端消費時，順序訊息只能由同一個消費端訊息。
6、定時訊息
傳送端指定訊息延時多長時間消費，broker端定時掃描定時訊息，達到延時時間的訊息加入到消費佇列。
7、事務訊息
傳送端分兩步，先預傳送訊息，broker端只記錄訊息為預傳送狀態，再執行本地事務，然後再根據本地事務的成功或者失敗傳送確認訊息（回滾還是提交），這步如果發生異常，broker啟動定時任務，把未確認的訊息傳送給傳送端回查事務狀態（需要傳送端提供回查介面）。