原文鏈接: https://blog.csdn.net/qq_38619183/article/details/107578076
這篇文章只是我對(duì)于架構(gòu)認(rèn)識(shí)的一些觀點(diǎn)影锈，如果您不認(rèn)同我的觀點(diǎn)或想和我討論的話佛析，十分歡迎評(píng)論指教。希望本文能幫助您在架構(gòu)設(shè)計(jì)的路上多一點(diǎn)思考。
本篇文章主要講架構(gòu)的一些定義和架構(gòu)師的職責(zé)，最后還有一些如何設(shè)計(jì)架構(gòu)的原則和觀點(diǎn)。在開始正文前我先拋出3個(gè)問題:
- 什么是架構(gòu)? 框架冷守、架構(gòu)、模塊剪况、組件的區(qū)別與聯(lián)系是什么?
- 架構(gòu)師的定義是什么? 他到底是做什么的? 什么是稱職的架構(gòu)師?
- 架構(gòu)師如何設(shè)計(jì)出高性能教沾、高擴(kuò)展性、高可用性的架構(gòu)?
1. 架構(gòu)
1.1 什么是架構(gòu)
先看看wiki百科給的架構(gòu)的定義:
軟件架構(gòu)是一個(gè)系統(tǒng)的草圖译断。軟件架構(gòu)描述的對(duì)象是直接構(gòu)成系統(tǒng)的抽象組件。各個(gè)組件之間的連接則明確和相對(duì)細(xì)致地描述組件之間的通訊或悲。在實(shí)現(xiàn)階段孙咪，這些抽象組件被細(xì)化為實(shí)際的組件，比如具體某個(gè)類或者對(duì)象巡语。在面向?qū)ο箢I(lǐng)域中翎蹈，組件之間的連接通常用接口來實(shí)現(xiàn)。
軟件架構(gòu)本質(zhì)是為了滿足客戶需求而需要的設(shè)計(jì)方案男公，它描述模塊荤堪、組件以及它們之間的關(guān)系。其實(shí)wiki百科中給的解釋還把軟件架構(gòu)和建筑物的架構(gòu)作類比枢赔，但我認(rèn)為它們之間是有很大的不同的澄阳。
軟件擁有一個(gè)很大的特點(diǎn)，就是易變性踏拜，他所依賴的需求不穩(wěn)定碎赢。所以要求架構(gòu)師所創(chuàng)造的東西具有足夠的靈活性，并且能夠根據(jù)用戶的需求進(jìn)行演化速梗。
1.2 那框架和架構(gòu)到底是什么關(guān)系呢? 模塊和組件是什么關(guān)系呢?
框架是: 為了實(shí)現(xiàn)某個(gè)業(yè)界標(biāo)準(zhǔn)或完成特定基本任務(wù)的軟件組件規(guī)范肮塞，也指為了實(shí)現(xiàn)某個(gè)軟件組件規(guī)范時(shí)，提供規(guī)范所要求之基礎(chǔ)功能的軟件產(chǎn)品姻锁。
- 可以舉例出: MVC框架枕赵，springMVC框架就是其中的一個(gè)特別實(shí)現(xiàn)。它定義了一組軟件規(guī)范位隶，并且以注解的形式提供了該框架的基礎(chǔ)功能拷窜。
模塊和組件的關(guān)系其實(shí)只是角度上的差別。模塊設(shè)計(jì)的作用是職責(zé)分離; 組件設(shè)計(jì)的作用是單元復(fù)用。
- 從軟件邏輯上看装黑，一個(gè)大的學(xué)生管理系統(tǒng)可以劃分為學(xué)生登入管理系統(tǒng)副瀑、學(xué)生信息管理系統(tǒng)等;
- 從物理角度看，又可以看成數(shù)據(jù)庫組件恋谭、ngix組件等糠睡。
1.3 架構(gòu)要素和架構(gòu)設(shè)計(jì)套路
設(shè)計(jì)一個(gè)架構(gòu)要注意什么方面呢(可能不完善還請(qǐng)見諒):
- 職責(zé)明確的模塊和組件(高內(nèi)聚和低耦合的體現(xiàn))
- 組件間明確的關(guān)聯(lián)關(guān)系(一對(duì)多?一對(duì)一?多對(duì)多?)
- 詳細(xì)清晰的約束和指導(dǎo)原則(例如:單一原則、里式替換原則疚颊、開閉原則以及依據(jù)業(yè)務(wù)自定義的其他原則等)
以下是架構(gòu)師的一般性設(shè)計(jì)套路狈孔，關(guān)于架構(gòu)師定義和職責(zé)相關(guān)的在后文會(huì)提及:
- 定義問題->確定架構(gòu)->提出方案->落地。
一個(gè)架構(gòu)設(shè)計(jì)最難得地方就是定義問題的部分: 什么是最需要注意? 什么是系統(tǒng)的瓶頸所在? 在這一步要看清主次矛盾材义，但也要注意主次矛盾是會(huì)互相變換的(從這點(diǎn)看均抽，架構(gòu)師還需要點(diǎn)哲學(xué)的思想呢哈哈)。
例如當(dāng)業(yè)務(wù)比較小時(shí)其掂，特別是初創(chuàng)公司油挥，可能成本是首要矛盾，而對(duì)于大型公司款熬、或業(yè)務(wù)從小發(fā)展到大深寥，成本可能不再是首要矛盾，TPS贤牛、QPS這些性能方面的東西可能是首要注意點(diǎn)惋鹅。
而對(duì)于定位問題，要有打破砂鍋問到底精神(5why分析法)殉簸，如下圖所示闰集，最初知識(shí)想要提升用戶體驗(yàn)，但隨著不斷的深入研究探索般卑，發(fā)現(xiàn)了更多的需要注定的點(diǎn)武鲁，這時(shí)架構(gòu)師可能就得利用自己經(jīng)驗(yàn)來判斷出哪個(gè)才是首要矛盾。
架構(gòu)設(shè)計(jì)如此復(fù)雜且吃經(jīng)驗(yàn)椭微，那有沒有一些架構(gòu)設(shè)計(jì)的原則指導(dǎo)呢?
1.4 架構(gòu)設(shè)計(jì)原則
雖然架構(gòu)設(shè)計(jì)總是伴隨著需求的不確定性洞坑、技術(shù)選型的復(fù)雜性，但架構(gòu)設(shè)計(jì)還是可以總結(jié)出三個(gè)原則蝇率，分別是: 合適原則迟杂、簡單原則、演化原則本慕。
1.4.1 合適原則
看業(yè)務(wù)是否需要排拷，是否必要、是否合適锅尘。很多技術(shù)人員成為架構(gòu)師總是會(huì)有一些技術(shù)上的渴求监氢，想要設(shè)計(jì)出最牛的最好的架構(gòu)布蔗，但往往這樣的架構(gòu)要么設(shè)計(jì)不出來，要么復(fù)雜度太高浪腐，實(shí)現(xiàn)成本太高纵揍。
架構(gòu)設(shè)計(jì)是服務(wù)于業(yè)務(wù)的。架構(gòu)設(shè)計(jì)的本質(zhì)其實(shí)是取舍(這就需要架構(gòu)師擁有足夠的技術(shù)儲(chǔ)備)议街，架構(gòu)設(shè)計(jì)沒有銀彈泽谨，只有針對(duì)不同的業(yè)務(wù)情況進(jìn)行設(shè)計(jì)才能設(shè)計(jì)出好的架構(gòu)。
舉一個(gè)學(xué)生管理系統(tǒng)的例子: 作為學(xué)生管理系統(tǒng)特漩，進(jìn)入流量的大小大致是有數(shù)而且不大的吧雹，不需要進(jìn)行高性能的設(shè)計(jì)，高可擴(kuò)展性也是不太需要的涂身，但如果數(shù)據(jù)庫宕機(jī)了甚至機(jī)器壞了雄卷，學(xué)生數(shù)據(jù)就得管理人員一條一條的輸入，這是很麻煩的蛤售，所以需要足夠的可用性丁鹉。
1.4.2 簡單原則
能用簡單的技術(shù)滿足需要就不要給自己的團(tuán)隊(duì)增加工作量。在合適原則的基礎(chǔ)上盡量選擇團(tuán)隊(duì)成員最熟悉的悍抑，技術(shù)上實(shí)現(xiàn)最簡單的鳄炉。越復(fù)雜的技術(shù)對(duì)研發(fā)人員的要求就越高，維護(hù)的成本也會(huì)增加搜骡。
1.4.3 演化原則
不要試圖一開始進(jìn)行"長遠(yuǎn)考慮"，過度的提前設(shè)計(jì)只會(huì)把整個(gè)團(tuán)隊(duì)拖入泥潭佑女。
要做好不斷迭代優(yōu)化的準(zhǔn)備记靡，在開發(fā)的層面上可以采用敏捷開發(fā)的思想(敏捷開發(fā)也說明過度設(shè)計(jì)是弊大于利的)。
雖然說架構(gòu)師所要設(shè)計(jì)的業(yè)務(wù)需求是不斷變化的(特別是當(dāng)今的互聯(lián)網(wǎng)行業(yè))团驱，但要想捕捉到未來的需求是十分難的摸吠，首先是確定未來可能的需求變化，接著針對(duì)這種變化進(jìn)行針對(duì)性設(shè)計(jì)嚎花〈缌。可是誰也不能保證架構(gòu)師所預(yù)計(jì)的需求變化真的會(huì)發(fā)生。如果不發(fā)生紊选，輕則浪費(fèi)了研發(fā)資源啼止，重則對(duì)之后的開發(fā)還有負(fù)面影響。
架構(gòu)師要審慎的進(jìn)行"面向未來"設(shè)計(jì)兵罢，畢竟沒有一種架構(gòu)設(shè)計(jì)是銀彈献烦，不要太深入到一種架構(gòu)設(shè)計(jì)中去，保留足夠的變更空間卖词。
2. 架構(gòu)師
軟件架構(gòu)的功能是控制軟件的復(fù)雜度巩那。軟件架構(gòu)師的工作就是控制軟件的復(fù)雜度。
軟件的復(fù)雜度在于一臺(tái)機(jī)器和不同機(jī)器間。例如: 同一臺(tái)機(jī)器內(nèi)有同步/異步的選型; 不同的機(jī)器間有狀態(tài)機(jī)的選型即横。
自從軟件出生以來噪生，軟件開發(fā)和軟件的復(fù)雜度一直如影隨行。從最早的機(jī)器語言东囚，到中低級(jí)編程語言跺嗽，到軟件工程、面向?qū)ο蟪霈F(xiàn)舔庶，都在處理軟件復(fù)雜的的問題抛蚁。但是軟件復(fù)雜度的解決方案也沒有銀彈。之后軟件規(guī)模越來越大惕橙，甚至出現(xiàn)了分布式的軟件系統(tǒng)瞧甩，對(duì)于大型軟件，架構(gòu)設(shè)計(jì)越來越有必要弥鹦。
2.1 架構(gòu)師職責(zé)
讓我看看看wiki上的定義:
是在信息系統(tǒng)研發(fā)中肚逸，負(fù)責(zé)依據(jù)需求來確定主要的技術(shù)選擇、設(shè)計(jì)系統(tǒng)的主體框架結(jié)構(gòu)彬坏，并負(fù)責(zé)搭建實(shí)施的人朦促。[1] 他們（與系統(tǒng)分析師共同）確立系統(tǒng)的主體架構(gòu)和實(shí)現(xiàn)方向，并負(fù)責(zé)指導(dǎo)軟件工程師等開發(fā)人員的編碼開發(fā)工作栓始。
讓我抽取出一些核心的概念: 技術(shù)選擇务冕、負(fù)責(zé)搭建實(shí)施、指導(dǎo)軟件工程師幻赚。
在目前的業(yè)界情況禀忆，其實(shí)還可以用五個(gè)字來概括軟件架構(gòu)師: 人、財(cái)落恼、物箩退、是、事佳谦。其實(shí)軟件架構(gòu)師管理的不僅僅是軟件戴涝，還有管理團(tuán)隊(duì)。敏捷開發(fā)和<<微服務(wù)設(shè)計(jì)>>都說明:
在最理想的情況下钻蔑，架構(gòu)師應(yīng)該和開發(fā)人員一起編碼啥刻，如果架構(gòu)師實(shí)在很忙那也應(yīng)該和開發(fā)人員一起工作。
架構(gòu)師本質(zhì)工作是管理人員矢棚，或者就是管理開發(fā)人員郑什。所以系統(tǒng)架構(gòu)的設(shè)計(jì)也需要和團(tuán)隊(duì)組織結(jié)構(gòu)具有足夠的一致性。技術(shù)選型也是如此蒲肋。
不僅不能成為所謂的"ppt架構(gòu)師"蘑拯，也不能成為架構(gòu)設(shè)計(jì)出來后就甩手而去的"架構(gòu)師"钝满。架構(gòu)師在團(tuán)隊(duì)開發(fā)的過程中要保證團(tuán)隊(duì)具有良好的開發(fā)節(jié)奏(開發(fā)、測(cè)試申窘、部署弯蚜，做好增量開發(fā)部署的準(zhǔn)備)，把握好開發(fā)進(jìn)度(立會(huì)制度就很好)剃法。此處額外說明下: 立會(huì)就是站著開會(huì)的意思碎捺，在立會(huì)上不要深入討論開發(fā)細(xì)節(jié)，主要目的是了解開發(fā)進(jìn)度贷洲，最好時(shí)間控制在10~15m之間收厨。同時(shí)也能培養(yǎng)出"代碼集體所有制"的氛圍，避免單人負(fù)責(zé)導(dǎo)致思維盲點(diǎn)优构。
同時(shí)诵叁，擁抱變化而不要畏懼變化。
2.2 架構(gòu)設(shè)計(jì)淺談
2.2.1 CAP原理
CAP三個(gè)大寫字符分別是: Consistency(一致性)钦椭、Availability(可用性)拧额、Partition tolerance(分區(qū)容忍性)。
C和A比較好理解彪腔，那P是什么意思呢? 我的理解是: 忍的是"同步時(shí)間差"侥锦。在多實(shí)例下，實(shí)例間的狀態(tài)同步需要一定的時(shí)間德挣，所以多實(shí)例下P必然要成立恭垦。
更多CAP的相關(guān)信息可以看這里: https://zhuanlan.zhihu.com/p/20399316
2.2.2 高性能、高可用格嗅、高擴(kuò)展相關(guān)
高性能和高可用本質(zhì)上都是通過加機(jī)器來實(shí)現(xiàn)署照。高性能目標(biāo)的加機(jī)器叫擴(kuò)展，高可用的加機(jī)器叫冗余吗浩。
高性能是軟件架構(gòu)最復(fù)雜的地方。軟件架構(gòu)的復(fù)雜性在高性能上可以體現(xiàn)在兩個(gè)方面:
- 單臺(tái)計(jì)算機(jī)內(nèi)部復(fù)雜度: 線程\進(jìn)程没隘、阻塞\非阻塞等懂扼。
- 多臺(tái)機(jī)器之間的復(fù)雜交互: 異步\同步、消息隊(duì)列右蒲、請(qǐng)求/響應(yīng)阀湿、事件/訂閱等。
高可用加機(jī)器是為了擴(kuò)展性能瑰妄，往往伴隨著狀態(tài)決策機(jī)制陷嘴。狀態(tài)決策機(jī)制有三種:
- 獨(dú)裁式。一臺(tái)機(jī)器進(jìn)行狀態(tài)決策间坐，可用性不夠灾挨。
- 協(xié)商式邑退。主備或主從形式。
- 民主式劳澄。zookeeper中的paxos變體算法就是民主式地技。民主式會(huì)有一個(gè)"腦裂"的問題(因?yàn)橥ㄐ攀?dǎo)致有多個(gè)決策主體發(fā)布狀態(tài)信息)，所以往往要求超過一半的投票次數(shù)滿足了才能通過對(duì)應(yīng)的"提議"秒拔。
高可用分為計(jì)算高可用莫矗、存儲(chǔ)高可用、應(yīng)用高可用砂缩。常見的高可用方案有加機(jī)器且負(fù)載均衡路由作谚、冗余備份、超時(shí)設(shè)置庵芭、異步調(diào)用(解耦)妹懒、服務(wù)降級(jí)保護(hù)、監(jiān)控告警喳挑、灰度發(fā)布和回滾機(jī)制等彬伦。
高擴(kuò)展性的設(shè)計(jì)在飛快變化的需求面前往往是必不可少的。設(shè)計(jì)高可用的架構(gòu)首先在于識(shí)別業(yè)務(wù)可能會(huì)發(fā)生的變化伊诵。識(shí)別出變化點(diǎn)后单绑，套用高耦合低內(nèi)聚的原則、單一原則曹宴、依賴倒置原則等搂橙，模塊和模塊間的通信也設(shè)計(jì)成盡量穩(wěn)定的或易于修改的(客戶端和服務(wù)端公用一套公共庫是一件很糟糕的事情)。
設(shè)計(jì)高擴(kuò)展性架構(gòu)時(shí)同時(shí)要記住不要過度設(shè)計(jì)笛坦。大服務(wù)拆分成小服務(wù)比小服務(wù)設(shè)計(jì)出來后不合適于業(yè)務(wù)要重新開發(fā)成本要低多了区转。
關(guān)于高擴(kuò)展性的更多可以參考這里: https://www.cnblogs.com/dimmacro/p/4568905.html
2.2.3 安全、成本
安全也是架構(gòu)的一個(gè)重要方面版扩，架構(gòu)安全可以大致分為兩個(gè)方面:
- 功能安全
- 架構(gòu)安全
功能安全像是防小偷废离，大致可能的威脅來源有:XSS漏洞、CSRF漏洞礁芦、SQL漏洞蜻韭、越權(quán)漏洞等。
架構(gòu)安全像是防強(qiáng)盜柿扣，往往類型像是給架構(gòu)一記重重拳擊肖方，動(dòng)輒幾十上百TB的流量沖擊，擊穿緩存未状、擊垮數(shù)據(jù)庫等俯画。
成本對(duì)于架構(gòu)設(shè)計(jì)來說，相當(dāng)于一個(gè)約束司草。在設(shè)計(jì)高可用艰垂、高擴(kuò)展等"高"架構(gòu)時(shí)泡仗，成本往往是對(duì)這些追求的限制，要想突破限制只能通過創(chuàng)新來實(shí)現(xiàn)既降低成本又"高"的架構(gòu)材泄。
參考資料
- 高可用: https://zhuanlan.zhihu.com/p/28059511
- 高性能: https://my.oschina.net/jayqqaa12/blog/3161787
- https://www.cnblogs.com/dimmacro/p/4568905.html
- <<微服務(wù)設(shè)計(jì)>>
- <<高效程序員的45個(gè)習(xí)慣>>
- 極客時(shí)間: 從0開始學(xué)架構(gòu)
