架構評審方法和思路總結

2021-07-24 12:55:08 字數 2583 閱讀 1347

2023年延續2023年的架構和成本優化思路,運營管理部在15年組織各大bg開展了大量的架構評審和成本優化工作。作為規劃組的一員,在全年21個規劃產品的評審中我主要參與了其中11個。在前期和業務產品,開發及運維的交流和準備材料過程中,發現雖然已經經過了一年的評審,溝通和交流,但大家對為什麼要做架構評審,怎樣做架構評審,其中的思路和流程都還存在一定的不了解的地方,所以這裡自己先拋磚引玉,跟大家聊聊討該如何做架構評審。

先來說說裝置

裝置是支撐公司業務運營的最基本實體,隨著公司業務的不斷發展壯大,公司的裝置總數也於去年突破了50w臺大關。評審乙個業務的架構,首先得從其裝置使用的合理性上來看。

總的裝置架構評審思路可以簡單歸納如下4步:

裝置需求驅動形態 -- 確認裝置需求動因和相關指標;

關鍵路徑的技術架構 -- 確認架構是否合理;

需求資源推算模型 -- 資源預算和指標關聯是否合理,架構分布是否合理。

資源優化計畫 -- 後續是否可以釋放部分資源,降低成本。

第一點比較好理解,裝置的需求動因,我們需要描述清楚涉及裝置的關鍵業務指標以及業務指標的變化情況,通常這些指標在做年度預算的時候能夠定義清楚。如果當時沒有清晰的定義,我們這裡可以根據業務的實際資源需求情況來定義清楚關鍵指標。後面3點是乙個架構評審的關鍵所在,我們這裡重點展開來講。

我們談乙個產品的架構,最開始當然先要從一張總架構圖開始講起。比如下面這個手q的訊息互動架構圖。

乙個清晰的架構圖至少需要具備如下要素:

描述總體架構關鍵模組構成和各模組對應的裝置數目;

業務請求互動圖,描述業務關鍵路徑上的模組互動流程,需包含請求量/包量及對應的裝置數;

描述裝置需求中關鍵路徑的構成情況和模組之間的互動邏輯。

定義出關鍵路徑和關鍵業務模組後,這些模組需求和架構是否合理,我們需要把這裡面的內容給評委展開來重點解釋。

針對每乙個關鍵模組,我們首先需要:

描述在總體系統架構中該一級模組的主要核心功能;

描述該核心模組的處理業務邏輯分布,如重要業務邏輯的資源佔比情況。

比如下面手q sso模組的描述

定義出核心關鍵模組之後,我們需要進一步解釋其資源使用的合理性。這裡我們主要針對最常見的處理類和儲存類兩類模組來說明,其他比如吞吐量類,快取類的模組可以依此類推。

針對處理類模組,我們通常需要說明:

給出核心模組的資源模型,如單機每秒建立連線數,每秒包處理能力;

描述核心模組的當前瓶頸所在;

描述核心模組的裝置型別;

描述核心模組的最大支撐能力,如單機峰值qps;

根據預估的業務指標結合模組單機處理能力來評估所需的裝置數。

而對於儲存類的模組,我們通常需要說明:

給出核心儲存單元的資源模型,如每個儲存單元所占用的位元組數,每個儲存單元包括哪些字段資訊,主要欄位的訪問頻次,每份資料儲存份數等,並根據單份的模型結合業務後續預估的指標來估算總體的儲存量;

描述核心儲存單元的當前瓶頸所在。

同時,針對架構分布上,由於公司idc資源的地理分布不平衡性,某些特定的地理區域由於歷史和儲備的原因,idc資源會較為緊缺,所以我們在架構評審的過程中也要對業務模組的物理分布情況來評估其合理性,比如如下兩點:

描述總體現有架構模組的物理分布情況和容量模型,包括架構是否有set化,其set分布,資料的異地儲存份數說明,以及容災方式;

描述新增預算資源的分布模型以及是否可以異地化部署的評估。

在review過架構和模組的現狀後,業務自己通常也會發現一些自己架構上的問題,這些可能是歷史原因的遺留問題,也可能是技術進步發展了有一些更優的解決方案,所以我們在架構評審的最後可以針對這些問題來提出進一步的 優化,給自己定乙個更優的目標,追求技術上更進一步。主要邏輯可以分為下面幾步:

描述可能的柔性策略、優化手段和方法(包括技術上和運營上的);

描述優化後的系統架構圖和模型;

描述優化後的目標和成果

資源的最大化整合和復用:比如運用虛擬化,docker等技術,來講裝置的利用率發揮到最大優勢,充分壓榨單機的處理負載,提高單機的處理能力。

新技術和新處理框架:比如採用新的處理框架,從http協議改為直接tcp處理,從原來的同步qzhttp改為非同步rpc處理,以及充分利用gpu並行能力和fpga可程式設計硬體相比軟體處理的高效性來提高編碼和壓縮的效率等等,來提公升單機的效率。

新協議和新格式的利用:這塊在儲存類服務中最場景,比如用壓縮效率更高的webp來替代傳統的jpeg,然後又採用更高的h.265編碼格式的bgp來替代webp,這些新格式的出現對於日益增長的海量資料又是乙個重要的優化手段。

提公升資源管理和流轉效率:比如資源直供模式,閒置裝置,閒置時段的離線計算使用,比如如何有效的利用儲存類裝置的cpu資源來進行計算,這些也都是架構評審優化中值得考慮的問題。

好了,前面關於裝置上的架構評審流程和方式講了這麼多,相信如果大家都按這麼思路來理解架構評審,再加上自己對業務和技術的充分理解,跟boss過的架構評審將不再是個問題,更多的是對大家技術的展現了。

裝置先講到這裡,有機會我們繼續來解析如何做頻寬的架構評審。see you again!

系統ooa文件 系統架構師之 測試評審方法

下面我們對此概要分享,以助於整體掌控制知識,也方便軟考架構師考試提供參考,不是為了考試而知識,而是因為創造而知識。1 目的 發現軟體中的錯誤 缺陷 2 階段 單元測試unit testing 需要編寫驅動模組或者樁 stub 模組 整合測試integration testing 非漸增式與漸增式 系...

TypeSDK總體設計思路和架構

引言 本文旨在提供讀者製作乙個自己的聚合sdk的思路,拋磚引玉,讓更多的讀者對聚合sdk有好的理解。這是最好的時代,這是最壞的時代,這是智慧型的時代,這是愚蠢的時代 這是信仰的時期,這是懷疑的時期 這是光明的季節,這是黑暗的季節 這是希望之春,這是失望之冬 人們面前有著各樣事物,人們面前一無所有 人...

CRISP DM分析方法和思路

目錄 crisp dm原理及原理圖 1.理解業務需求 2.資料理解 理解業務,探索業務需求中的指標概念和影響因素 3.資料準備 業務資料與分析資料格式不同,需要做轉換 4 模組化 選擇分析技術對資料分析計畫進行模組化 5 評估 從業務角度評估結果 6 部署 實現資料分析應用到業務中 日常專案中的資料...