在分析互聯(lián)網(wǎng)業(yè)務(wù)發(fā)展的特點時，我們注意到一個明顯的趨勢：系統(tǒng)的復(fù)雜性不斷增加。這種復(fù)雜性主要體現(xiàn)在系統(tǒng)數(shù)量的增加以及不同系統(tǒng)由不同團隊開發(fā)。如果各團隊采用不同的開發(fā)框架和技術(shù)，會引發(fā)諸多問題，如技術(shù)人員間缺乏共同語言、技術(shù)掌握需要大量人力資源、團隊間人員流動困難等。

為了解決這些問題，互聯(lián)網(wǎng)公司通常會選擇統(tǒng)一的技術(shù)方向和開發(fā)框架。例如，Java領(lǐng)域的SSH、SpringMVC、Play，Ruby的Ruby on Rails，PHP的ThinkPHP，以及Python的Django等。這種做法不僅提升了團隊的協(xié)作效率，也優(yōu)化了組織資源的配置。

在選擇框架時，通行的原則是優(yōu)先考慮成熟的框架，避免盲目追新。成熟的框架有幾個明顯優(yōu)點：首先，文檔資料完善，大部分問題都能通過搜索解決；其次，由于使用者眾多，招聘時也更易找到合適的人才；最后，成熟的框架通常更穩(wěn)定，適合長期使用，這對企業(yè)的持續(xù)發(fā)展非常重要。

Web 服務(wù)器

開發(fā)框架雖然關(guān)鍵于業(yè)務(wù)功能的實現(xiàn)，但要讓這些功能真正運作并服務(wù)于用戶，服務(wù)器的角色是不可或缺的。

考慮到開發(fā)一個成熟的 Web 服務(wù)器所需的高昂成本，以及市場上已有眾多成熟的開源 Web 服務(wù)器，互聯(lián)網(wǎng)行業(yè)普遍采用現(xiàn)成的解決方案。這意味著選擇一個流行的開源服務(wù)器通常足以滿足需求。大型公司可能會根據(jù)自己的業(yè)務(wù)需求對開源服務(wù)器進行二次開發(fā)，如淘寶開發(fā)的 Tengine，但大多數(shù)公司只需深入理解開源服務(wù)器的機制，并通過優(yōu)化設(shè)置和調(diào)整配置來滿足業(yè)務(wù)需求。

選擇服務(wù)器時，需要考慮到開發(fā)語言的兼容性。例如，Java通常使用Tomcat、JBoss或Resin；而PHP和Python則常用Nginx。當然，選擇Apache可以說是最保險的做法，因為它支持各種語言。

對于Apache的性能問題，實際上沒有必要過早擔心。一般來說，只有當業(yè)務(wù)規(guī)模擴大到Apache難以支持時，才需要考慮替換，那時候資源將更為充足，包括資金、人力和時間。

容器

近年來，容器技術(shù)尤其是Docker，已經(jīng)在互聯(lián)網(wǎng)行業(yè)中變得極為流行。例如，騰訊的Docker應(yīng)用已經(jīng)擴展到萬臺規(guī)模的實踐，而新浪微博也在其紅包服務(wù)中實施了大規(guī)模的Docker集群。

相比之下，傳統(tǒng)的虛擬化技術(shù)如虛擬機，盡管解決了跨平臺問題，但由于其龐大且啟動慢，資源占用高的特性，其在互聯(lián)網(wǎng)行業(yè)的應(yīng)用并未廣泛。Docker的容器技術(shù)雖不具備跨平臺能力，但其快速啟動和極低的資源占用使其迅速獲得了廣泛應(yīng)用，容器技術(shù)被視為技術(shù)發(fā)展的未來主流。

Docker的影響遠超傳統(tǒng)的虛擬化或容器技術(shù)：

運維方式將徹底改變：Docker的快速啟動和低資源占用特性，使得基于Docker的自動化和智能化運維將成為新的運維標準。

設(shè)計模式將發(fā)生根本變化：Docker低成本啟動新容器的特性，將促進設(shè)計思維向“微服務(wù)”方向發(fā)展。例如，傳統(tǒng)網(wǎng)站的登錄、注冊、頁面訪問和搜索等功能通常集成于一體。引入容器技術(shù)后，這些功能可以從一開始就以服務(wù)化的方式進行設(shè)計，從而避免隨著訪問量增大而需要對系統(tǒng)進行重構(gòu)的問題。

服務(wù)層技術(shù)

隨著互聯(lián)網(wǎng)業(yè)務(wù)的持續(xù)發(fā)展，業(yè)務(wù)系統(tǒng)的數(shù)量和復(fù)雜度呈現(xiàn)上升趨勢。例如，為了支持一個A業(yè)務(wù)系統(tǒng)的運行，可能需要與B、C、D、E等多達十幾個其他系統(tǒng)進行協(xié)作。從數(shù)學(xué)角度看，系統(tǒng)間的依賴關(guān)系呈指數(shù)級增長。例如，3個系統(tǒng)之間可能存在3條相互關(guān)聯(lián)的路徑，而6個系統(tǒng)之間則有15條路徑。

服務(wù)層的核心目標是減少這些系統(tǒng)間的復(fù)雜度。以下是配置中心的主要優(yōu)點和功能：

1. 集中管理配置：

• 當系統(tǒng)數(shù)量較少時，各個系統(tǒng)通常獨立管理自己的配置。但隨著系統(tǒng)數(shù)量的增加，這種分散管理方式可能導(dǎo)致上線新功能或處理線上問題時效率低下，因為這需要多個系統(tǒng)的協(xié)作以及大量的配置檢查和溝通協(xié)調(diào)。
• 個別系統(tǒng)獨立管理配置時，通常通過文本編輯器進行修改，這樣容易發(fā)生錯誤，例如將IP地址中的數(shù)字0誤輸入為字母O，這類錯誤肉眼難以識別，但通過程序檢查則相對容易發(fā)現(xiàn)。

2. 配置中心的實現(xiàn)目的：

• 實現(xiàn)配置中心主要是為了解決上述問題，提高操作效率，并使所有配置集中在一個地方，便于檢查和協(xié)作。
• 配置中心還可以通過程序化規(guī)則（如正則表達式）進行檢查，有效避免常見的配置錯誤，比如檢查數(shù)值范圍、IP地址、URL地址等。

3. 配置的備份與恢復(fù)：

• 配置中心不僅作為配置的集中地，還相當于對系統(tǒng)配置的一種備份。在遇到硬件故障如整機磁盤損壞或主板故障時，如果沒有配置中心，恢復(fù)工作將非常耗時且容易出錯，需要逐個通過Vim等工具編輯配置文件。有了配置中心，可以迅速搭建新環(huán)境并恢復(fù)業(yè)務(wù)運行。

通過配置中心，互聯(lián)網(wǎng)公司能夠有效應(yīng)對日益增長的系統(tǒng)復(fù)雜性，提升整體運維效率。

下面是配置中心簡單的設(shè)計，其中通過“系統(tǒng)標識 + host + port”來標識唯一一個系統(tǒng)運行實例是常見的設(shè)計方法。

圖片

服務(wù)中心

當系統(tǒng)數(shù)量較少時，系統(tǒng)間的互相調(diào)用通常是直接在各自系統(tǒng)的配置文件中記錄的。但隨著系統(tǒng)數(shù)量的增加，這種直接配置的方法開始顯現(xiàn)出其局限性。

例如，如果A系統(tǒng)開發(fā)了一個新的Y接口來替代現(xiàn)有的X接口，并且希望十個依賴于X接口的系統(tǒng)切換到Y(jié)接口，那么這涉及到的十個系統(tǒng)可能需要在幾十甚至上百臺機器上修改配置并重啟，這個過程的效率非常低。

此外，如果A系統(tǒng)有20臺機器，其中5臺機器出現(xiàn)故障，其他系統(tǒng)如果通過域名訪問A系統(tǒng)，在域名緩存失效之前，仍然可能訪問到這些故障的機器。如果其他系統(tǒng)是通過IP地址來訪問A系統(tǒng)，那么每當A系統(tǒng)增加或刪除機器時，所有依賴的系統(tǒng)都需要在多臺機器上同步這些更改，這種協(xié)調(diào)工作的負擔也是巨大的。

為了解決跨系統(tǒng)依賴中的配置和調(diào)度問題，服務(wù)中心應(yīng)運而生。服務(wù)中心的實現(xiàn)通常有兩種形式：服務(wù)名字系統(tǒng)和服務(wù)總線系統(tǒng)。

服務(wù)名字系統(tǒng)（Service Name System）

這個概念類似于DNS（域名系統(tǒng)）。正如DNS的主要功能是將域名解析為IP地址，因為IP地址難以記憶，而域名相對容易記憶。服務(wù)名字系統(tǒng)的目的是將服務(wù)名稱解析為“主機+端口+接口名稱”。和DNS相似，服務(wù)名字系統(tǒng)的核心功能是解析，而實際的請求仍然由請求方發(fā)起。

基本的設(shè)計如下：

服務(wù)總線系統(tǒng)（Service Bus System）

看到這個翻譯，相信你可能立刻聯(lián)想到計算機的總線。沒錯，兩者的本質(zhì)也是基本類似的。

相比服務(wù)名字系統(tǒng)，服務(wù)總線系統(tǒng)更進一步了：由總線系統(tǒng)完成調(diào)用，服務(wù)請求方都不需要直接和服務(wù)提供方交互了。

基本的設(shè)計如下

圖片

“服務(wù)名字系統(tǒng)”和“服務(wù)總線系統(tǒng)”簡單對比如下表所示。

圖片

消息隊列

互聯(lián)網(wǎng)業(yè)務(wù)的一個特點是“快”，這就要求很多業(yè)務(wù)處理采用異步的方式。例如，大 V 發(fā)布一條微博后，系統(tǒng)需要發(fā)消息給關(guān)注的用戶，我們不可能等到所有消息都發(fā)送給關(guān)注用戶后再告訴大 V 說微博發(fā)布成功了，只能先讓大 V 發(fā)布微博，然后再發(fā)消息給關(guān)注用戶。

傳統(tǒng)的異步通知方式是由消息生產(chǎn)者直接調(diào)用消息消費者提供的接口進行通知的，但當業(yè)務(wù)變得龐大，子系統(tǒng)數(shù)量增多時，這樣做會導(dǎo)致系統(tǒng)間交互非常復(fù)雜和難以管理，因為系統(tǒng)間互相依賴和調(diào)用，整個系統(tǒng)的結(jié)構(gòu)就像一張蜘蛛網(wǎng)，如下圖所示。

圖片

消息隊列就是為了實現(xiàn)這種跨系統(tǒng)異步通知的中間件系統(tǒng)。消息隊列既可以“一對一”通知，也可以“一對多”廣播。以微博為例，可以清晰地看到異步通知的實現(xiàn)和作用，如下圖所示

圖片

對比之前的復(fù)雜的蜘蛛網(wǎng)架構(gòu)，采用消息隊列系統(tǒng)后的改變非常顯著：

結(jié)構(gòu)變化：原本的網(wǎng)狀結(jié)構(gòu)變?yōu)榱烁逦木€性結(jié)構(gòu)，使得整體架構(gòu)更加條理化。

解耦生產(chǎn)與消費：消息的生產(chǎn)者與消費者之間實現(xiàn)了解耦，簡化了實現(xiàn)過程。

擴展性提高：增加新的消費者時，對消息生產(chǎn)者沒有任何影響，這大大便利了系統(tǒng)的擴展。

高性能與高可用性：消息隊列系統(tǒng)能夠?qū)崿F(xiàn)高可用和高性能，減少了在各個子系統(tǒng)中重復(fù)建設(shè)的需要，從而降低了工作量。

業(yè)務(wù)集中：各個子系統(tǒng)可以集中精力于業(yè)務(wù)本身，簡化了技術(shù)實現(xiàn)。

盡管消息隊列的基礎(chǔ)功能相對簡單，但要實現(xiàn)高性能、高可用性、消息的時序性和事務(wù)性則較為復(fù)雜。市面上已有許多成熟的開源解決方案如RocketMQ、Kafka、ActiveMQ等，這些通常足以滿足基本需求。然而，如果業(yè)務(wù)對消息的可靠性、順序和事務(wù)性有更高要求，就需要深入了解并可能修改這些開源方案，以避免潛在的問題。

雖然開源方案使用方便，但一旦需要修改就可能變得復(fù)雜。因此，許多公司選擇自行開發(fā)消息隊列系統(tǒng)，這雖然重復(fù)了一些工作，但能更好地適應(yīng)公司的具體業(yè)務(wù)需求，實現(xiàn)快速的定制開發(fā)。

今天我為你講了互聯(lián)網(wǎng)架構(gòu)模板中的開發(fā)層和服務(wù)層技術(shù)，希望對你有所幫助。