轉型架構師必讀:實用架構的搭建思路

由於碎片化的時間多了,休閒的時候,我關注了一些架構相關的內容。發現有不少同道中人正在經歷着我前兩年經歷的階段,對於作架構沒有相對具象的一些理解,更沒有系統化的認識。因此,我把看到的問題、回答過的問題中的部份內容整理一下,權當記錄,留給3年後的本身~html

1、架構的定義安全

在軟件開發領域,自從架構這個詞被普遍傳播以後,產生的架構模式也很是多,架構關注點也在增長。但回到「道」的層面,架構的定義或者說本質仍是:性能優化

「架構,又名軟件架構,是有關軟件總體結構與組件的抽象描述,用於指導大型軟件系統各個方面的設計。」——摘自《百度百科》架構

2、架構是作什麼?併發

不少作業務功能的增刪改查開發感覺到無趣的小夥伴常把作架構想象成一片樂土,沒有嘈雜的業務聲音干擾,能夠專心作一番牛X的技術。會把架構單純的理解成,牛X的性能、牛X的TPS、高可用、支撐了多少PV等等。可是其實這些只是架構很小的一部分,並非所有。框架

在互聯網時代以前都是C/S程序的天下,那個時候並無對性能等有像如今這樣的關注度,可是就已經有架構之說了。分佈式

世上本無架構,只是因爲團隊越大越須要對總體的規則作約定,好讓你們往同一個方向發力,避免各自爲戰,產生大量的內耗,因此才逐漸造成了架構。這條路的造成之由就是「世上本無路,只是由於走的人多了變成了路」。模塊化

爲何說一個軟件架構是很重要的呢?微服務

當咱們的團隊人數只有二、3我的,甚至只有1我的單槍匹馬的狀況下,可能架構凸顯的做用並非那麼的明顯。可是若是團隊大了,相信下面的這些現象會比較常見:高併發

新上一個系統,每每不是獨立存在的,通常都須要與現存的系統進行交互,而須要集成交互的地方可能還不少,那麼哪些集成是本系統須要實現的?同時,通常會劃分爲多個階段開發,怎樣界定系統的邊界呢?

軟件系統是一個由多個模塊組成的總體。所以當上遊開發與咱們負責的模塊銜接總是出問題時,本身作再多的努力也沒法扭轉上游模塊質量差帶來的負面效果。(我想你們這時候確定是抓狂的。)

每次看到別人寫的代碼,老以爲本身來寫的話確定不會這麼寫,確定比他寫的更好。(咱們作技術的,自我感受良好是個常態)

在某些場景下,本身腦子裏有多套方案來實現,可是對孰優孰劣沒太大感受,最終基本上就是拍腦殼選了一個。

某塊代碼維護的次數多了,特別是中間由多我的接手事後,代碼風格各異,難以理解。

類似的代碼在好幾個地方出現,特別是一些非業務性的代碼,好比日誌處理等。再甚是在大型的分佈式系統中,不一樣子程序使用了不一樣的同類型中間件,一樣致使維護成本大增。

在2個相依賴項目邊界處的設計產生了分歧,而且站在各自的角度看都有道理。

任何事物都是有兩面性的,並非說有了上面的這些問題,咱們經過架構就要往另一個極端去走。好比在大型的分佈式系統中,不一樣子程序的確有必要在某些時刻選擇同類型的其它中間件。如Kafka和RabbitMQ雖都是MQ,但在特定的場景下能發揮的價值是沒法相互替代的。

因此咱們作架構有一點也是比較重要的,就是去Balance,選擇一個投入產出比最優的方案。關於這點第四段中會多說幾句。

除此以外,架構的主要目的是爲了讓你們往同一個方向,在同一個標準之上去發散擴張。一是把控硬性的下限標準,提升總體的最短版,二是提升上限水平位,也就是天花板位置,提供更大的發展空間。

比如造一幢大樓,把框架結構設計好搭好,讓你們造成一個共識,什麼是承重牆不能破壞,什麼是創變空間能夠自定義。在這樣的基礎下各自發展。

這個看上去是個限制,但倒是作架構最重要的任務,所謂再多的文檔,再多的最佳實踐都比不上一條約束。下降複雜度、下降理解難度,是實實在在的收益。最怕的就是憑空假設帶來的過分浪費。

更甚之,咱們作架構追求的理想國度是一個你們擁有一致共識的世界,架構是你們都像吃飯喝水這樣習覺得常的習慣。去理解或者接手其它人負責的項目的時候就好像是本身寫的同樣。這個時候就消滅架構了,就比如如今沒有人會教你如何吃飯同樣。(就當YY一下吧)

3、作架構的最佳實踐

上面提到更多的是作架構的目的。那麼要作好架構,主要就是要作好抽象。作抽象的方式是類比,作類比的方式可使用用例圖,因此建議你們多畫圖,經過畫圖來將大腦中抽象的結果直觀的體如今前面,再來進一步分析合理性。

主要推薦2種圖的類別,一種就是前面提到的用例圖。以下圖:

另一種是魯棒圖,如圖:

整個過程的主要目的是:

描述其與外部實體(系統和最終用戶)的交互;

標識系統和外部實體間的信息和控制流。

理想的世界裏,咱們程序的邊界設計剛好匹配於業務邊界。然而咱們做爲工程師首先要承擔業務需求的壓力,只能擠時間去作這些非業務性工做。也所以老項目的業務邊界也並不老是如新項目那樣明晰。

這意味着作任何架構的改動要考慮優先級,特別在拆分業務領域以前,要認真地思考業務的邊界,排定優先級,考量拆分的收益與風險。劃分業務的邊界,則須要更多的思考拆分後的將來將如何溝通協做,而後再考慮技術因素。

在技術因素前,主要考量這幾點:

是否擁有獨立的團隊來維護,以及是否擁有發展爲一項獨立業務的潛力。(非必要的狀況下,必定要避免共享內核的開發方式)

圍繞領域而非 feature,有明確的維護團隊,避免過於細粒度。

拆分或者組合以後,可否改善現有的協做流程。

可否幫助區分核心、非核心業務,改善穩定性。

上面這些完成了以後,即是選擇合適的中間件、技術框架來知足技術層面的要求,這個的選拔主要如下面幾點來考量:

若是是直接引入第三方的中間件的話,成熟度如何?是否有大公司在用?(有大公司的口碑背書的確定大大加分)

近期的社區活躍度如何?(用於考量是否有更多的人在一塊兒踩坑,下降各自遇到坑的數量和機率)

硬指標,當前場景的硬性要求是否知足。如性能、對關鍵部分或者將來的可擴展性等。

軟指標,複雜度、可維護性等。這裏能夠羅列幾個競品的優劣勢。

最重要的是要本身去親自驗證上面的幾點,而且作必定的模擬工做。

若是曾經用過或者有其中一部分的經驗可複用,這是加分項,畢竟在使用的過程當中才發現hold不住它,那是災難性的!

4、什麼是好架構

以前有聽到過一句話,歸納的很精闢。好的架構必須須要貼合業務。那麼把業務+技術演變成一個數學公式來表達能夠理解爲:2個數字的和等於10,求如何組合能獲得最大的乘積。那不是3*7,也不是4*6,而是5*5。

因此架構不是生搬硬套,不是爲了架構(搞事情)而架構,趕時髦,或者說裝X。

咱們應避免經過我的的主觀意願來主導。好比本身以爲某個中間件好,就「拿着錘子處處找釘子」,這一敲下來,看着不錯,可是帶來的成本和風險被忽略了。可能有更好的解決方案,或者徹底不必在當下敲這一釘子下去。  

好的架構須要評判投入產出比,收益更高的就是更好的架構,就以下圖的公式:

產出能夠理解爲咱們所以得到的好處(諸如可靠性、安全性、可擴展性、可維護性、可伸縮性、性能等),成本是咱們改造花費的投入,如人力物力和時間。特別注意的是風險這點,是很重要也是很容易被你們忽略的一點,是起到指數級做用的。

選擇的方案再好,若是都是一些hold不住的技術,那麼風險就是無窮大,致使減號右側無限趨近於0,最終的結果就是收益是負數,投入的成本打水漂,甚至還要加上其它額外的付出。

5、如何成爲架構師

上面提到的這些關注點都是架構師的職責,另外特別重要的一點是,架構師必需要是個有追求的「好碼農」(劃重點)。

軟件架構師不像建築師,其面對的自己是一個抽象的事物,若是再脫離了實操,這基本和紙上談兵無異。因此實際工做中的難點、要點都得清楚,而且可以給出解決方案或者方向。另外只有熟悉實操才能更準確的評估成本。

成爲了一個真正的「好碼農」就向架構師邁出第一步了。然後呢,須要不斷以深→廣→深→廣的節奏去開疆擴土,擴大本身的知識領域,固然須要以貼近當前工做內容的知識爲主,這是第二步。到了這還沒完,還有打造三板斧:業務能力、溝通能力、我的魅力。

題外話,在國內,純技術的架構師沒有應用型的架構師吃的開。因此此文皆以應用型架構師的職能要求爲參考。

原文連接:https://dbaplus.cn/news-141-2229-1.html

6、結語

回到文章開頭,架構的表現形式有不少,從本質上單體應用的架構設計思想和分佈式系統是一致的,所謂服務化其實也是模塊化的思想,只是維度的不一樣,致使用到的一些工具或者環境不一樣,但這都是「術」層面的東西。光學這些招數,永遠也學不完。架構之路漫長,繼續前行,共勉。

順便在此給你們推薦一個Java架構方面的交流學習羣:698581634,裏面會分享一些資深架構師錄製的視頻資料:有Spring,MyBatis,Netty源碼分析,高併發、高性能、分佈式、微服務架構的原理,JVM性能優化這些成爲架構師必備的知識體系,主要針對Java開發人員提高本身,突破瓶頸,相信你來學習,會有提高和收穫。在這個羣裏會有你須要的內容  朋友們請抓緊時間加入進來吧。

相關文章
相關標籤/搜索