1、極客時間13 | 架構設計流程：詳細方案設計2018-05-26 13 | 架構設計流程：詳細方案設計- 00:00 / 08:58完成備選方案的設計和選擇后，我們終于可以長出一口氣，因為整個架構設計最難的一步已經完成了，但整體方案尚未完成，架構師還需繼續努力。接下來我們需要再接再勵，將最終確定的備選方案進行細化，使得備選方案變成一個可以落地的設計方案。所以 我來講講架構設計流程第4步：詳細方案設計。架構設計第4步：詳細方案設計簡單來說，詳細方案設計就是將方案涉及的 細節給確定下來。假如我們確定使用Elasticsearch來做全文搜索，那么就需要確定Elasticsearch的索引是按照業務

2、劃分，還是一個大索引就可以了；副本數量是2個、3個還是4個，集群節點數量是3個還是6個等。假如我們確定使用MySQL分庫分表，那么就需要確定哪些表要分庫分表，按照什么維度來分庫分表，分庫分表后聯合 怎么處理等。假如我們確定引入Nginx來做負載均衡，那么Nginx的主備怎么做，Nginx的負載均衡策略用哪個（權重分配？輪詢？ip_hash？）等?？梢钥吹?，詳細設計方案里面其實也有一些 和備選方案類似。例如，Nginx的負載均衡策略，備選有輪詢、權重分配、ip_hash、fair、url_hash五個，具體選哪個呢？看起來和備選方案階段 的問題類似，但實際上這里的技術方案選擇是很輕量級的，我們無

3、須像備選方案階段那樣操作，而只需要簡單根據這些技術的適用場景選擇就可以了。例如，Nginx的負載均衡策略，簡單按照下面的規則選擇就可以了。輪詢（默認）每個請求按時間順序逐一分配到不同的后端服務器，后端服務器分配的請求數基本一致，如果后端服務器“down掉”，能自動剔除。加權輪詢根據權重來進行輪詢，權重高的服務器分配的請求 ，主要適應于后端服務器性能不均的情況，如新老服務器混用。ip_hash每個請求按 IP的hash結果分配，這樣每個訪客固定 一個后端服務器，主要用于解決session的問題，如購物車類的應用。fair按后端服務器的響應時間來分配請求，響應時間短的優先分配，能夠最大化地平衡各后

4、端服務器的 ，可以適用于后端服務器性能不均衡的情況，也可以防止某臺后端服務器性能不足的情況下還繼續接收同樣多的請求從而造成雪崩效應。url_hash按 URL的hash結果來分配請求，每個URL定向到同一個后端服務器，適用于后端服務器能夠將URL的響應結果緩存的情況。這幾個策略的適用場景區別還是比較明顯的，根據我們的業務需要，挑選一個合適的即可。例如，比如一個電商架構，由于和session比較強相關，因此如果用Nginx來做集群負載均衡，那么選擇ip_hash策略是比較合適的。詳細設計方案階段可能遇到的一種 情況就是在詳細設計階段發現備選方案不可行， 情況下主要的 是備選方案設計時遺漏了某個

5、點或者關鍵的質量屬性。例如，我曾經參與過一個項目，在備選方案階段確定是可行的，但在詳細方案設計階段，發現由于細節點太多，方案非常龐大，整個項目可能要開發長達1年時間，最后只得廢棄原來的備選方案，重 新調整項目目標、計劃和方案。這個項目的主要失誤就是在備選方案評估時忽略了開發周期這個質量屬性。幸運的是，這種情況可以通過下面方式有效地避免：架構師不但要進行備選方案設計和選型，還需要對備選方案的關鍵細節有較深入的理解。例如，架構師選擇了Elasticsearch作為全文搜索解決方案，前提必須是架構師 hongfenghuoju/78852018/8/6 9:14:24對Elasticsearch的設

6、計原理有深入的理解，比如索引、副本、集群等 ；而不能道聽途說Elasticsearch很牛，所以選擇它，更不能成為把“細節我們不討論”這句話掛在嘴邊的“PPT架構師”。通過分步驟、分階段、 方式，盡量降低方案復雜度，方案本身的復雜度越高，某個細節 整個方案的可能性就越高，適當降低復雜性，可以減少這種風險。如果方案本身就很復雜，那就采取設計團隊的方式來進行設計，博采眾長，匯集大家的智慧和經驗，防止只有12個架構師可能出現的思維盲點或者經驗盲區。詳細方案設計實戰雖然我們上期在“前浪 ”消息隊列的架構設計挑選了備選方案2作為最終方案，但備選方案設計階段的方案粒度還比較粗，無法真正指導開發 進行后續的

7、設計和開發，因此需要在備選方案的基礎上進一步細化。下面我列出一些備選方案2典型的需要細化的點供參考，有 的同學可以 嘗試細化 的設計點。1. 細化設計點1：數據庫表如何設計？數據庫設計兩類表，一類是日志表，用于消息寫入時快速 到MySQL中；另一類是消息表，每個消息隊列一張表。業務系統發布消息時，首先寫入到日志表，日志表寫入 就代表消息寫入 ； 線程再從日志表中 消息寫入 ，將消息內容寫入到消息表中。業務系統 消息時，從消息表中 。日志表表名為MQ_LOG，包含的字段：日志ID、發布者 、 、隊列名稱、消息內容。消息表表名就是隊列名稱，包含的字段：消息ID（遞增生成）、消息內容、消息 、消息發

8、布者。日志表需要及時清除已經寫入消息表的日志數據，消息表最多保存30天的消息數據。2. 細化設計點2：數據如何 ？直接采用MySQL主從 即可，只 消息 表，不 日志表。3. 細化設計點3：主備服務器如何倒換？采用ZooKeeper來做主備決策，主備服務器都連接到ZooKeeper建立 的節點，主服務器的路徑規則為“/MQ/server/分區編號/master”，備機為“/MQ/server/分區編號/slave”，節點類型為EPHEMERAL。備機 主機的節點消息，當發現主服務器節點斷 ，備服務器修改 的狀態，對外提供消息 服務。4. 細化設計點4：業務服務器如何寫入消息？消息隊列系統設計兩

9、個角色：生產者和消費者，每個角色都有唯一的名稱。消息隊列系統提供SDK供各業務系統調用，SDK從配置中 所有消息隊列系統的服務器 ，SDK采取輪詢算法發起消息寫入請求給主服務器。如果某個主服務器無響應或者返回錯誤，SDK將發起請求發送到下一臺服務器。5. 細化設計點5：業務服務器如何 消息？消息隊列系統提供SDK供各業務系統調用，SDK從配置中 所有消息隊列系統的服務器 ，輪流向所有服務器發起消息 請求。消息隊列服務器需要 每個消費者的消費狀態，即當前消費者已經 到了哪條消息，當收到消息 請求時，返回下一條未被 的消息給消費者。6. 細化設計點6：業務服務器和消息隊列服務器之間的通信協議如何設

10、計？考慮到消息隊列系統后續可能會對接多種不同編程語言編寫的系統，為了提升兼容性，傳輸協議用TCP，數據格式為ProtocolBufer。當然還有 設計細節就不再一一列舉，因此這還不是一個完整的設計方案，我希望可以通過這些具體實例來說明細化方案具體如何去做。小結我為你講了架構設計流程的第四個步驟：詳細方案設計，并且基于模擬的“前浪 ”消息隊列系統，給出了具體的詳細設計示例，希望對你有所幫助。這個示例并 整，有興趣的同學可以 再詳細思考一下還有哪些 以繼續完善。這就是 的全部內容，留一道思考題給你吧，你見過“PPT架構師”么？他們 都具備什么特點？歡迎你把 寫到留言區，和我一起討論。相信經過深度思

11、考的回答，也會讓你對更加深刻。（編輯亂入：精彩的留言有機會獲得豐厚福利哦！）極客時間正是那朵玫瑰可以完善的細節：1、發送端和消費端如何尋址2018-05-28利用zookeeper做 中心，把broker的地址 到zk上，發送端和消費端只要配置 中心的地址即可獲取集群所以broker地址，當有broker下線時，發送端和消費端 更新broker地址。2、發送端消息重試當發送消息發生網絡異常時（不 超時異常），可以重新選擇下一臺broker來重試發送，重試策略可以自定義。3、消息消費采用pull還是push？考慮push模式會更復雜，故放棄，采用pull模式，消費端主動去拉，為了達到與push模

12、式相同的低延遲效果，可以采用長輪詢的方式，消費端輪詢拉取消息費，當有消費可消費時，返回消息， 如果沒有可消費的消息，掛起當前線程，直到超時或者有可消費的消息為止。4、消息重復問題消息中間件不解決消息重復的問題，有業務系統 根據業務的唯一id去重。5、順序消息發送端在發生順序消息時，只發送到相同broker的相同隊列，消費端消費時，順序消息只能由同一個消費端消息。6、定時消息發送端指定消息延時多長時間消費，broker端定時掃描定時消息，達到延時時間的消息加入到消費隊列。7、事務消息發送端分兩步，先預發送消息，broker端只 消息為預發送狀態，再執行本地事務，然后再根據本地事務的 或者失敗發送

13、確認消息（ 還是提交），這步如果發生異常，broker啟動定時任務，把未確認的消息發送給發送端 事務狀態（需要發送端提供 接口）。目前就想到這么多。作者回復厲害，基本上重點都涵蓋了穩健的少年2018-05-282018-05-26PPT架構師以脫離一線時間較久的領導居多吧。很多技術他們沒有真正使用過，只是從各種途徑得知很強大，其他公司（BAT）都在用，于是就在PPT中寫入這種技術。缺點就是很容易做出貌似 可行，深究其細節的設計。作者回復BAT三個字是設計捷徑，但也很多坑ant2018-05-272018-05-26很有幸我們現在的架構師就是PPT架構師，我覺得他的優點就是懂了很多的概念，能說話

14、到，可以 住 。缺點也很明顯，就是他知道的都不是很深，比如曾經我們的搜索引擎原型，他并不 能說出ES和solr的優缺點(當然我也不知道， 用solr多點)，最后我們選了ES，他給的 就是朋友說的ES比solr好，后面搜索這里就交給我來搞了。我們是互聯網項目，在重構的項目的時候他選擇了jpa，這就導致變化需求的時候， 這塊比較麻煩，不靈活。其實就像前面說的，每個技術 就是合理的，只是每個有每個技術的使用點，架構師應該對常見的技術棧原理非常清楚，知道什么時候應該使用什么技術。我理解的PPT架構師的特點就是知識點多，知道概念，能虎住 ，缺點就是技術棧不咋滴，特別是細節上。我覺得架構師應該幫助員工成長

15、，而不是遇到問題就說這個問題我沒遇到過， 網搜索下解決方案。初次留言，歡迎板磚作者回復架構師確實需要技術面寬，但別只知道技術名詞，基本使用，關鍵原理，優缺點都需要了解蝸牛就一些新的技術引入，架構師需要做哪些技術驗證，或者研究到什么深度以后，才認為該技術適合呢？作者回復基本原理，優點缺點，關鍵設計點，架構師至少要安裝過，編寫demo體驗過，確定選型后，要進行性能和可用性測試例如es的索性設計就是關鍵設計點bluefantasy2018-05-272018-05-262018-05-26請教 ：您說的”日志表是尾部追加，性能高”，這個日志表是用myisam 引擎嗎？我剛剛查了文檔innodb只有系

16、統表空間和日志文件是序列化寫呀，普通表文件都是隨機寫。 請指教。2018-05-28作者回復2018-05-29這個日志表是我們 設計的，不管是innodb還是myisam都可以，我說的尾部追加是指我們只會往日志表 數據，類似kafka的文件尾部追加一樣Jolie Liang對于PPT架構師，總結有以下幾個特點：1） 整體思路照搬2） 不能準確定位業務需要解決的痛點3） 對所需技術的 解不深2018-05-26hongfenghuoju/78852018/8/6 9:14:24極客時間4） 執行到后期，返工及補坑的工作比較多.作者回復PPT可以造火箭，實際實現只能造鞭炮2018-05-27ho

17、ngfenghuoju/78852018/8/6 9:14:24燃燒的業務系統發布消息時，首先寫入到日志表，日志表寫入 就代表消息寫入 ； 線程再從日志表中 消息寫入 ，將消息內容寫入到消息表中。業務系統 消息時，從消息表中 。這里的設計是不是冗余了？作者回復日志表是尾部追加，性能高空檔滑行2018-05-262018-05-272018-05-26真見過PPT架構師，1. 基本不寫代碼，2.對某一項技術比較精通所以架構設計時盡量往這上面靠，比如對mysql很熟悉所以設計出的系統大量用到mysql 過程，3.設計出來的架構完全不考慮老系統兼容或者遷移難度作者回復架構師手里有一把錘子，然后所有的

18、問題都是釘子李志博2018-05-27認識一個工作10多年的架構師，天天只會說代碼命名和注釋的問題，從來沒談過什么的架構，也從來沒見他寫過代碼，有一次我來他來幫我看一個問題，他裝沒聽見，走了2018-05-31作者回復你們公司還要架構師么2018-06-01名字叫 丶我們的架構師連PPT都懶得做。crazyone2018-05-30，"日志表是尾部追加，性能高"，這個具體實施細節能否講解下。2018-05-29作者回復其實高性能的很多 方案都是這樣設計的，MySQL有Binlog，HBase有HLog，道理都是相通的。2018-05-29在這個備選方案中，我們設計一個日志表

19、，假設名稱叫MQ_LOG，包含ID, time, queueName, message, publisher等幾個字段，每次收到消息發布請求時先寫這個表，每次尾部追加。如果不用 設計的日志表，mysql的binlog也類似尾部追加，性能也不錯，缺點就是沒法 靈活實現各種刷盤機制了。Fenlon2018-06-15一樓事物消息 還有種方案就是本地事物解決方案。 消息和業務一塊 本地，只要保證本地消息能被發到broker就好了Sylar.我也沒有明白作者說的日志表尾部追加性能好，具體是什么操作，還望賜教，多謝了！dilei2018-05-282018-05-28看來ppt架構師還是很多的啊，應該推

20、薦他們來看看 的文章o(o)oGarwen，您講的詳細設計示例特別好，我非常想看到一些比較完整的詳細設計文稿，不知可否有推薦。2018-05-28作者回復2018-05-28可以 嘗試，我沒有這幾個備選方案的詳細文檔，內部的方案設計和這個方案不同，而且資料也不能泄露，望諒it2018-05-27這種架構師 不了解技術細節 只了解大體使用哪種技術 技術有哪些限制或者坑了解的不透徹 這樣在細化階段會產生很多問題 這種架構師領導還湊活 落地時大多就會出狀況 由此問 如何快速提升架構硬實力 尤其是當下技術發展迅速 人的精力有限 如何更 進行技術了解與選型ppt架構師共同的特點是:1. 方案設計大多從網

21、上照抄2. 回避別人提出的技術細節問題3. 口頭禪: 別人都是這么用的4. 只會眾多技術名稱的單詞拼寫，而且還經常在交談中時不時的說出一兩個作者回復2018-05-272018-05-27細節不討論，Hook請 指導下：同一個隊列的消息數據是不是被分散到了不同的分區上？此時假如要考慮消息順序性的話，是不是就不滿足了？作者回復是的，保證消息順序很復雜公眾號：歪脖貳點零2018-05-272018-05-27極客時間架構師對個人的知識點、知識面、知識體系要求很高，也就是技術寬度與深度的問題。平常說打雜也不為過，什么都要懂，但不一定都得上手做，要能指引他人按著藍圖去實施，當然碰到棘手問題，還是要深入

22、進去解決。 架構師是體現了一個團隊的技術強度，PPT架構師有時候還是需要做一做，但不能只停留在PPT里，落地實戰同樣不能遜色。作者回復2018-05-272018-05-27hongfenghuoju/78852018/8/6 9:14:24習慣是最好安裝運行，然后寫demo體驗一下，單純看文檔理解還是不夠行用現在很多架構師只關注主流程，大方向，根本不關注細節。導致做出來的東西用戶體驗不好作者回復兩者需要兼顧，把握平衡Tom2018-05-272018-05-27怎么保證日志表所有數據都寫入消息表？日志表是不是要加狀態字段， 線程寫入消息表后更新狀態值。2018-05-26作者回復2018-0

23、5-27以有很多實現方式，限于篇幅無法展開，詳細的設計文檔有幾十頁蔡2018-07-15基本原理，優點缺點，點。親身體驗下Enjoystudy2018-06-28補充幾點:1.應該確保同一個分區只有一個消費者，否則消費的時候還得解決多個消費者拉到相同的消息，而且這塊應該做到一個負載均衡，多個分區應該分給不同的消費者 2.隊列應該做個優先級 ，也就是日志表應該有多個 3.應該有個ack的機制，否則沒法做重試 4.應該支持延時隊列 5.消息的狀態以及下一條消費的游標要區分不同的group軒轅十四日志表尾部寫入的細節還沒理解透。請問如果沒有日志表，直接寫各消息表，不也是尾部追加嗎？這里是否設涉及MY

24、DQL寫文件的細節？作者回復2018-06-272018-06-28各個消息表在磁盤上 的位置不同，會導致磁盤尋址時間較長jiasudd請問 ，架構設計和技術方案設計的界限是什么？感覺架構師很詳細的設計完，開發 只是功能實現會沒有成就感2018-06-19作者回復2018-06-21簡單來說，架構師說用單進程多線程的網絡模型，開發 要具體實現這個模型，里面細節還是很多的vintin2018-06-15MySQL中為什么要設計一張日志表呢？直接根據隊列名稱來路由寫入到對應的消息分表性能豈不是更高？這樣省去了從日志表到消息表的中間環節。如果是為了讀寫分離，轉移線程在寫消息表 的時候業務也在拉消息，

25、也沒有避免。請 指教作者回復日志表是尾部追加，寫入性能高LouisLimTJ2018-06-152018-06-10這可能離題了，主要是管理問題。經過內部的評審機制，阿里的P9存還不 PPT 架構師？SHLOMA有沒有可以開源的架構設計文檔之類的資料，見識見識大廠出品李作者回復2018-06-042018-06-06這是公司 資料，如果你要看開源的，推薦kafka，es，disruptor的技術資料Mars2018-06-04，這個專欄講解架構設計的概念、設計原則、設計規則等主演偏重理論上的設計。對很多沒有親身經歷過架構設計的 又想踏入架構師之旅，文章閱讀之后文中講的理論基本也懂，但要 真正落

26、地恐怕非常難？要是這個專欄之后 能再寫一個專欄，就 “前浪 ”的消息隊列從設計前期、詳細設計、框架搭建、開發實現、最后測試部署的一套流程的專欄。讓我 們親自動手感受從系統設計到最終系統上線的一套完整流程。相信會受很多人歡迎及訂閱。Geek_8242cb多個消費端并發的取消息，如何保證消息的順序性？當前上一個消息的ofset需要保 zookeeper 中嗎？2018-06-02作者回復需要的，可以用zookeeper，也可以用數據庫，redis等，就看你要求多高的性能cinio2018-06-022018-06-02傳統企業及提供服務的架構師就是PPT架構師，這個沒啥辦法，因為和傳統企業的組織機

27、構對應。我認為應該提供一個平衡的 來銜接。按目前 的內容肯定是說服不了現有組織接受設計的。allwmh采用mysql消息 的話 應該不需要狀態了吧？2018-06-01作者回復也需要 消費2018-06-01極客時間小龍2018-06-01架構師需要把框架搭起來嗎？還是只是以文檔形式把方案寫出來，團隊根據文檔搭框架寫代碼？現在的專欄技術都是講解互聯網電商行業的技術及架構，您專欄講的架構知識是否適用于工業領 域？比如自動化碼頭調度 所有自動化 的 系統。hongfenghuoju/78852018/8/6 9:14:24作者回復2018-06-011. 架構師不需要搭框架，但要保證方案可行2.

28、這套架構理論不局限于互聯網 系統，各行業都可以適應售前架構師也是需要，作者大人估計不怎么打標或推新作者回復2018-05-302018-05-30以前在菊花廠答 ，轉移動互聯網就沒做過了正直D2018-05-29看了評論學習到很多，還有不解的地方。如何 消費者的消費狀態，比如正在處理哪些消息， 處理了哪些消息，哪些消息處理失敗了。這些保 消費者端好，還是在消息隊列系統中保存。作者回復2018-05-29是的，限于篇幅無法完整展開，你正好可以根據課程內容， 這個問題來練練手在做架構設計時，為了使甲 得系統規模、技術與合同成本是對等的，不得不進行復雜的架構設計。有的技術可能根本用不到或無需用到，但

29、都要寫到架構設計中，什么技術新這什么，什么 技術看起來這什么。如果不這樣甲方可能覺得錢花多了，這個怎么破？孫曉明作者回復通常情況下，這些要求算架構設計的約束，只能遵守，不能選擇，架構師的任務是如何以最小成本來滿足甲方需求，這也是復雜度之一fuhuoyeyou我 用戶session是不是單獨 呀？如果直接放在業務服務器上，是不是有很多局限性？作者回復2018-05-282018-05-282018-05-282018-05-28可以持久化或者，也可以直接放業務服務器，沒了就重新生成，看你的業務場景下用戶的接受程度了鈺湚隨著做it時間久了，發現好架構真的太少了，上得了廳堂下得了廚房，我們開發團隊挺大的，每個團隊最多也就培養出一兩個人，找個替代很難。作者回復2018-05-282018-05-28架構師比 程序員難找多了2018-05-27設計上是否考慮一致性問題，即連接到不同業務節點，他們連到不同數據庫節點，看到的 是否可能不同?不知道mysql集群是怎么處理的，例如只寫入一個數據庫節點就返回? 是否需要只有master負責寫，所有節點可以讀?作者回復master負責讀寫，slave只在master故障的情況下提供讀操作2018-05-28發消息時，消息寫入日志表