丨架構設計流程詳細方案設計

MySQLNginxNginx，Nginx可以看到，詳細設計方案里面其實也有一些和備選方案類似。例如，Ngnx均衡策略，備選有輪詢、權重分配、phfairh段的問題類似，但實際上這里的技術方案選擇是很輕量級的像備選方案階段那樣操作，而只需要簡單根據這些技術的適用場景選擇就可以了。例如，Nginx的負載均衡策略，簡單按照下面的規(guī)則選擇就可以了。果后端服務器“down掉”，能自動剔除。每個請求按IP的hash結果分配，這樣每個訪客固定一個后端服務器，主要用于解決session的問題，如購物車類的應用。按后端服務器的響應時間來分配請求，響應時間短的優(yōu)先分配，能夠最大化地平衡各后端服務器的壓力，可以適用于后端服務器性能不均衡的情況，也可以防止某臺后端服務器性能不足的情況下還繼續(xù)接收同樣多的請求從而造成雪崩效應。按URL的hash結果來分配請求，每個URL定向到同一個后端服務器，適用于后端服務器能夠將URL的響應結果緩存的情況。例如，比如一個架構，由于和session比較強相關，因此如果用Nginx來做集群負載均衡，那么選擇ip_hash策略是比較合適的。設計階段遇到種況就詳細階段備選不可一般情況下主要的原因是備選方案設計時遺漏了某個關鍵或者關鍵的質量屬性。1年時間，最后只得廢棄原來的備選，重整項標、和方這個的主就備選評估略了開發(fā)周期這個質量屬性。tsh作為全文搜索解決方案，前提必須是架構師自己對tsh的設計原理有深入的理解，比如索引、副本、集群等；而不能道聽lastih“PPT通過分步驟、分階段、分系統(tǒng)等方式，盡量降低方案復雜度節(jié)整個方案的可能性就越高，適當降低復雜性，可以減少這種風險。如果方案本身就很復雜，那就采取設計團隊慧和經驗，防止只有2個架構師可能出現的思維盲點或者經驗盲區(qū)。雖然我們上期在“浪消息隊列的架構設計挑選了備選方案2作為最方案，但備下面我列出一些備選方案2典型的需要細化的點供參考，有的同學可以自己嘗試細化細化設計點1：數據庫設計兩類表，一類是日志表，用于消息寫入時快速到MySQL中；另一類是日志表表名為MQ_LOG，包含的字段：日志ID、發(fā)布者信息、、隊列名稱、消ID（遞增生成）、消息內容、消息發(fā)布時日志表需要及時清除已經寫入消息表的日志數據，消息表最多保存30天的消息數據。細化設計點2：數據如何直接采用MySQL主從即可，只消息表，不日志表細化設計點3：采用ZooKeeper來做主備決策，主備服務器都連接到ZooKeeper建立自己的節(jié)點，主服務器的路徑規(guī)則為“/MQ/server/分區(qū)編號/master”，備機為“/MQ/server/分區(qū)編號/slave”，節(jié)點類型為EPHEMERAL細化設計點消息隊列系統(tǒng)提供K供各業(yè)務系統(tǒng)調用，DK置所息隊統(tǒng)的務K采取輪詢算法發(fā)起消息寫入請求給主服務器。如果某個主服務器無響應或者返回錯誤，K將發(fā)起請求發(fā)送到下一臺服務器。細化設計點5：業(yè)務服務器如何消息消息隊列系統(tǒng)提供SDK供各業(yè)務系統(tǒng)調用，SDK從配置中所有消息隊列系統(tǒng)的服務細化設計點6：協議用TCP，數據格式為ProtocolBuffer。這就是今天的全部內容，留一道思考題給你吧，你見過“PPT 售賣。頁面已增加防盜追蹤，將依 上一 12|架構設計流程：評估和選擇備選方下一 14|高性能數據庫集群：讀寫分正是那朵玫 88穩(wěn)健的少 作者回復: 13李志 作者回復:公司還要架構師么蝸 10 9空檔滑 這上面靠，比如對mysql很熟悉所以設計出的系統(tǒng)大量用到mysql過程，3.設計出來的作者回復:架構師手里有一把錘子，然后所有的問題都是釘子我的名字叫 4 寫。請指教。 3在這個備選方案中，我們設計一個日志表，假設名稱叫MQ_LOG，包含ID,time,queueName, 約書 31Jolie 作者回復:燃燒的阿 3…微 1 1作者回復:你這種叫“系統(tǒng)分析師”或者“解決方案架構師”更貼切王天 之前有個所謂的架構師同事，落地任何項目，他到網上找到一個技術dem演示一遍后他就撒手不管了，做進一步的指導?？陬^禪是“我是架構師”潛臺詞是，我負責搭一個理論架