前言

寫這篇文章的目的是為了幫助自己思考和澄清，以及如何從一個(gè)簡(jiǎn)單的網(wǎng)站架構(gòu)演進(jìn)到一個(gè)大型的網(wǎng)站架構(gòu)，主要集中在技術(shù)方面

簡(jiǎn)單的網(wǎng)站

由于沒(méi)做過(guò)php，所以就以jsp為例，jsp為網(wǎng)站前端，以電子商務(wù)網(wǎng)站為例，描述一個(gè)簡(jiǎn)單的網(wǎng)站結(jié)構(gòu)

前端jsp+css+js

后端java ssh

網(wǎng)絡(luò)容器

數(shù)據(jù)庫(kù)

開(kāi)發(fā)人員，一名美工，一名前端，一名 Java

部署計(jì)劃是：

一臺(tái)服務(wù)器，部署和

架構(gòu)圖如下：

應(yīng)用和數(shù)據(jù)庫(kù)的分布式部署

然后網(wǎng)站運(yùn)行了一段時(shí)間，開(kāi)始盈利了，用戶數(shù)量也增加了。這時(shí)候數(shù)據(jù)庫(kù)的數(shù)據(jù)量還不是很大。

但是，越來(lái)越多的用戶訪問(wèn)會(huì)占用大量的服務(wù)器內(nèi)存和cpu。數(shù)據(jù)庫(kù)和應(yīng)用程序應(yīng)該分開(kāi)部署。架構(gòu)圖如下

這樣網(wǎng)站就可以運(yùn)行一段時(shí)間了

解耦開(kāi)發(fā)

接下來(lái)我們來(lái)看看開(kāi)發(fā)問(wèn)題，但是開(kāi)發(fā)和運(yùn)維往往是分不開(kāi)的。由于網(wǎng)站業(yè)務(wù)的快速發(fā)展，我們必須給它添加新的功能，否則將無(wú)法發(fā)揮，功能也會(huì)越來(lái)越多的開(kāi)發(fā)者變得越來(lái)越相互依賴。以前的開(kāi)發(fā)模式是java程序員從jsp寫到dao，全都負(fù)責(zé)，所以現(xiàn)在有5個(gè)java一起開(kāi)發(fā)，每個(gè)負(fù)責(zé)不同的功能，比如用戶模塊、商品模塊、訂單模塊、交易模塊等。 ，那么問(wèn)題來(lái)了

1 Java程序員經(jīng)常對(duì)css做一些調(diào)整，寫了很多工作，我們使用的是

2 不一定要等到所有模塊都開(kāi)發(fā)完成后再上線。在很多情況下，只需要修改一個(gè)模塊就可以上線。那么代碼寫在一個(gè)項(xiàng)目中，版本控制就變得很困難了。而且，每次修改一個(gè)模塊的功能，都可能影響到另一個(gè)模塊的功能，導(dǎo)致項(xiàng)目變得很不穩(wěn)定。這種情況對(duì)于運(yùn)行中的項(xiàng)目來(lái)說(shuō)是致命的，無(wú)限加班也無(wú)濟(jì)于事。痛苦。

解決方案 1（模塊化）

這是我多年前想到的解決方案。這么多功能不能合二為一。我指的是一個(gè) java web 項(xiàng)目。至少在開(kāi)發(fā)過(guò)程中必須模塊化，分離不同的功能。 通過(guò)接口調(diào)用，如用戶模塊、應(yīng)用模塊、商品模塊、訂單模塊、交易模塊等。不同的人負(fù)責(zé)開(kāi)發(fā)，那么模塊之間如何通信呢？我當(dāng)時(shí)的計(jì)劃是，每個(gè)后端模塊都是一個(gè)jar包項(xiàng)目。當(dāng)它們被釋放時(shí)php大型網(wǎng)站技術(shù)架構(gòu)，它們被標(biāo)記為一個(gè) jar 包，供其他模塊調(diào)用。該項(xiàng)目的構(gòu)建使其從開(kāi)發(fā)到部署更加自動(dòng)化。基本實(shí)現(xiàn)模塊化開(kāi)發(fā)，項(xiàng)目發(fā)布更加穩(wěn)定。

模塊化的缺點(diǎn)

這個(gè)想法就是從那里來(lái)的，他們也模塊化了不同的功能，但是這種形式有很多缺點(diǎn)：

1 隨著時(shí)間的推移，每個(gè)模塊都在不斷更新，版本也在不斷升級(jí)。如果模塊 A 依賴于模塊 B，則 C

可以理解為A為web前置模塊，B為用戶模塊，C為訂單模塊

如下圖：

如果 B 或 C 發(fā)生變化，則 A 有 2 個(gè)選擇：

1 如果 B 和 C 沒(méi)有更新，它們?nèi)匀豢梢允褂?。結(jié)果將是不支持最新的 b 和 c 函數(shù)。

2 如果選擇更新，A需要重新添加新的B或C jar包并進(jìn)行調(diào)試和測(cè)試工作，

從接口依賴的角度來(lái)看

因?yàn)锽和C需要查數(shù)據(jù)庫(kù)，所以B和C的jar包暴露給A的api太多，沒(méi)辦法很好的控制。對(duì)于A項(xiàng)目的開(kāi)發(fā)者來(lái)說(shuō)，接口不清晰，幾乎所有的方法都可以調(diào)用，使得B和C的變化對(duì)上層A產(chǎn)生不可控的影響。

從系統(tǒng)性能來(lái)看

由于B和C都需要檢查數(shù)據(jù)庫(kù)，在A中以jar的形式，占用了A項(xiàng)目中所有服務(wù)器的內(nèi)存、cpu等資源，無(wú)法分布式部署。

方案二：模塊化分布式部署

那么應(yīng)該用什么方案，最好是分布式部署，通過(guò)網(wǎng)絡(luò)通信調(diào)用A和B，C

由此帶來(lái)的好處

1 A、B、C實(shí)現(xiàn)分布式部署

2 B、C提供清晰的接口供A調(diào)用，只要接口不變，B和C修改內(nèi)部業(yè)務(wù)邏輯，A不需要重新構(gòu)建和部署，實(shí)現(xiàn)最大解耦，即, 修改部分系統(tǒng)功能php大型網(wǎng)站技術(shù)架構(gòu)，其他模塊不受影響或受影響較小，影響范圍可控。

下一篇大型網(wǎng)站系統(tǒng)架構(gòu)演進(jìn)（二）分布式模塊間的通信

目錄大型網(wǎng)站系統(tǒng)架構(gòu)演進(jìn)