CSDN看到一篇介紹架構(gòu)設(shè)計(jì)的博客宜狐，內(nèi)容提綱挈領(lǐng)，內(nèi)容豐富岸啡。依據(jù)原文整理原叮，加上自己的理解和總結(jié)。 推薦給大家巡蘸。點(diǎn)擊原文可以查看出處奋隶。

原文鏈接：https://blog.csdn.net/hguisu/article/details/78258430

什么是架構(gòu)和架構(gòu)本質(zhì)

在軟件行業(yè)，對(duì)于什么是架構(gòu)悦荒，都有很多的爭(zhēng)論唯欣，每個(gè)人都有自己的理解。此君說(shuō)的架構(gòu)和彼君理解的架構(gòu)未必是一回事搬味。因此我們?cè)谟懻摷軜?gòu)之前境氢，我們先討論架構(gòu)的概念定義，概念是人認(rèn)識(shí)這個(gè)世界的基礎(chǔ)碰纬，并用來(lái)溝通的手段萍聊，如果對(duì)架構(gòu)概念理解不一樣，那溝通起來(lái)自然不順暢悦析。

Linux有架構(gòu)脐区，MySQL有架構(gòu)，JVM也有架構(gòu)她按，使用Java開(kāi)發(fā)牛隅、MySQL存儲(chǔ)、跑在Linux上的業(yè)務(wù)系統(tǒng)也有架構(gòu)酌泰，應(yīng)該關(guān)注哪一個(gè)媒佣？

想要清楚以上問(wèn)題需要梳理幾個(gè)有關(guān)系又相似的概念：系統(tǒng)與子系統(tǒng)、模塊與組建陵刹、框架與架構(gòu):

區(qū)分系統(tǒng)默伍、模塊、組件、框架和架構(gòu)

S君： 區(qū)分系統(tǒng)也糊、模塊炼蹦、組件、框架和架構(gòu)

• 系統(tǒng)(system)和子系統(tǒng)：有關(guān)聯(lián)的個(gè)體狸剃，根據(jù)某種規(guī)則運(yùn)行掐隐，共同完成獨(dú)特的功能。子系統(tǒng)：系統(tǒng)的組成部分钞馁。

• 模塊(module)和組件(component)：模塊和組件都是系統(tǒng)的組成部分虑省，只是從不同角度拆分系統(tǒng)而已。 從邏輯角度拆分得到的是模塊僧凰，從物理角度拆分得到的是組件探颈。 模塊是為了實(shí)現(xiàn)職責(zé)分離， 組件是為了實(shí)現(xiàn)復(fù)用训措。

• 框架：為了實(shí)現(xiàn)某個(gè)業(yè)界標(biāo)準(zhǔn)或完成特定基本任務(wù)的軟件組件規(guī)范伪节，按照規(guī)范提供所要求基礎(chǔ)功能的軟件產(chǎn)品。

• 架構(gòu)：頂層設(shè)計(jì)

系統(tǒng)與子系統(tǒng)

系統(tǒng)：泛指由一群有關(guān)聯(lián)的個(gè)體組成绩鸣，根據(jù)某種規(guī)則運(yùn)作怀大，能完成個(gè)別元件不能獨(dú)立完成的工作能力的群體。

子系統(tǒng)：也是由一群關(guān)聯(lián)的個(gè)體組成的系統(tǒng)全闷，多半是在更大的系統(tǒng)中的一部分。

模塊與組件

都是系統(tǒng)的組成部分萍启，從不同角度拆分系統(tǒng)而已总珠。模塊是邏輯單元，組件是物理單元勘纯。

模塊就是從邏輯上將系統(tǒng)分解局服， 即分而治之， 將復(fù)雜問(wèn)題簡(jiǎn)單化驳遵。模塊的粒度可大可小淫奔， 可以是系統(tǒng)，幾個(gè)子系統(tǒng)堤结、某個(gè)服務(wù)唆迁，函數(shù)， 類(lèi)竞穷，方法唐责、 功能塊等等。

組件可以包括應(yīng)用服務(wù)瘾带、數(shù)據(jù)庫(kù)鼠哥、網(wǎng)絡(luò)、物理機(jī)、還可以包括MQ朴恳、容器抄罕、Nginx等技術(shù)組件。

框架與架構(gòu)

框架是組件實(shí)現(xiàn)的規(guī)范于颖，例如：MVC呆贿、MVP、MVVM等恍飘，是提供基礎(chǔ)功能的產(chǎn)品榨崩，例如開(kāi)源框架：Ruby on Rails、Spring章母、Laravel母蛛、Django等，這是可以拿來(lái)直接使用或者在此基礎(chǔ)上二次開(kāi)發(fā)乳怎。

框架是規(guī)范彩郊，架構(gòu)是結(jié)構(gòu)。

架構(gòu)重新定義

S君：架構(gòu)是什么蚪缀？架構(gòu)師解決什么問(wèn)題秫逝？

• 架構(gòu)是經(jīng)過(guò)系統(tǒng)性地思考¹, 權(quán)衡利弊之后在現(xiàn)有資源約束下的最合理決策, 最終明確的系統(tǒng)骨架²。包括子系統(tǒng), 模塊, 組件. 以及他們之間協(xié)作關(guān)系³, 約束規(guī)范, 指導(dǎo)原則⁴询枚。并由它來(lái)指導(dǎo)團(tuán)隊(duì)中的每個(gè)人思想層面上的一致违帆。

• 架構(gòu)師能力要求：理解業(yè)務(wù)，全局把控金蜀，選擇合適技術(shù)刷后，解決關(guān)鍵問(wèn)題、指導(dǎo)研發(fā)落地實(shí)施渊抄。

我在這重新定義架構(gòu)：軟件架構(gòu)指軟件系統(tǒng)的頂層結(jié)構(gòu)尝胆。

架構(gòu)是經(jīng)過(guò)系統(tǒng)性地思考, 權(quán)衡利弊之后在現(xiàn)有資源約束下的最合理決策, 最終明確的系統(tǒng)骨架。包括子系統(tǒng), 模塊, 組件. 以及他們之間協(xié)作關(guān)系, 約束規(guī)范, 指導(dǎo)原則护桦。并由它來(lái)指導(dǎo)團(tuán)隊(duì)中的每個(gè)人思想層面上的一致含衔。涉及四方面：

• 系統(tǒng)性思考的合理決策：比如技術(shù)選型、解決方案等二庵。

• 明確的系統(tǒng)骨架：明確系統(tǒng)有哪些部分組成贪染。

• 系統(tǒng)協(xié)作關(guān)系：各個(gè)組成部分如何協(xié)作來(lái)實(shí)現(xiàn)業(yè)務(wù)請(qǐng)求。

• 約束規(guī)范和指導(dǎo)原則：保證系統(tǒng)有序催享，高效抑进、穩(wěn)定運(yùn)行。

因此架構(gòu)師具備能力：理解業(yè)務(wù)睡陪，全局把控寺渗，選擇合適技術(shù)匿情，解決關(guān)鍵問(wèn)題、指導(dǎo)研發(fā)落地實(shí)施信殊。

架構(gòu)的本質(zhì)就是對(duì)系統(tǒng)進(jìn)行有序化地重構(gòu)以致符合當(dāng)前業(yè)務(wù)的發(fā)展炬称，并可以快速擴(kuò)展。

那什么樣的系統(tǒng)要考慮做架構(gòu)設(shè)計(jì) 技術(shù)不會(huì)平白無(wú)故的出和自驅(qū)動(dòng)發(fā)展起來(lái)涡拘，而架構(gòu)的發(fā)展和需求是基于業(yè)務(wù)的驅(qū)動(dòng)玲躯。

架構(gòu)設(shè)計(jì)完全是為了業(yè)務(wù)：

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

架構(gòu)分層和分類(lèi)

S君：

業(yè)務(wù)架構(gòu)是戰(zhàn)略朽缴，應(yīng)用架構(gòu)是戰(zhàn)術(shù)，技術(shù)架構(gòu)是裝備

• 業(yè)務(wù)架構(gòu)（俯視架構(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ì)象。

• 應(yīng)用架構(gòu)(剖面架構(gòu)): 承接業(yè)務(wù)架構(gòu)和技術(shù)架構(gòu)奕扣。應(yīng)用架構(gòu)的本質(zhì)是通過(guò)系統(tǒng)拆分薪鹦，平衡業(yè)務(wù)和技術(shù)復(fù)雜性，保證系統(tǒng)形散神不散惯豆。
  應(yīng)用作為獨(dú)立可部署的單元池磁，為系統(tǒng)劃分了明確的邊界，深刻影響系統(tǒng)功能組織循帐、代碼開(kāi)發(fā)框仔、部署和運(yùn)維等各方面舀武，應(yīng)用架構(gòu)定義系統(tǒng)有哪些應(yīng)用拄养、以及應(yīng)用之間如何分工和合作。應(yīng)用的分偏向于業(yè)務(wù)银舱，反映業(yè)務(wù)架構(gòu)瘪匿，應(yīng)用的合偏向于技術(shù)，影響技術(shù)架構(gòu)寻馏。

• 技術(shù)架構(gòu)：確定組成應(yīng)用系統(tǒng)的實(shí)際運(yùn)行組件(技術(shù)選型)棋弥，這些運(yùn)行組件之間的關(guān)系，以及部署到硬件的策略诚欠。
  技術(shù)架構(gòu)主要考慮系統(tǒng)的非功能性特征顽染，對(duì)系統(tǒng)的高可用漾岳、高性能、擴(kuò)展粉寞、安全尼荆、伸縮性、簡(jiǎn)潔等做系統(tǒng)級(jí)的把握

• 三者關(guān)系：
  業(yè)務(wù)架構(gòu)是生產(chǎn)力唧垦，應(yīng)用架構(gòu)是生產(chǎn)關(guān)系捅儒，技術(shù)架構(gòu)是生產(chǎ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)最終落地

補(bǔ)充材料：節(jié)選《軟件架構(gòu)設(shè)計(jì)》 關(guān)注微信公眾號(hào)回復(fù)【架構(gòu)設(shè)計(jì)】獲取相關(guān)書(shū)籍

• 架構(gòu)五視圖：

• 邏輯架構(gòu)：邏輯架構(gòu)關(guān)注功能坊秸，不僅包括用戶(hù)可見(jiàn)的功能麸祷，還包括為實(shí)現(xiàn)用戶(hù)功能而必須提供的“輔助功能模塊”。

• 開(kāi)發(fā)架構(gòu)：開(kāi)發(fā)架構(gòu)關(guān)注程序包妇斤，不僅包括要編寫(xiě)的源程序摇锋，還包括可以直接使用的第三方SDK 和現(xiàn)場(chǎng)框架、類(lèi)庫(kù)站超，以及開(kāi)發(fā)的系統(tǒng)將運(yùn)行于其上的系統(tǒng)軟件或中間件荸恕。關(guān)注編譯時(shí)刻的靜態(tài)依賴(lài)關(guān)系。

• 運(yùn)行架構(gòu)：運(yùn)行架構(gòu)關(guān)注進(jìn)程死相、線(xiàn)程融求、對(duì)象等運(yùn)行時(shí)概念，以及相關(guān)的并發(fā)算撮，同步生宛，通信等問(wèn)題。運(yùn)行架構(gòu)關(guān)注運(yùn)行期間各個(gè)單元的交互肮柜。

• 物理架構(gòu)：物理架構(gòu)關(guān)注“目標(biāo)程序及其依賴(lài)的運(yùn)行庫(kù)和系統(tǒng)軟件”最終如何安裝或部署到物理機(jī)器陷舅，以及如何部署機(jī)器和網(wǎng)絡(luò)來(lái)配合軟件系統(tǒng)的可靠性，可伸縮性等要求审洞。

• 數(shù)據(jù)架構(gòu)：數(shù)據(jù)架構(gòu)關(guān)注持久化數(shù)據(jù)的存儲(chǔ)方案莱睁，不僅包括實(shí)體及實(shí)體關(guān)系的存儲(chǔ)格式、還包括數(shù)據(jù)傳遞芒澜，數(shù)據(jù)復(fù)制仰剿，數(shù)據(jù)同步等策略。

架構(gòu)分類(lèi)可細(xì)分為業(yè)務(wù)架構(gòu)痴晦、應(yīng)用架構(gòu)南吮、技術(shù)架構(gòu), 代碼架構(gòu), 部署架構(gòu)、數(shù)據(jù)架構(gòu)

image

業(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ù)，形成業(yè)務(wù)架構(gòu)必孤，根據(jù)業(yè)務(wù)架構(gòu)猾骡，做出相應(yīng)的應(yīng)用架構(gòu)，最后技術(shù)架構(gòu)落地實(shí)施敷搪。

如何針對(duì)當(dāng)前需求兴想，選擇合適的應(yīng)用架構(gòu)，如何面向未來(lái)赡勘，保證架構(gòu)平滑過(guò)渡嫂便，這個(gè)是軟件開(kāi)發(fā)者，特別是架構(gòu)師闸与，都需要深入思考的問(wèn)題毙替。

業(yè)務(wù)架構(gòu)（俯視架構(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)的效果荠商。

看看京東業(yè)務(wù)架構(gòu)（網(wǎng)上分享圖）：

image

應(yīng)用架構(gòu)（剖面架構(gòu)寂恬，也叫邏輯架構(gòu)圖）：

硬件到應(yīng)用的抽象续誉，包括抽象層和編程接口莱没。應(yīng)用架構(gòu)和業(yè)務(wù)架構(gòu)是相輔相成的關(guān)系。業(yè)務(wù)架構(gòu)的每一部分都有應(yīng)用架構(gòu)酷鸦。

類(lèi)似：

image

應(yīng)用架構(gòu)：應(yīng)用作為獨(dú)立可部署的單元饰躲，為系統(tǒng)劃分了明確的邊界牙咏，深刻影響系統(tǒng)功能組織、代碼開(kāi)發(fā)嘹裂、部署和運(yùn)維等各方面. 應(yīng)用架構(gòu)定義系統(tǒng)有哪些應(yīng)用妄壶、以及應(yīng)用之間如何分工和合作。這里所謂應(yīng)用就是各個(gè)邏輯模塊或者子系統(tǒng)寄狼。

應(yīng)用架構(gòu)圖關(guān)鍵有2點(diǎn)：

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

• 邏輯分層

• 子系統(tǒng)丁寄、模塊定義

• 關(guān)鍵類(lèi)

②. 職責(zé)之間的協(xié)作：

• 接口協(xié)議：應(yīng)用對(duì)外輸出的接口。
• 協(xié)作關(guān)系：應(yīng)用之間的調(diào)用關(guān)系泊愧。

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

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

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

應(yīng)用的反映應(yīng)用之間如何協(xié)作敲街，共同完成復(fù)雜的業(yè)務(wù)case团搞，主要體現(xiàn)在應(yīng)用之間的通訊機(jī)制和數(shù)據(jù)格式，通訊機(jī)制可以是同步調(diào)用/異步消息/共享DB訪(fǎng)問(wèn)等多艇，數(shù)據(jù)格式可以是文本/XML/JSON/二進(jìn)制等莺丑。

應(yīng)用的分偏向于業(yè)務(wù)，反映業(yè)務(wù)架構(gòu)墩蔓，應(yīng)用的合偏向于技術(shù)梢莽，影響技術(shù)架構(gòu)。分降低了業(yè)務(wù)復(fù)雜度奸披，系統(tǒng)更有序昏名，合增加了技術(shù)復(fù)雜度，系統(tǒng)更無(wú)序阵面。

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

系統(tǒng)采用什么樣的應(yīng)用架構(gòu)赵誓，受業(yè)務(wù)復(fù)雜性影響，包括企業(yè)發(fā)展階段和業(yè)務(wù)特點(diǎn)嚷量；同時(shí)受技術(shù)復(fù)雜性影響取逾，包括IT技術(shù)發(fā)展階段和內(nèi)部技術(shù)人員水平。業(yè)務(wù)復(fù)雜性（包括業(yè)務(wù)量大）必然帶來(lái)技術(shù)復(fù)雜性箕母，應(yīng)用架構(gòu)目標(biāo)是解決業(yè)務(wù)復(fù)雜性的同時(shí)储藐，避免技術(shù)太復(fù)雜俱济，確保業(yè)務(wù)架構(gòu)落地。

數(shù)據(jù)架構(gòu)

數(shù)據(jù)架構(gòu)指導(dǎo)數(shù)據(jù)庫(kù)的設(shè)計(jì). 不僅僅要考慮開(kāi)發(fā)中涉及到的數(shù)據(jù)庫(kù)钙勃，實(shí)體模型蛛碌，也要考慮物理架構(gòu)中數(shù)據(jù)存儲(chǔ)的設(shè)計(jì)。

image

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

子系統(tǒng)代碼架構(gòu)主要為開(kāi)發(fā)人員提供切實(shí)可行的指導(dǎo)辖源，如果代碼架構(gòu)設(shè)計(jì)不足蔚携，就會(huì)造成影響全局的架構(gòu)設(shè)計(jì)。比如公司內(nèi)不同的開(kāi)發(fā)團(tuán)隊(duì)使用不同的技術(shù)椏巳模或者組件浮梢，結(jié)果公司整體架構(gòu)設(shè)計(jì)就會(huì)失控。

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

①. 代碼單元:

• 配置設(shè)計(jì)

• 框架彤路、類(lèi)庫(kù)秕硝。

②. 代碼單元組織：

• 編碼規(guī)范，編碼的慣例洲尊。

• 項(xiàng)目模塊劃分

• 頂層文件結(jié)構(gòu)設(shè)計(jì)远豺，比如mvc設(shè)計(jì)。

• 依賴(lài)關(guān)系

image

技術(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í)的把握毡鉴。

系統(tǒng)架構(gòu)的設(shè)計(jì)要求架構(gòu)師具備軟件和硬件的功能和性能的過(guò)硬知識(shí)崔泵，這也是架構(gòu)設(shè)計(jì)工作中最為困難的工作。

部署拓?fù)浼軜?gòu)圖（實(shí)際物理架構(gòu)圖）：

拓?fù)浼軜?gòu)猪瞬，包括架構(gòu)部署了幾個(gè)節(jié)點(diǎn)憎瘸，節(jié)點(diǎn)之間的關(guān)系，服務(wù)器的高可用陈瘦，網(wǎng)路接口和協(xié)議等幌甘，決定了應(yīng)用如何運(yùn)行，運(yùn)行的性能，可維護(hù)性含潘，可擴(kuò)展性，是所有架構(gòu)的基礎(chǔ)线婚。這個(gè)圖主要是運(yùn)維工程師主要關(guān)注的對(duì)象遏弱。

image

物理架構(gòu)主要考慮硬件選擇和拓?fù)浣Y(jié)構(gòu)，軟件到硬件的映射塞弊，軟硬件的相互影響漱逸。

image

架構(gòu)級(jí)別

S君：

• 戰(zhàn)略設(shè)計(jì)即業(yè)務(wù)架構(gòu)設(shè)計(jì)
• 戰(zhàn)術(shù)設(shè)計(jì)即應(yīng)用架構(gòu)設(shè)計(jì)
• 戰(zhàn)術(shù)實(shí)施即技術(shù)架構(gòu)實(shí)施

我們使用金字塔的架構(gòu)級(jí)別來(lái)說(shuō)明,上層級(jí)別包含下層：

image

• 系統(tǒng)級(jí)：即整個(gè)系統(tǒng)內(nèi)各部分的關(guān)系以及如何治理：分層
• 應(yīng)用級(jí)：即單個(gè)應(yīng)用的整體架構(gòu)，及其與系統(tǒng)內(nèi)單個(gè)應(yīng)用的關(guān)系等游沿。
• 模塊級(jí)：即應(yīng)用內(nèi)部的模塊架構(gòu)饰抒，如代碼的模塊化、數(shù)據(jù)和狀態(tài)的管理等诀黍。
• 代碼級(jí)：即從代碼級(jí)別保障架構(gòu)實(shí)施袋坑。

戰(zhàn)略設(shè)計(jì)與戰(zhàn)術(shù)設(shè)計(jì)

基于架構(gòu)金字塔，我們有了系統(tǒng)架構(gòu)的戰(zhàn)略設(shè)計(jì)與戰(zhàn)術(shù)設(shè)計(jì)的完美結(jié)合：

• 戰(zhàn)略設(shè)計(jì)：業(yè)務(wù)架構(gòu)用于指導(dǎo)架構(gòu)師如何進(jìn)行系統(tǒng)架構(gòu)設(shè)計(jì)眯勾。
• 戰(zhàn)術(shù)設(shè)計(jì)：應(yīng)用架構(gòu)要根據(jù)業(yè)務(wù)架構(gòu)來(lái)設(shè)計(jì)枣宫。
• 戰(zhàn)術(shù)實(shí)施：應(yīng)用架構(gòu)確定以后，就是技術(shù)選型吃环。

image

應(yīng)用架構(gòu)演進(jìn)

S君

應(yīng)用架構(gòu)演化過(guò)程：?jiǎn)误w應(yīng)用-> 服務(wù)化 -> 微服務(wù)

業(yè)務(wù)架構(gòu)是生產(chǎn)力也颤，應(yīng)用架構(gòu)是生產(chǎn)關(guān)系，技術(shù)架構(gòu)是生產(chǎ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ù)

單體應(yīng)用

企業(yè)一開(kāi)始業(yè)務(wù)比較簡(jiǎn)單，只應(yīng)用某個(gè)簡(jiǎn)單場(chǎng)景骑篙，應(yīng)用服務(wù)支持?jǐn)?shù)據(jù)增刪改查和簡(jiǎn)單的邏輯即可输吏，單體應(yīng)用可以滿(mǎn)足要求。

典型的三級(jí)架構(gòu)替蛉，前端（Web/手機(jī)端）+中間業(yè)務(wù)邏輯層+數(shù)據(jù)庫(kù)層贯溅。這是一種典型的Java Spring MVC或者Python Django框架的應(yīng)用。其架構(gòu)圖如下所示：

image

針對(duì)單體應(yīng)用躲查，非功能性需求的做法：

• 性能需求：使用緩存改善性能

• 并發(fā)需求：使用集群改善并發(fā)

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

• 使用反向代理和cdn加速它浅、

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

單體架構(gòu)的應(yīng)用比較容易部署、測(cè)試镣煮， 在項(xiàng)目的初期姐霍，單體應(yīng)用可以很好地運(yùn)行。然而，隨著需求的不斷增加镊折， 越來(lái)越多的人加入開(kāi)發(fā)團(tuán)隊(duì)胯府，代碼庫(kù)也在飛速地膨脹。慢慢地恨胚，單體應(yīng)用變得越來(lái)越臃腫骂因，可維護(hù)性、靈活性逐漸降低赃泡，維護(hù)成本越來(lái)越高寒波。下面是單體架構(gòu)應(yīng)用的一些缺點(diǎn)：

• 復(fù)雜性高：以一個(gè)百萬(wàn)行級(jí)別的單體應(yīng)用為例，整個(gè)項(xiàng)目包含的模塊非常多升熊、模塊的邊界模糊俄烁、 依賴(lài)關(guān)系不清晰、 代碼質(zhì)量參差不齊级野、 混亂地堆砌在一起页屠。可想而知整個(gè)項(xiàng)目非常復(fù)雜蓖柔。每次修改代碼都心驚膽戰(zhàn)卷中， 甚至添加一個(gè)簡(jiǎn)單的功能， 或者修改一個(gè)Bug都會(huì)帶來(lái)隱含的缺陷渊抽。

• 技術(shù)債務(wù)：隨著時(shí)間推移蟆豫、需求變更和人員更迭，會(huì)逐漸形成應(yīng)用程序的技術(shù)債務(wù)懒闷， 并且越積 越多十减。“ 不壞不修”愤估， 這在軟件開(kāi)發(fā)中非常常見(jiàn)帮辟， 在單體應(yīng)用中這種思想更甚。已使用的系統(tǒng)設(shè)計(jì)或代碼難以被修改玩焰，因?yàn)閼?yīng)用程序中的其他模塊可能會(huì)以意料之外的方式使用它由驹。

• 部署頻率低：隨著代碼的增多，構(gòu)建和部署的時(shí)間也會(huì)增加昔园。而在單體應(yīng)用中蔓榄， 每次功能的變更或缺陷的修復(fù)都會(huì)導(dǎo)致需要重新部署整個(gè)應(yīng)用。全量部署的方式耗時(shí)長(zhǎng)默刚、 影響范圍大甥郑、 風(fēng)險(xiǎn)高， 這使得單體應(yīng)用項(xiàng)目上線(xiàn)部署的頻率較低荤西。而部署頻率低又導(dǎo)致兩次發(fā)布之間會(huì)有大量的功能變更和缺陷修復(fù)澜搅，出錯(cuò)率比較高伍俘。

• 可靠性差：某個(gè)應(yīng)用Bug，例如死循環(huán)勉躺、內(nèi)存溢出等癌瘾， 可能會(huì)導(dǎo)致整個(gè)應(yīng)用的崩潰。
  擴(kuò)展能力受限：?jiǎn)误w應(yīng)用只能作為一個(gè)整體進(jìn)行擴(kuò)展饵溅，無(wú)法根據(jù)業(yè)務(wù)模塊的需要進(jìn)行伸縮妨退。例如，應(yīng)用中有的模塊是計(jì)算密集型的概说，它需要強(qiáng)勁的CPU碧注；有的模塊則是IO密集型的嚣伐，需要更大的內(nèi)存糖赔。由于這些模塊部署在一起，不得不在硬件的選擇上做出妥協(xié)轩端。

• 阻礙技術(shù)創(chuàng)新：?jiǎn)误w應(yīng)用往往使用統(tǒng)一的技術(shù)平臺(tái)或方案解決所有的問(wèn)題放典， 團(tuán)隊(duì)中的每個(gè)成員 都必須使用相同的開(kāi)發(fā)語(yǔ)言和框架，要想引入新框架或新技術(shù)平臺(tái)會(huì)非常困難基茵。

分布式

隨著業(yè)務(wù)深入奋构，業(yè)務(wù)要求的產(chǎn)品功能越來(lái)越多，每個(gè)業(yè)務(wù)模塊邏輯也都變得更加復(fù)雜拱层，業(yè)務(wù)的深度和廣度都增加弥臼，使得單體應(yīng)用變得越來(lái)越臃腫，可維護(hù)性根灯、靈活性逐漸降低径缅，增加新功能開(kāi)發(fā)周期越來(lái)越長(zhǎng)，維護(hù)成本越來(lái)越高烙肺。

這時(shí)需要對(duì)系統(tǒng)按照業(yè)務(wù)功能模塊拆分纳猪，將各個(gè)模塊服務(wù)化，變成一個(gè)分布式系統(tǒng)桃笙。業(yè)務(wù)模塊分別部署在不同的服務(wù)器上氏堤，各個(gè)業(yè)務(wù)模塊之間通過(guò)接口進(jìn)行數(shù)據(jù)交互。

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

• 降低了耦合度：把模塊拆分脚祟，使用接口通信,降低模塊之間的耦合度。
• 責(zé)任清晰：把項(xiàng)目拆分成若干個(gè)子項(xiàng)目强饮，不同的團(tuán)隊(duì)負(fù)責(zé)不同的子項(xiàng)目由桌。
• 擴(kuò)展方便：增加功能時(shí)只需要再增加一個(gè)子項(xiàng)目，調(diào)用其他系統(tǒng)的接口就可以。
• 部署方便：可以靈活的進(jìn)行分布式部署行您。
• 提高代碼的復(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ā)增大工作量姓迅，但是利大于弊敲霍。

微服務(wù)

緊接著業(yè)務(wù)模式越來(lái)越復(fù)雜，訂單丁存、商品肩杈、庫(kù)存、價(jià)格等各個(gè)模塊都很深入解寝，比如價(jià)格區(qū)分會(huì)員等級(jí)扩然，訪(fǎng)問(wèn)渠道（app還是PC），銷(xiāo)售方式（團(tuán)購(gòu)還是普通）等聋伦，還有大量的價(jià)格促銷(xiāo)夫偶，這些規(guī)則很復(fù)雜，容易相互沖突嘉抓，需要把分散到各個(gè)業(yè)務(wù)的價(jià)格邏輯進(jìn)行統(tǒng)一管理索守，以基礎(chǔ)價(jià)格服務(wù)的方式透明地提供給上層應(yīng)用，變成一個(gè)微內(nèi)核的服務(wù)化架構(gòu)抑片，即微服務(wù)卵佛。

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

• 易于開(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)衙解。

• 單個(gè)微服務(wù)啟動(dòng)較快：?jiǎn)蝹€(gè)微服務(wù)代碼量較少， 所以啟動(dòng)會(huì)比較快焰枢。

• 局部修改容易部署：?jiǎn)误w應(yīng)用只要有修改蚓峦，就得重新部署整個(gè)應(yīng)用舌剂，微服務(wù)解決了這樣的問(wèn)題。一般來(lái)說(shuō)暑椰，對(duì)某個(gè)微服務(wù)進(jìn)行修改霍转，只需要重新部署這個(gè)服務(wù)即可。

• 技術(shù)棧不受限：在微服務(wù)架構(gòu)中一汽，可以結(jié)合項(xiàng)目業(yè)務(wù)及團(tuán)隊(duì)的特點(diǎn)避消，合理地選擇技術(shù)棧。例如某些服務(wù)可使用關(guān)系型數(shù)據(jù)庫(kù)MySQL召夹；某些微服務(wù)有圖形計(jì)算的需求岩喷，可以使用Neo4j；甚至可根據(jù)需要监憎，部分微服務(wù)使用Java開(kāi)發(fā)纱意，部分微服務(wù)使用Node.js開(kāi)發(fā)。

微服務(wù)雖然有很多吸引人的地方枫虏，但它并不是免費(fèi)的午餐妇穴，使用它是有代價(jià)的爬虱。使用微服務(wù)架構(gòu)面臨的挑戰(zhàn)隶债。

• 運(yùn)維要求較高：更多的服務(wù)意味著更多的運(yùn)維投入。在單體架構(gòu)中跑筝，只需要保證一個(gè)應(yīng)用的正常運(yùn)行死讹。而在微服務(wù)中，需要保證幾十甚至幾百個(gè)服務(wù)服務(wù)的正常運(yùn)行與協(xié)作曲梗，這給運(yùn)維帶來(lái)了很大的挑戰(zhàn)赞警。

• 分布式固有的復(fù)雜性：使用微服務(wù)構(gòu)建的是分布式系統(tǒng)。對(duì)于一個(gè)分布式系統(tǒng)虏两，系統(tǒng)容錯(cuò)愧旦、網(wǎng)絡(luò)延遲、分布式事務(wù)等都會(huì)帶來(lái)巨大的挑戰(zhàn)定罢。

• 接口調(diào)整成本高：微服務(wù)之間通過(guò)接口進(jìn)行通信笤虫。如果修改某一個(gè)微服務(wù)的API，可能所有使用了該接口的微服務(wù)都需要做調(diào)整祖凫。

• 重復(fù)勞動(dòng)：很多服務(wù)可能都會(huì)使用到相同的功能琼蚯，而這個(gè)功能并沒(méi)有達(dá)到分解為一個(gè)微服務(wù)的程度，這個(gè)時(shí)候惠况，可能各個(gè)服務(wù)都會(huì)開(kāi)發(fā)這一功能遭庶，從而導(dǎo)致代碼重復(fù)。盡管可以使用共享庫(kù)來(lái)解決這個(gè)問(wèn)題（例如可以將這個(gè)功能封裝成公共組件稠屠，需要該功能的微服務(wù)引用該組件）峦睡，但共享庫(kù)在多語(yǔ)言環(huán)境下就不一定行得通了翎苫。

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

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

合理的架構(gòu)設(shè)計(jì)：

業(yè)務(wù)需求角度

• 能解決當(dāng)下業(yè)務(wù)需求和問(wèn)題

• 高效完成業(yè)務(wù)需求: 能以?xún)?yōu)雅且可復(fù)用的方式解決當(dāng)下所有業(yè)務(wù)問(wèn)題

• 前瞻性設(shè)計(jì): 能在未來(lái)一段時(shí)間都能以第2種方式滿(mǎn)足業(yè)務(wù)，從而不會(huì)每次當(dāng)業(yè)務(wù)進(jìn)行演變時(shí)叔扼，導(dǎo)致架構(gòu)翻天覆地的變化事哭。

非業(yè)務(wù)需求角度

①. 穩(wěn)定性指標(biāo)：

高可用：要盡可能的提高軟件的可用性，我想每個(gè)操作人都不愿意看到自己的工作無(wú)法正常進(jìn)行瓜富。黑盒白盒測(cè)試鳍咱、單元測(cè)試、自動(dòng)化測(cè)試与柑、故障注入測(cè)試谤辜、提高測(cè)試覆蓋率等方式來(lái)一步一步推進(jìn)。

②. 高效指標(biāo)：

文檔化：不管是整體還是部分的整個(gè)生命周期內(nèi)都必須做好文檔化价捧，變動(dòng)的來(lái)源包括但不限于BUG丑念，需求。

可擴(kuò)展：軟件的設(shè)計(jì)秉承著低耦合的理念去做结蟋，注意在合理的地方抽象脯倚。方便功能更改、新增和運(yùn)用技術(shù)的迭代嵌屎，并且支持在適時(shí)對(duì)架構(gòu)做出重構(gòu)推正。

高復(fù)用：為了避免重復(fù)勞動(dòng)，為了降低成本宝惰，我們希望能夠重用之前的代碼植榕、之前的設(shè)計(jì)。這點(diǎn)對(duì)于架構(gòu)環(huán)境的依賴(lài)是最大的尼夺。

③. 安全指標(biāo)

安全：組織的運(yùn)作過(guò)程中產(chǎn)生的數(shù)據(jù)都是具有商業(yè)價(jià)值的尊残，保證數(shù)據(jù)的安全也是刻不容緩的一部分。以免出現(xiàn)XX門(mén)之類(lèi)丑聞汞斧。加密夜郁、https等為普遍手段

常見(jiàn)架構(gòu)誤區(qū)

S君：

架構(gòu)設(shè)計(jì)需要考慮功能需求和非功能需求，要根據(jù)現(xiàn)狀又要有一定的前瞻性粘勒，也講究方法又要講究落地竞端，要循序漸進(jìn)，不斷演化

• 低開(kāi)高走落不到實(shí)處
• 遺漏關(guān)鍵性約束與非功能需求
• 為虛無(wú)的未來(lái)買(mǎi)單而過(guò)度設(shè)計(jì)
• 過(guò)早做出關(guān)鍵性決策
• 客戶(hù)說(shuō)啥就是啥成為傳話(huà)筒
• 埋頭干活兒缺乏前瞻性
• 架構(gòu)設(shè)計(jì)還要考慮系統(tǒng)可測(cè)性
• 架構(gòu)設(shè)計(jì)不要企圖一步到位

常見(jiàn)誤區(qū)：

• 誤區(qū)1——架構(gòu)專(zhuān)門(mén)由架構(gòu)師來(lái)做庙睡，業(yè)務(wù)開(kāi)發(fā)人員無(wú)需關(guān)注事富。架構(gòu)的再好技俐，最終還是需要代碼來(lái)落地，并且組織越大這個(gè)落地的難度越大统台。不單單是系統(tǒng)架構(gòu)雕擂，每個(gè)解決方案每個(gè)項(xiàng)目也由自己的架構(gòu)，如分層贱勃、設(shè)計(jì)模式等井赌。如果每一塊磚瓦不夠堅(jiān)固，那么整個(gè)系統(tǒng)還是會(huì)由崩塌的風(fēng)險(xiǎn)贵扰。所謂“千里之堤仇穗，潰于蟻穴”。

• 誤區(qū)2——架構(gòu)師確定了架構(gòu)藍(lán)圖之后任務(wù)就結(jié)束了戚绕。架構(gòu)不是“空中樓閣”纹坐，最終還是要落地的，但是架構(gòu)師完全不去深入到第一線(xiàn)怎么知道“地”在哪舞丛？怎么才能落的穩(wěn)穩(wěn)當(dāng)當(dāng)耘子。

• 誤區(qū)3——不做出完美的架構(gòu)設(shè)計(jì)不開(kāi)工。世上沒(méi)有最好架構(gòu)球切，只有最合適的架構(gòu),不要企圖一步到位谷誓。我們需要的不是一下子造出一輛汽車(chē)，而是從單輪車(chē)→自行車(chē)→摩托車(chē)欧聘，最后再到汽車(chē)片林。想象一下2年后才能造出的產(chǎn)品端盆，當(dāng)初市場(chǎng)還存在嗎怀骤？

• 誤區(qū)4—— 為虛無(wú)的未來(lái)埋單而過(guò)度設(shè)計(jì)。在創(chuàng)業(yè)公司初期焕妙，業(yè)務(wù)場(chǎng)景和需求邊界很難把握蒋伦，產(chǎn)品需要快速迭代和變現(xiàn)，需求頻繁更新焚鹊，這個(gè)時(shí)候需要的是快速實(shí)現(xiàn)痕届。不要過(guò)多考慮未來(lái)的擴(kuò)展，說(shuō)不定功能做完末患，效果不好就無(wú)用了研叫。如果業(yè)務(wù)模式和應(yīng)用場(chǎng)景邊界都已經(jīng)比較清晰，是應(yīng)該適當(dāng)?shù)目紤]未來(lái)的擴(kuò)展性設(shè)計(jì)璧针。

• 誤區(qū)5——一味追隨大公司的解決方案：由于大公司巨大成功的光環(huán)效應(yīng)嚷炉，再加上從大公司挖來(lái)的技術(shù)高手的影響，網(wǎng)站在討論架構(gòu)決策時(shí)探橱，最有說(shuō)服力的一句話(huà)就成了“淘寶就是這么搞的”或者“騰訊 就是這么搞的”申屹。大公司的經(jīng)驗(yàn)和成功模式固然重要绘证，值得學(xué)習(xí)借鑒，但如果因此而變得盲從哗讥，就失去了堅(jiān)持自我的勇氣嚷那，在架構(gòu)演化的道路上遲早會(huì)迷路。

• 誤區(qū)6——為了技術(shù)而技術(shù)：技術(shù)是為業(yè)務(wù)而存在的杆煞，除此毫無(wú)意義魏宽。在技術(shù)選型和架構(gòu)設(shè)計(jì)中，脫離網(wǎng)站業(yè)務(wù)發(fā)展的實(shí)際决乎，一味追求時(shí)髦的新技術(shù)湖员，可能會(huì)將技術(shù)發(fā)展引入崎嶇小道，架構(gòu)之路越走越難瑞驱∧锼ぃ考慮實(shí)現(xiàn)成本、時(shí)間唤反、人員等各方面都要綜合考慮凳寺，理想與現(xiàn)實(shí)需要折中。

架構(gòu)知識(shí)體系

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

• 初始階段：LAMP,部署在一臺(tái)服務(wù)器
• 應(yīng)用服務(wù)器和數(shù)據(jù)服務(wù)器分離
• 使用緩存改善性能
• 使用集群改善并發(fā)
• 數(shù)據(jù)庫(kù)地讀寫(xiě)分離
• 使用反向代理和cdn加速
• 使用分布式文件和分布式數(shù)據(jù)庫(kù)
• 業(yè)務(wù)拆分
• 分布式服務(wù)

架構(gòu)模式

分層：橫向分層：應(yīng)用層彤侍，服務(wù)層肠缨，數(shù)據(jù)層

分割：縱向分割：拆分功能和服務(wù)

分布式

• 分布式應(yīng)用和服務(wù)
• 分布式靜態(tài)資源
• 分布式數(shù)據(jù)和存儲(chǔ)
• 分布式計(jì)算

集群：提高并發(fā)和可用性

緩存：優(yōu)化系統(tǒng)性能

• cdn
• 方向代理訪(fǎng)問(wèn)資源
• 本地緩存
• 分布式緩存

異步：降低系統(tǒng)的耦合性

• 提供系統(tǒng)的可用性
• 加快響應(yīng)速度

冗余：冷備和熱備，保證系統(tǒng)的可用性

自動(dòng)化：發(fā)布盏阶，測(cè)試晒奕，部署，監(jiān)控名斟，報(bào)警脑慧，失效轉(zhuǎn)移，故障恢復(fù)

安全：

架構(gòu)核心要素

高性能：網(wǎng)站的靈魂

• 性能測(cè)試
• 前端優(yōu)化
• 應(yīng)用優(yōu)化
• 數(shù)據(jù)庫(kù)優(yōu)化

可用性：保證服務(wù)器不宕機(jī)砰盐，一般通過(guò)冗余部署備份服務(wù)器來(lái)完成

• 負(fù)載均衡
• 數(shù)據(jù)備份
• 自動(dòng)發(fā)布
• 灰度發(fā)布
• 監(jiān)控報(bào)警

伸縮性：建集群闷袒，是否快速應(yīng)對(duì)大規(guī)模增長(zhǎng)的流量，容易添加新的機(jī)器

• 集群
• 負(fù)載均衡
• 緩存負(fù)載均衡（冷熱）

可擴(kuò)展性：主要關(guān)注功能需求岩梳，應(yīng)對(duì)業(yè)務(wù)的擴(kuò)展囊骤，快速響應(yīng)業(yè)務(wù)的變化。是否做法開(kāi)閉原則冀值，系統(tǒng)耦合依賴(lài)

• 分布式消息
• 服務(wù)化

安全性：網(wǎng)站的各種攻擊也物，各種漏洞是否堵住，架構(gòu)是否可以做到限流作用列疗，防止ddos攻擊滑蚯。

• xss攻擊
• sql注入
• csr攻擊
• web防火墻漏洞
• 安全漏洞
• ssl

架構(gòu)書(shū)籍推薦

1. 《大型網(wǎng)站技術(shù)架構(gòu)：核心原理與案例分析》

這是比較早，比較系統(tǒng)介紹大型網(wǎng)站技術(shù)架構(gòu)的書(shū)作彤，通俗易懂又充滿(mǎn)智慧膘魄，即便你之前完全沒(méi)接觸過(guò)網(wǎng)站開(kāi)發(fā)乌逐，通讀前幾章，也能快速獲取到常見(jiàn)的網(wǎng)站技術(shù)架構(gòu)及其應(yīng)用場(chǎng)景创葡。非常贊浙踢。

2. 《億級(jí)流量網(wǎng)站架構(gòu)核心技術(shù)》

相比《大型網(wǎng)站技術(shù)架構(gòu)》的高屋建瓴，開(kāi)濤的這本《億級(jí)流量網(wǎng)站架構(gòu)核心技術(shù)》則落實(shí)到細(xì)節(jié)灿渴，網(wǎng)站架構(gòu)中常見(jiàn)的各種技術(shù)洛波，比如緩存、隊(duì)列骚露、線(xiàn)程池蹬挤、代理……，統(tǒng)統(tǒng)都講到了棘幸，而且配有核心代碼焰扳。甚至連 Nginx 的配置都有！

如果你想在實(shí)現(xiàn)大流量網(wǎng)站時(shí)找參考技術(shù)和代碼误续，這本書(shū)最合適啦吨悍。

3. 《架構(gòu)即未來(lái)》

這是一本“神書(shū)”啦，超越具體技術(shù)層面蹋嵌，著重剖析架構(gòu)問(wèn)題的根源育瓜，幫助我們弄清楚應(yīng)該以何種方式管理、領(lǐng)導(dǎo)栽烂、組織和配置團(tuán)隊(duì)躏仇。

4. 《分布式服務(wù)架構(gòu)：原理、設(shè)計(jì)與實(shí)戰(zhàn)》

這本書(shū)全面介紹了分布式服務(wù)架構(gòu)的原理與設(shè)計(jì)腺办，并結(jié)合作者在實(shí)施微服務(wù)架構(gòu)過(guò)程中的實(shí)踐經(jīng)驗(yàn)焰手，總結(jié)了保障線(xiàn)上服務(wù)健康、可靠的最佳方案菇晃，是一本架構(gòu)級(jí)册倒、實(shí)戰(zhàn)型的重量級(jí)著作。

5. 《聊聊架構(gòu)》

這算是架構(gòu)方面的一本神書(shū)了磺送，從架構(gòu)的原初談起，從業(yè)務(wù)的拆分談起灿意，談到架構(gòu)的目的估灿，架構(gòu)師的角色，架構(gòu)師如何將架構(gòu)落地……強(qiáng)烈推薦缤剧。

不過(guò)馅袁，對(duì)于沒(méi)有架構(gòu)實(shí)踐經(jīng)驗(yàn)的小伙伴來(lái)講，可能會(huì)覺(jué)得這本書(shū)比較虛荒辕，概念多汗销，實(shí)戰(zhàn)少犹褒。但如果你有過(guò)一兩個(gè)項(xiàng)目的架構(gòu)經(jīng)驗(yàn)，就會(huì)深深認(rèn)同書(shū)中追本溯源探討的架構(gòu)理念弛针。

6. 《軟件架構(gòu)師的12項(xiàng)修煉》

大多數(shù)時(shí)候所謂的“技術(shù)之玻璃天花板”其實(shí)只是缺乏軟技能而已叠骑。這些技能可以學(xué)到，缺乏的知識(shí)可以通過(guò)決定改變的努力來(lái)彌補(bǔ)削茁。

參考：

• 在首席架構(gòu)師手里宙枷，應(yīng)用架構(gòu)如此設(shè)計(jì)

什么是架構(gòu)設(shè)計(jì)？架構(gòu)設(shè)計(jì)看這篇文章就夠了

Redis為什么這么快茧跋？

重磅：解讀2020年最新JVM生態(tài)報(bào)告

BIO,NIO,AIO 總結(jié)

JDK8的新特性慰丛，你知道多少？

image