91精品视频在线看_久久国产精品久久国产片_青春草在线视频精品_伊人天天躁夜夜躁狠狠

一. 什么是架構(gòu)和架構(gòu)本質(zhì)（文末有驚喜）

在軟件領(lǐng)域，關(guān)于架構(gòu)的定義存在諸多爭議，每個人對此都有自己的見解。這位所說的架構(gòu)可能與那位所理解的架構(gòu)并不相同。鑒于此，在展開架構(gòu)的討論之前，我們首先需明確架構(gòu)的定義。概念作為認識世界的基礎(chǔ)，同時也是交流的工具。若對架構(gòu)概念的理解存在差異，那么在溝通時自然會感到不順暢。

Linux體系結(jié)構(gòu)存在，MySQL同樣擁有架構(gòu)，JVM亦不例外。在這樣的背景下，以Java進行開發(fā)、以MySQL進行數(shù)據(jù)存儲、運行在Linux環(huán)境中的業(yè)務(wù)系統(tǒng)，它們同樣具備架構(gòu)。那么，我們究竟應(yīng)該關(guān)注哪一個架構(gòu)呢？要解答這一問題，我們需要對一系列相互關(guān)聯(lián)且性質(zhì)相近的概念進行梳理：系統(tǒng)及其子系統(tǒng)、模塊與組件、框架與架構(gòu)。

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

系統(tǒng)，通常指的是由眾多相互關(guān)聯(lián)的個體所構(gòu)成，它們遵循特定的規(guī)則協(xié)同運作，并具備單個元件無法單獨實現(xiàn)的功能的集體。

子系統(tǒng)，它是由眾多相互關(guān)聯(lián)的個體所構(gòu)成的，通常情況下，它是隸屬于一個更大系統(tǒng)中的一個組成部分。

1.2. 模塊與組件

這些均為系統(tǒng)的構(gòu)成要素，不過是將系統(tǒng)從不同維度進行劃分罷了。模塊代表的是邏輯上的獨立單元，而組件則指的是物理上的獨立部分。

模塊化是將系統(tǒng)在邏輯層面進行拆分，也就是采取分解的策略，從而將復(fù)雜的問題簡化。模塊的規(guī)模可以靈活調(diào)整，它可以是整個系統(tǒng)，或是若干個子系統(tǒng)，亦或是某個具體的服務(wù)、函數(shù)、類、方法、功能單元等。

該系統(tǒng)所涉及的組件涵蓋了應(yīng)用服務(wù)、數(shù)據(jù)庫管理系統(tǒng)、網(wǎng)絡(luò)設(shè)施，以及物理服務(wù)器等，此外，亦包括消息隊列、容器技術(shù)、Nginx等多樣化的技術(shù)元素。

1.3. 框架與架構(gòu)

框架是組件遵循的標準，諸如MVC、MVP、MVVM等，它們是具備基礎(chǔ)功能的產(chǎn)品。比如，開源框架Ruby on Rails、Spring、Laravel、Django等，這些框架既可直接應(yīng)用，也可在此基礎(chǔ)上進行進一步的開發(fā)。

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

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

經(jīng)過周密思考與利弊分析，架構(gòu)是在現(xiàn)有資源限制下做出的最優(yōu)化選擇，它最終確定了系統(tǒng)的基本框架：涵蓋子系統(tǒng)、模塊、組件及其相互間的協(xié)作機制、約束規(guī)則和指導(dǎo)方針。這一框架還指導(dǎo)著團隊成員在思想上的統(tǒng)一。該架構(gòu)涉及以下四個方面：

系統(tǒng)性的合理決策至關(guān)重要，涉及諸如技術(shù)選擇與解決方案的確定。構(gòu)建清晰的系統(tǒng)架構(gòu)，明確指出系統(tǒng)的各個組成部分。同時，關(guān)注系統(tǒng)各部分之間的協(xié)作機制，以確保它們能夠協(xié)同完成業(yè)務(wù)需求。此外，還需制定約束規(guī)范和指導(dǎo)原則，以確保系統(tǒng)的有序、高效與穩(wěn)定運行。

因此，架構(gòu)師需具備以下能力：深入理解業(yè)務(wù)需求，全面掌控項目全局，挑選恰當(dāng)?shù)募夹g(shù)方案，有效解決核心難題，并指導(dǎo)研發(fā)團隊將方案成功實施。

架構(gòu)的核心在于對系統(tǒng)進行有序的重組，以適應(yīng)現(xiàn)有業(yè)務(wù)的進步，同時具備迅速擴展的能力。

要考慮進行架構(gòu)設(shè)計的系統(tǒng)，其技術(shù)并非無端產(chǎn)生或自發(fā)演進，其架構(gòu)的演進與需求的形成，均源自于業(yè)務(wù)的發(fā)展推動。

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

需求較為復(fù)雜，非功能性的需求在系統(tǒng)中扮演著關(guān)鍵角色。系統(tǒng)擁有較長的生命周期，并需滿足擴展性的要求。此外，系統(tǒng)設(shè)計需考慮基于組件或集成的方式，以及業(yè)務(wù)流程的重新設(shè)計。因此，在架構(gòu)設(shè)計上，需要考慮分層和分類。

架構(gòu)體系可以進一步劃分為業(yè)務(wù)層面、應(yīng)用層面、技術(shù)層面，以及代碼層面和部署層面。

業(yè)務(wù)架構(gòu)代表著戰(zhàn)略方向，應(yīng)用架構(gòu)則體現(xiàn)為具體實施策略，而技術(shù)架構(gòu)則是實現(xiàn)這些策略的工具。在三者中，應(yīng)用架構(gòu)扮演著至關(guān)重要的角色，它不僅肩負著將業(yè)務(wù)架構(gòu)轉(zhuǎn)化為實際操作的重任，同時也在技術(shù)選型上發(fā)揮著決定性的作用。

對業(yè)務(wù)內(nèi)容深入了解，構(gòu)建起業(yè)務(wù)體系架構(gòu)英語的英文，依據(jù)該體系，制定對應(yīng)的應(yīng)用體系，最終將技術(shù)體系實際應(yīng)用到實踐中。

在當(dāng)前需求背景下，開發(fā)者尤其是架構(gòu)師必須深思熟慮，如何挑選恰當(dāng)?shù)膽?yīng)用架構(gòu)，以及如何確保架構(gòu)在未來能夠?qū)崿F(xiàn)平穩(wěn)過渡。

2.1. 業(yè)務(wù)架構(gòu)（俯視架構(gòu)）：

涵蓋業(yè)務(wù)規(guī)劃、模塊劃分以及流程梳理，對系統(tǒng)整體業(yè)務(wù)進行細致拆解，同時設(shè)計領(lǐng)域模型，將實際業(yè)務(wù)內(nèi)容轉(zhuǎn)化為理論上的抽象實體。

沒有絕對的完美設(shè)計，只有最適合的設(shè)計方案，所有系統(tǒng)構(gòu)建的核心理念都應(yīng)聚焦于解決實際業(yè)務(wù)難題，若技術(shù)構(gòu)建脫離了業(yè)務(wù)實際，容易導(dǎo)致系統(tǒng)陷入困境，而那些完全不考慮業(yè)務(wù)需求，隨意發(fā)揮的架構(gòu)設(shè)計，實則是無理取鬧的行為。

我們需要明確所有問題的基礎(chǔ)在于了解目前所面對的業(yè)務(wù)規(guī)模及其增長趨勢，同時，處理高并發(fā)問題必然是一個逐步推進的漸進過程。一個合理的架構(gòu)設(shè)計應(yīng)能預(yù)見到未來1至2年的業(yè)務(wù)發(fā)展，通過這樣的設(shè)計，我們可以在付出相對合理的成本后，真正實現(xiàn)技術(shù)對業(yè)務(wù)成長的引領(lǐng)作用。

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

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

硬件至應(yīng)用層面的抽象涵蓋抽象層與編程接口兩個層面。應(yīng)用架構(gòu)與業(yè)務(wù)架構(gòu)之間存在著相互促進的緊密聯(lián)系。在業(yè)務(wù)架構(gòu)的各個組成部分中，均融入了應(yīng)用架構(gòu)的元素。

類似：

應(yīng)用架構(gòu)將獨立可部署的單元應(yīng)用于系統(tǒng)，從而為系統(tǒng)劃定了清晰的界限，并在系統(tǒng)功能組織、代碼開發(fā)、部署及運維等多個方面產(chǎn)生了深遠影響。該架構(gòu)明確了系統(tǒng)包含哪些應(yīng)用，以及這些應(yīng)用之間如何進行分工與協(xié)作。在此語境中，“應(yīng)用”指的是各個邏輯模塊或子系統(tǒng)。

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

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

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

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

應(yīng)用之間的協(xié)作模式展現(xiàn)了它們?nèi)绾喂餐幚韽?fù)雜的業(yè)務(wù)場景，這一過程主要表現(xiàn)在它們之間的通信方式和數(shù)據(jù)交換格式上。通信方式包括同步調(diào)用、異步消息傳遞以及共享數(shù)據(jù)庫訪問等，而數(shù)據(jù)交換格式則涵蓋了文本、XML、JSON以及二進制等多種形式。

應(yīng)用的方向側(cè)重于業(yè)務(wù)領(lǐng)域，映射出業(yè)務(wù)體系結(jié)構(gòu)；而應(yīng)用的融合則傾向于技術(shù)層面貝語網(wǎng)校，作用于技術(shù)架構(gòu)。分應(yīng)用有助于簡化業(yè)務(wù)復(fù)雜性，使系統(tǒng)運行更加有序；相對地，融合應(yīng)用則提升了技術(shù)復(fù)雜性，導(dǎo)致系統(tǒng)運行更加混亂。

應(yīng)用架構(gòu)的核心在于對系統(tǒng)進行拆分處理，旨在協(xié)調(diào)業(yè)務(wù)與技術(shù)的復(fù)雜度，確保整體系統(tǒng)既保持分散的結(jié)構(gòu)，又維持內(nèi)在的統(tǒng)一性。

系統(tǒng)所采納的應(yīng)用架構(gòu)選擇，受多方面因素制約，如企業(yè)所處的成長階段及其業(yè)務(wù)特性；此外，技術(shù)層面的復(fù)雜性亦不容忽視，這涉及IT技術(shù)的進步階段及內(nèi)部技術(shù)人員的專業(yè)能力。業(yè)務(wù)規(guī)模的擴大不可避免地會引發(fā)技術(shù)層面的復(fù)雜性，而應(yīng)用架構(gòu)的設(shè)計宗旨在于在解決業(yè)務(wù)復(fù)雜性的同時，力求技術(shù)不至過于復(fù)雜架構(gòu)英語的英文，從而保障業(yè)務(wù)架構(gòu)的有效實施。

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

數(shù)據(jù)架構(gòu)對數(shù)據(jù)庫的構(gòu)建起著指導(dǎo)作用，這不僅僅意味著要關(guān)注開發(fā)過程中涉及的數(shù)據(jù)庫和實體模型，還要求我們充分考慮物理架構(gòu)層面上的數(shù)據(jù)存儲設(shè)計。

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

子系統(tǒng)代碼架構(gòu)為開發(fā)者提供了切實可行的指導(dǎo)原則，若架構(gòu)設(shè)計存在缺陷，則可能對整體架構(gòu)設(shè)計產(chǎn)生不利影響。例如，若公司內(nèi)部不同開發(fā)團隊采用各異的技術(shù)棧或組件，可能導(dǎo)致公司整體架構(gòu)設(shè)計陷入混亂。

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

①. 代碼單元:

②. 代碼單元組織：

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

技術(shù)架構(gòu)方面，需明確應(yīng)用系統(tǒng)所依賴的具體運行模塊，如負載均衡器、反向代理服務(wù)器、應(yīng)用服務(wù)器以及PHP進程管理器等；同時，還需界定這些模塊間的相互聯(lián)系，并制定它們在硬件設(shè)備上的部署策略。

技術(shù)架構(gòu)設(shè)計主要側(cè)重于系統(tǒng)非功能性方面的考量，確保系統(tǒng)在可用性、性能、可擴展性、安全性、伸縮性和簡潔性等方面達到系統(tǒng)整體層面的要求。

系統(tǒng)架構(gòu)的構(gòu)建需要架構(gòu)師對軟件與硬件的功能及性能有扎實的掌握，而這正是架構(gòu)設(shè)計過程中最具挑戰(zhàn)性的環(huán)節(jié)之一。

2.6. 部署拓撲架構(gòu)圖（實際物理架構(gòu)圖）：

拓撲結(jié)構(gòu)涵蓋了節(jié)點部署情況、節(jié)點間的相互聯(lián)系、服務(wù)器的高可靠性、網(wǎng)絡(luò)接口與協(xié)議等因素，這些因素共同決定了應(yīng)用的運行方式、性能表現(xiàn)、維護便利性以及擴展能力，構(gòu)成了架構(gòu)的根本。此圖是運維工程師重點關(guān)注的內(nèi)容。

物理架構(gòu)設(shè)計需重點考慮硬件設(shè)備的選擇以及網(wǎng)絡(luò)布局，同時關(guān)注軟件與硬件之間的映射關(guān)系，以及它們之間的相互作用。

三. 架構(gòu)級別（文末有驚喜）

我們使用金字塔的架構(gòu)級別來說明,上層級別包含下層：

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

依托于架構(gòu)金字塔的框架，我們實現(xiàn)了系統(tǒng)架構(gòu)在戰(zhàn)略層面與戰(zhàn)術(shù)層面的完美融合。

四. 應(yīng)用架構(gòu)演進

業(yè)務(wù)架構(gòu)構(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)的發(fā)展而持續(xù)演變。與此同時，應(yīng)用架構(gòu)的實現(xiàn)離不開技術(shù)架構(gòu)的支持，最終得以落地實施。

架構(gòu)演進路程：單體應(yīng)用→分布式應(yīng)用服務(wù)化→微服務(wù)

4.1. 單體應(yīng)用

企業(yè)初期業(yè)務(wù)相對單一，主要針對某一特定場景，只需實現(xiàn)數(shù)據(jù)的基本增刪改查功能以及簡單的邏輯處理，單個應(yīng)用便能充分滿足需求。

該系統(tǒng)采用了一種典型的三級結(jié)構(gòu)設(shè)計，包括前端部分（無論是Web端還是移動端）、負責(zé)處理業(yè)務(wù)邏輯的中間層以及存儲數(shù)據(jù)的數(shù)據(jù)庫層。這種設(shè)計模式常見于Java Spring MVC或Python Django等框架的應(yīng)用場景。具體的架構(gòu)圖，請參考下文展示。

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

性能提升需借助緩存技術(shù)，并發(fā)需求可通過集群方案解決；讀寫分離則需采用數(shù)據(jù)庫層面的策略，反向代理與CDN可助力加速，分布式文件系統(tǒng)與數(shù)據(jù)庫技術(shù)亦不可或缺。

單體架構(gòu)的實施較為簡便，易于部署和檢驗，尤其在項目啟動階段，單個應(yīng)用能夠高效運作。不過，伴隨著需求量的持續(xù)上升，開發(fā)團隊的規(guī)模不斷擴大，代碼庫也迅速擴張。隨著時間的推移，單體應(yīng)用逐漸顯得龐大，其可維護性和靈活性逐步減弱，維護費用亦隨之攀升。以下列舉了單體架構(gòu)應(yīng)用存在的一些不足之處：

4.2. 分布式

隨著業(yè)務(wù)不斷拓展，所需的產(chǎn)品功能日益豐富，各個業(yè)務(wù)模塊的運作邏輯也日益繁復(fù)，業(yè)務(wù)涉及的深度與廣度同步提升，導(dǎo)致單一應(yīng)用系統(tǒng)逐漸顯得龐大，其可維護性和靈活性逐步下降，新增功能的開發(fā)周期不斷延長，維護成本也隨之攀升。

此時，需對系統(tǒng)進行業(yè)務(wù)功能模塊的劃分，并將各模塊實現(xiàn)服務(wù)化，構(gòu)建為一個分布式架構(gòu)。這些業(yè)務(wù)模塊將分別部署于不同的服務(wù)器之中，而它們之間則通過接口實現(xiàn)數(shù)據(jù)的互通與交流。

與單體架構(gòu)相較，本架構(gòu)具備負載均衡功能，顯著增強了系統(tǒng)的承載能力，有效滿足了網(wǎng)站面對高并發(fā)情況的需求。此外，它還具有以下幾項特性：

4.3. 微服務(wù)

隨著業(yè)務(wù)模式日漸繁復(fù)，訂單、商品、庫存、價格等多個環(huán)節(jié)都涉及到了深層次的運作。例如，價格策略會根據(jù)會員等級、訪問渠道（如app或PC端）以及銷售方式（如團購或普通銷售）進行區(qū)分，同時伴隨眾多價格促銷活動。這些規(guī)則錯綜復(fù)雜，往往容易產(chǎn)生沖突。因此，有必要將分散在各個業(yè)務(wù)中的價格邏輯進行集中管理，并以基礎(chǔ)價格服務(wù)的形式，透明地向上層應(yīng)用提供，進而構(gòu)建成一個以微服務(wù)為核心的輕量級服務(wù)架構(gòu)。

微服務(wù)的特點：

微服務(wù)架構(gòu)雖然具備諸多誘人的優(yōu)勢，然而，它并非毫無成本，采用這一架構(gòu)同樣需要付出相應(yīng)的代價。在使用微服務(wù)架構(gòu)的過程中，我們將會遭遇一系列的挑戰(zhàn)。

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

構(gòu)建的框架應(yīng)當(dāng)服務(wù)于業(yè)務(wù)需求，不存在絕對的最優(yōu)設(shè)計，唯有契合需求的才是最佳選擇。架構(gòu)設(shè)計始終以實現(xiàn)高效、穩(wěn)定、安全為標準，以此來評估其合理性。

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

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

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

①. 穩(wěn)定性。指標：

②. 高效指標：

③. 安全指標

六. 常見架構(gòu)誤區(qū)（文末有驚喜）

開高走落不到實處

常見誤區(qū)

七. 架構(gòu)知識體系

7.1. 架構(gòu)演進

7.2. 架構(gòu)模式

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

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

分布式

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

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

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

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

自動化：發(fā)布，測試，部署，監(jiān)控，報警，失效轉(zhuǎn)移，故障恢復(fù)

安全：

7.3. 架構(gòu)核心要素

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

可用性：保證服務(wù)器不宕機，一般通過冗余部署備份服務(wù)器來完成

集群的伸縮性體現(xiàn)在，它能否迅速適應(yīng)流量的劇增，以及是否便于新增設(shè)備。

集群

在考慮可擴展性時，我們應(yīng)著重于滿足功能需求，以便于應(yīng)對業(yè)務(wù)范圍的拓展。同時，要能夠迅速適應(yīng)業(yè)務(wù)上的變動。這涉及到是否遵循了開閉原則，以及系統(tǒng)內(nèi)部各組件之間的耦合和依賴關(guān)系。

網(wǎng)站的安全性涉及諸多方面，包括是否有效堵住了各類攻擊途徑和漏洞，其架構(gòu)是否具備限流功能，以及能否有效抵御ddos攻擊。

彩蛋時刻