如何識別架構(gòu)方案是否合理

工程師成長到一個階段之后就需要做架構(gòu)設(shè)計了，當(dāng)然這個架構(gòu)背后的scope是不一樣的，有的架構(gòu)是圍繞一個系統(tǒng)，有的是某個方向解決方案架構(gòu)，更高級別的是整個部門的整體架構(gòu)。

架構(gòu)也分為技術(shù)架構(gòu)和業(yè)務(wù)架構(gòu)，技術(shù)架構(gòu)可以認(rèn)為是偏底層的解決方案，比如異地多活，多機房容災(zāi)。

業(yè)務(wù)架構(gòu)是圍繞于某一個領(lǐng)域的具體業(yè)務(wù)而來的。那在架構(gòu)評審時如何判斷架構(gòu)方案是否合理，并提出建設(shè)性建議呢？

降低復(fù)雜度

首先需要你的解決方案不要過于復(fù)雜，復(fù)雜問題的解決方案往往是簡單的，如果用一個簡單的方法解決了一個復(fù)雜的問題，架構(gòu)師的價值則更大。

一個方案如果足夠簡單，那么就值得依賴，過于復(fù)雜的方案就會顯得過于剛性，缺少容錯能力。

做架構(gòu)方案首先要認(rèn)清一個事實，架構(gòu)是不斷演進(jìn)的。

唯一的不變是變化，相信很多同學(xué)剛接觸軟件開發(fā)時都聽過這句話。

好的或者合理的架構(gòu)不是一蹴而就的，是不斷迭代而來的，沒有人能完整預(yù)測整個項目的死亡，但是需要具備一定的前置視野，級別不同要求程度不同，比如半年、一年、三年，時間越久越抽象，越短越具體。

基于這個事實，架構(gòu)合理性的一點要求就是【可擴展性】。

怎么理解呢？

在我理解，架構(gòu)是元素+連接的組合。

元素越多越復(fù)雜、連接越多越復(fù)雜。不同環(huán)境之下不同元素本質(zhì)也越來越復(fù)雜，綜合起來，架構(gòu)的復(fù)雜度就體現(xiàn)出來了。

解決架構(gòu)復(fù)雜度就是解決元素復(fù)雜度和連接復(fù)雜度。

元素復(fù)雜度與連接復(fù)雜度的解決方案抽象看起來就是SOLID。連接解決的好，就決定了架構(gòu)擴展性好。

連接宏觀上包含了服務(wù)之間的連接、應(yīng)用服務(wù)與存儲服務(wù)的連接，數(shù)據(jù)中心的連接，這種連接的處理需要提供普世的通信協(xié)議；微觀上包含了函數(shù)之間、類之間、模塊之間，這種連接的處理需要SOLID。

領(lǐng)域思想

領(lǐng)域思想是非常好的復(fù)雜度解決方法論，他告訴我們從業(yè)務(wù)視角去看系統(tǒng)、看邊界，這樣可以更好的和業(yè)務(wù)迭代貼近，降低因為需求變得引起的架構(gòu)大的調(diào)整，而且領(lǐng)域驅(qū)動中有很多其他的方法論對于架構(gòu)治理非常重要，越大的組織、架構(gòu)復(fù)雜度效果越好，比如上下文、邊界、UL、事件風(fēng)暴、用戶地圖、運營操作地圖等。

分治思想

分久必合、合久必分。相信大家都聽過，微服務(wù)也好、servicemesh也好、領(lǐng)域驅(qū)動也好、分布式服務(wù)也好，背后都是分治的思想。

為什么分？

分可以很好的把復(fù)雜問題分拆成一個個的簡單問題，治理起來也就容易了。我們可以做橫向拆分、縱向拆分、讀寫分離、一主多從、多主多從等。

怎么分更合理呢？

因為分了后續(xù)就需要考慮合，需要考慮治理成本，除此之外還包括多冗余一份數(shù)據(jù)，最終一致性問題等。

穩(wěn)定性完備

如果說做架構(gòu)是設(shè)計高樓大廈的話，那么再高大上的高樓，如果坍塌了啥也不是。所以，一定把底線守住。

需要關(guān)注于鏈路上服務(wù)的高可用，哪些是單點、哪些需要做容錯。

好的架構(gòu)方案需要體現(xiàn)出對于穩(wěn)定性及性能的關(guān)注，比如上線初期是否存在問題？問題的比重什么樣？需要采用怎樣的降級邏輯與預(yù)案？

綜合來說系統(tǒng)的可觀測性就很重要，監(jiān)控、打點、報警幫助我們開了上帝之眼，發(fā)現(xiàn)那些難以發(fā)現(xiàn)的問題。

另一種體現(xiàn)穩(wěn)定性意識的是，每次需求變更都需要進(jìn)行核心鏈路的測試、代碼監(jiān)測、壓測等。