程序員如何蛻變成架構(gòu)師-魔扣目錄

程序員更多的關(guān)注的是局部，而架構(gòu)師則是全局，這個(gè)蛻變的過(guò)程，是一個(gè)長(zhǎng)期積累的過(guò)程，是一個(gè)需要量變的過(guò)程，最后才能從量變轉(zhuǎn)化為質(zhì)變，成為一名合格的架構(gòu)師。

一、什么是架構(gòu)

架構(gòu)是系統(tǒng)與子系統(tǒng)、模塊與組件、框架與架構(gòu)以及它們之間的協(xié)作關(guān)系、約束規(guī)范、指導(dǎo)原則。
架構(gòu)的本質(zhì)是對(duì)系統(tǒng)進(jìn)行有序化地重構(gòu)，使其符合當(dāng)前業(yè)務(wù)的發(fā)展，并可以快速擴(kuò)展。
什么樣的系統(tǒng)要考慮做架構(gòu)設(shè)計(jì)

需求相對(duì)復(fù)雜.
非功能性需求在整個(gè)系統(tǒng)占據(jù)重要位置.
系統(tǒng)生命周期長(zhǎng),有擴(kuò)展性需求.
系統(tǒng)基于組件或者集成的需要.
業(yè)務(wù)流程再造的需要.

二、架構(gòu)分類(lèi)

架構(gòu)可分為業(yè)務(wù)架構(gòu)、應(yīng)用架構(gòu)、技術(shù)架構(gòu), 代碼架構(gòu), 部署架構(gòu)。

業(yè)務(wù)架構(gòu)是戰(zhàn)略，應(yīng)用架構(gòu)是戰(zhàn)術(shù)，技術(shù)架構(gòu)是裝備。其中應(yīng)用架構(gòu)承上啟下，一方面承接業(yè)務(wù)架構(gòu)的落地，另一方面影響技術(shù)選型。

業(yè)務(wù)架構(gòu)

包括業(yè)務(wù)規(guī)劃，業(yè)務(wù)模塊、業(yè)務(wù)流程，對(duì)整個(gè)系統(tǒng)的業(yè)務(wù)進(jìn)行拆分，對(duì)領(lǐng)域模型進(jìn)行設(shè)計(jì)，把現(xiàn)實(shí)的業(yè)務(wù)轉(zhuǎn)化成抽象對(duì)象。
沒(méi)有最優(yōu)的架構(gòu)，只有最合適的架構(gòu)，一切系統(tǒng)設(shè)計(jì)原則都要以解決業(yè)務(wù)問(wèn)題為最終目標(biāo)，脫離實(shí)際業(yè)務(wù)的技術(shù)情懷架構(gòu)往往會(huì)給系統(tǒng)帶入大坑，任何不基于業(yè)務(wù)做異想天開(kāi)的架構(gòu)都是耍流氓。
所有問(wèn)題的前提要搞清楚我們今天面臨的業(yè)務(wù)量有多大，增長(zhǎng)走勢(shì)是什么樣，而且解決高并發(fā)的過(guò)程，一定是一個(gè)循序漸進(jìn)逐步的過(guò)程。合理的架構(gòu)能夠提前預(yù)見(jiàn)業(yè)務(wù)發(fā)展1~2年為宜。這樣可以付出較為合理的代價(jià)換來(lái)真正達(dá)到技術(shù)引領(lǐng)業(yè)務(wù)成長(zhǎng)的效果。

2.應(yīng)用架構(gòu)

劃分

1）、職責(zé)劃分: 明確應(yīng)用（各個(gè)邏輯模塊或者子系統(tǒng)）邊界

a. 邏輯分層

b. 子系統(tǒng)、模塊定義。

c. 關(guān)鍵類(lèi)。

2）、職責(zé)之間的協(xié)作：

a. 接口協(xié)議：應(yīng)用對(duì)外輸出的接口。

b. 協(xié)作關(guān)系：應(yīng)用之間的調(diào)用關(guān)系。

應(yīng)用分層有兩種方式:

1）、水平分（橫向），按照功能處理順序劃分應(yīng)用，比如把系統(tǒng)分為web前端/中間服務(wù)/后臺(tái)任務(wù)，這是面向業(yè)務(wù)深度的劃分。

2）、垂直分（縱向），按照不同的業(yè)務(wù)類(lèi)型劃分應(yīng)用，比如進(jìn)銷(xiāo)存系統(tǒng)可以劃分為三個(gè)獨(dú)立的應(yīng)用，這是面向業(yè)務(wù)廣度的劃分。

總結(jié)：業(yè)務(wù)架構(gòu)、應(yīng)用架構(gòu)、技術(shù)架構(gòu)三者之間，應(yīng)用架構(gòu)是個(gè)承上啟下的連接作用，應(yīng)用架構(gòu)依賴業(yè)務(wù)架構(gòu)，同時(shí)又影響技術(shù)架構(gòu)。

應(yīng)用架構(gòu)的本質(zhì)是通過(guò)系統(tǒng)拆分，平衡業(yè)務(wù)和技術(shù)復(fù)雜性，保證系統(tǒng)形散神不散。

3.代碼架構(gòu)（也叫開(kāi)發(fā)架構(gòu)）

公司統(tǒng)一代碼架構(gòu)，如果不同開(kāi)發(fā)團(tuán)隊(duì)使用不同的技術(shù)棧或者組件，結(jié)果公司整體架構(gòu)設(shè)計(jì)就會(huì)失控

代碼架構(gòu)主要定義：

1）、代碼單元

a. 配置設(shè)計(jì)

b. 框架、類(lèi)庫(kù)

2）、代碼單元組織：

a. 編碼規(guī)范，編碼的慣例

b. 項(xiàng)目模塊劃分

c .頂層文件結(jié)構(gòu)設(shè)計(jì)，比如mvc設(shè)計(jì)

d.依賴關(guān)系

4.技術(shù)架構(gòu)

技術(shù)架構(gòu)：確定組成應(yīng)用系統(tǒng)的實(shí)際運(yùn)行組件（lvs，Nginx，Tomcat，php-fpm等），這些運(yùn)行組件之間的關(guān)系，以及部署到硬件的策略。

技術(shù)架構(gòu)主要考慮系統(tǒng)的非功能性特征，對(duì)系統(tǒng)的高可用、高性能、擴(kuò)展、安全、伸縮性、簡(jiǎn)潔等做系統(tǒng)級(jí)的把握。

5.部署拓?fù)浼軜?gòu)

三、架構(gòu)設(shè)計(jì)的3個(gè)原則

1、簡(jiǎn)單

1）組件越多，就越有可能其中某個(gè)組件出現(xiàn)故障

2）某個(gè)組件改動(dòng)，會(huì)影響關(guān)聯(lián)的所有組件

3）定位一個(gè)復(fù)雜系統(tǒng)中的問(wèn)題總是比簡(jiǎn)單系統(tǒng)更加困難

總結(jié)：簡(jiǎn)單優(yōu)于復(fù)雜，無(wú)論是結(jié)構(gòu)的復(fù)雜性，還是邏輯的復(fù)雜性，都會(huì)存在各種問(wèn)題，所以架構(gòu)設(shè)計(jì)時(shí)如果簡(jiǎn)單的方案和復(fù)雜的方案都可以滿足需求，最好選擇簡(jiǎn)單的方案

2、合適

合適優(yōu)于業(yè)界領(lǐng)先，根據(jù)自身實(shí)際情況，采用適合自己的業(yè)務(wù)，應(yīng)用，技術(shù)架構(gòu)，不能生搬硬套。這也是哲學(xué)上所說(shuō)的，客觀決定主觀。

3、演化

演化優(yōu)于一步到位

首先，設(shè)計(jì)出來(lái)的架構(gòu)要滿足當(dāng)時(shí)的業(yè)務(wù)需要。
其次，架構(gòu)要不斷地在實(shí)際應(yīng)用過(guò)程中迭代，保留優(yōu)秀的設(shè)計(jì)，修復(fù)有缺陷的設(shè)計(jì)，改正錯(cuò)誤的設(shè)計(jì)，去掉無(wú)用的設(shè)計(jì)，使得架構(gòu)逐漸完善。
第三，當(dāng)業(yè)務(wù)發(fā)生變化時(shí)，架構(gòu)要擴(kuò)展、重構(gòu)，甚至重寫(xiě)；代碼也許會(huì)重寫(xiě)，但有價(jià)值的經(jīng)驗(yàn)、教訓(xùn)、邏輯、設(shè)計(jì)等（類(lèi)似生物體內(nèi)的基因）卻可以在新架構(gòu)中延續(xù)。

四、架構(gòu)的演進(jìn)

業(yè)務(wù)架構(gòu)決定應(yīng)用架構(gòu)，應(yīng)用架構(gòu)需要適配業(yè)務(wù)架構(gòu)，并隨著業(yè)務(wù)架構(gòu)不斷進(jìn)化，同時(shí)應(yīng)用架構(gòu)依托技術(shù)架構(gòu)最終落地。

架構(gòu)演進(jìn)路程：?jiǎn)误w應(yīng)用->分布式應(yīng)用服務(wù)化-> 微服務(wù)->service mesh

1、單體應(yīng)用

非功能性需求的做法：

1）、性能需求：使用緩存改善性能

2）、并發(fā)需求：使用集群改善并發(fā)

3）、讀寫(xiě)分離：數(shù)據(jù)庫(kù)地讀寫(xiě)分離

4）、使用反向代理和cdn加速

5）、使用分布式文件和分布式數(shù)據(jù)庫(kù)

缺點(diǎn)

1）、復(fù)雜度高

2）、耦合性高

3）、可靠性差

4）、擴(kuò)展性差

2、分布式應(yīng)用

該架構(gòu)相對(duì)于單體架構(gòu)來(lái)說(shuō)，這種架構(gòu)提供了負(fù)載均衡的能力，大大提高了系統(tǒng)負(fù)載能力，解決了網(wǎng)站高并發(fā)的需求。另外還有以下特點(diǎn)：

1）降低了耦合度：把模塊拆分，使用接口通信,降低模塊之間的耦合度。

2）責(zé)任清晰：把項(xiàng)目拆分成若干個(gè)子項(xiàng)目，不同的團(tuán)隊(duì)負(fù)責(zé)不同的子項(xiàng)目。

3）擴(kuò)展方便：增加功能時(shí)只需要再增加一個(gè)子項(xiàng)目，調(diào)用其他系統(tǒng)的接口就可以。

4）部署方便：可以靈活的進(jìn)行分布式部署。

5）提高代碼的復(fù)用性：比如Service層，如果不采用分布式rest服務(wù)方式架構(gòu)就會(huì)在手機(jī)Wap商城，微信商城，PC，Android，IOS每個(gè)端都要寫(xiě)一個(gè)Service層邏輯，開(kāi)發(fā)量大，難以維護(hù)一起升級(jí)，這時(shí)候就可以采用分布式rest服務(wù)方式，公用一個(gè)service層。

缺點(diǎn)：系統(tǒng)之間的交互要使用遠(yuǎn)程通信，接口開(kāi)發(fā)增大工作量，但是利大于弊。

3、微服務(wù)應(yīng)用

微服務(wù)的特點(diǎn)：

1）、易于開(kāi)發(fā)和維護(hù)：一個(gè)微服務(wù)只會(huì)關(guān)注一個(gè)特定的業(yè)務(wù)功能，所以它業(yè)務(wù)清晰、代碼量較少。開(kāi)發(fā)和維護(hù)單個(gè)微服務(wù)相對(duì)簡(jiǎn)單。而整個(gè)應(yīng)用是由若干個(gè)微服務(wù)構(gòu)建而成的，所以整個(gè)應(yīng)用也會(huì)被維持在一個(gè)可控狀態(tài)。

2）、單個(gè)微服務(wù)啟動(dòng)較快：單個(gè)微服務(wù)代碼量較少，所以啟動(dòng)會(huì)比較快

3）、局部修改容易部署：單體應(yīng)用只要有修改，就得重新部署整個(gè)應(yīng)用，微服務(wù)解決了這樣的問(wèn)題。一般來(lái)說(shuō)，對(duì)某個(gè)微服務(wù)進(jìn)行修改，只需要重新部署這個(gè)服務(wù)即可。

4）功能純粹、耦合性低：服務(wù)拆分，每個(gè)服務(wù)功能單一，耦合性低

缺點(diǎn)：運(yùn)維要求較高、分布式固有的復(fù)雜性、接口調(diào)整成本高

4、service mesh

微服務(wù)的下一個(gè)階段，即service mesh

Service Mesh 的核心其實(shí)就2個(gè)模塊：SideCar 與 Control Plane

用來(lái)解決微服務(wù)架構(gòu)中服務(wù)間可靠調(diào)用、服務(wù)治理等問(wèn)題

大家有興趣可以專(zhuān)門(mén)研究一下，在此不做過(guò)多講述

五、衡量架構(gòu)的合理性

架構(gòu)為業(yè)務(wù)服務(wù)，沒(méi)有最優(yōu)的架構(gòu)，只有最合適的架構(gòu)，架構(gòu)始終以高效，穩(wěn)定，安全為目標(biāo)來(lái)衡量其合理性。

1、穩(wěn)定性