前言

驀然回首自己做開發(fā)已經(jīng)十年了，這十年中我獲得了很多，技術(shù)能力、培訓(xùn)、出國(guó)、大公司的經(jīng)歷，還有很多很好的朋友。但再仔細(xì)一想，這十年中我至少浪費(fèi)了五年時(shí)間，這五年可以足夠讓自己成長(zhǎng)為一個(gè)優(yōu)秀的程序員，可惜我錯(cuò)過了，我用這五年時(shí)間和很多程序員一樣在困惑和迷茫中找不到出路！

路其實(shí)一直都在那里，只是我們看不到而已！

以前我一直被公司和技術(shù)牽著走，并不是自己在選擇技術(shù)，而是不自覺地被推到了這個(gè)位置上。想想有多少人對(duì)于自己將來要從事的職業(yè)和技術(shù)類型進(jìn)行過深入思考和比較呢？當(dāng)我跳出編碼后，我開始思考和程序及程序員職業(yè)生涯相關(guān)的問題，最后發(fā)現(xiàn)，影響我們走入今天的困局的竟然是一些我們常常掛在嘴邊的話。

一、分布式架構(gòu)學(xué)習(xí)路線圖

據(jù)統(tǒng)計(jì)，人的閱讀時(shí)間在20分鐘以內(nèi)是能夠達(dá)到全身心投入的，顧文章單張篇幅以后會(huì)盡量縮短，但更新會(huì)盡量相應(yīng)頻繁一些。

二、計(jì)算機(jī)軟件發(fā)展歷史

首先我們了解下計(jì)算機(jī)軟件的發(fā)展歷史,大概總結(jié)概括，分為c/s時(shí)代，web1.0時(shí)代和web2.0時(shí)代。

**c/s時(shí)代:**富客戶端方案。賣軟件可賺錢。例如 qq、影音、游戲。

**1.0時(shí)代:**主要是單向信息的發(fā)布，即信息門戶—廣大瀏覽器客戶端 ，互聯(lián)網(wǎng)內(nèi)容是由少數(shù)編輯人員（或站長(zhǎng)）定制的。

表是三大門戶，新浪/網(wǎng)易/搜狐。新浪以新聞+廣告為主，網(wǎng)易拓展游戲?yàn)橹?#xff0c;搜狐延伸門戶矩陣

**2.0時(shí)代:**注重用戶的交互。每個(gè)人都是內(nèi)容的供稿者。?RSS訂閱扮演一個(gè)很重要的作用。

例如:博客、播客、維基、P2P下載、社區(qū)、分享服務(wù)

時(shí)至今日，互聯(lián)網(wǎng)的形式演變已經(jīng)變成全員參與，老少皆宜的活動(dòng)。因此，互聯(lián)網(wǎng)相關(guān)的技術(shù)也是要求越來越高，參與人數(shù)的增加也讓系統(tǒng)的負(fù)擔(dān)越來越大。

三、技術(shù)架構(gòu)演進(jìn)史

以下為2017年天貓雙11的交易指標(biāo)。那么大的數(shù)據(jù)量,那么快的處理請(qǐng)求，顯然單臺(tái)機(jī)器，單個(gè)服務(wù)絕對(duì)是無法支撐的。

那么怎么辦呢，我們將原本單臺(tái)部署，單臺(tái)處理的服務(wù)，需要進(jìn)行拆分以及部署到不同的服務(wù)器中去，使其用多臺(tái)機(jī)器去處理，分擔(dān)壓力。但是我們又要保證系統(tǒng)的完整性。這就是分布式的設(shè)計(jì)。接下來我們看下服務(wù)架構(gòu)的演進(jìn)史。

架構(gòu)演進(jìn)一:?早期雛形

特征：應(yīng)用程序主要做靜態(tài)文件讀取，返回內(nèi)容給瀏覽器。

**架構(gòu)演進(jìn)二:?**數(shù)據(jù)庫(kù)開發(fā)（LAMP特長(zhǎng)）

特征：應(yīng)用程序主要主要讀取數(shù)據(jù)表值，填充html模塊。業(yè)務(wù)邏輯簡(jiǎn)單，寫sql

架構(gòu)演進(jìn)三:? javaweb的雛形

特征：tomcat + servlet + jsp + mysql。一個(gè)war包打天下

項(xiàng)目結(jié)構(gòu)：ssh/ssm三層結(jié)構(gòu)。

架構(gòu)演進(jìn)四:? javaweb的集群發(fā)展

特征：硬件機(jī)器的橫向復(fù)制，對(duì)整個(gè)項(xiàng)目結(jié)構(gòu)無影響。

架構(gòu)演進(jìn)五:? javaweb的分布式發(fā)展

特征：將Service層單獨(dú)分離出去，成為一個(gè)單獨(dú)的項(xiàng)目jar。單獨(dú)運(yùn)行。Web服務(wù)器通過rpc框架，對(duì)分離出去的service進(jìn)行調(diào)用。

架構(gòu)演進(jìn)六:? javaweb的微服務(wù)發(fā)展

特征：從業(yè)務(wù)角度，細(xì)分業(yè)務(wù)為微服務(wù)，每一個(gè)微服務(wù)是一個(gè)完整的服務(wù)（從http請(qǐng)求到返回）。在微服務(wù)內(nèi)部，將需要對(duì)外提供的接口，包裝成rpc接口，對(duì)外部開放。

集群與分布式的區(qū)別

我在面試的時(shí)候，發(fā)現(xiàn)很多同學(xué)會(huì)把集群和分布式混淆，其實(shí)他倆完全是兩個(gè)東西

分布式：縱向拆分，一個(gè)業(yè)務(wù)分拆多個(gè)子業(yè)務(wù)，部署在不同的服務(wù)器上。主要是業(yè)務(wù)層面拆分，進(jìn)行業(yè)務(wù)解耦，從而提高服務(wù)高可用以及高性能。
集群：橫向復(fù)制，同一個(gè)業(yè)務(wù)，部署在多個(gè)服務(wù)器上，前面通過負(fù)載均衡，起到分擔(dān)壓力的作用。而且這些服務(wù)器中，即使有一兩個(gè)宕機(jī)也不會(huì)影響到整體業(yè)務(wù)。

本章主要講了一下高性能架構(gòu)的學(xué)習(xí)路線，以及技術(shù)演進(jìn)史。接下來聊聊Alibaba百萬年薪架構(gòu)師必備技能——高性能架構(gòu)學(xué)習(xí)路線（筆記）：中間件、Nginx、緩存、ZK等等…看下方高性能架構(gòu)進(jìn)階技能圖…

說明：以下全部所說的架構(gòu)師必備技能之高性能架構(gòu)學(xué)習(xí)路線及相關(guān)筆記：中間件、Nginx、緩存、ZK等等等，篇幅有限，很多都是截圖展示，但是圖片都是很高清的，可以清晰的看見其中的內(nèi)容。

一、Zookeeper分布式環(huán)境指揮官

1.1 zookeeper基礎(chǔ)

ZooKeeper是一種分布式協(xié)調(diào)服務(wù)，用于管理大型主機(jī)。在分布式環(huán)境中協(xié)調(diào)和管理服務(wù)是一個(gè)復(fù)雜的過程。ZooKeeper通過其簡(jiǎn)單的架構(gòu)和API解決了這個(gè)問題。ZooKeeper允許開發(fā)人員專注于核心應(yīng)用程序邏輯，而不必?fù)?dān)心應(yīng)用程序的分布式特性。

1.2 分布式應(yīng)用的優(yōu)點(diǎn)

• （1）可靠性 - 單個(gè)或幾個(gè)系統(tǒng)的故障不會(huì)使整個(gè)系統(tǒng)出現(xiàn)故障。

• （2）可擴(kuò)展性 - 可以在需要時(shí)增加性能，通過添加更多機(jī)器，在應(yīng)用程序配置中進(jìn)行微小的更改，而不會(huì)有停機(jī)時(shí)間。

• （3）透明性 - 隱藏系統(tǒng)的復(fù)雜性，并將其顯示為單個(gè)實(shí)體/應(yīng)用程序。

1.3 分布式應(yīng)用的挑戰(zhàn)

• （1）競(jìng)爭(zhēng)條件 - 兩個(gè)或多個(gè)機(jī)器嘗試執(zhí)行特定任務(wù)，實(shí)際上只需在任意給定時(shí)間由單個(gè)機(jī)器完成。例如，共享資源只能在任意給定時(shí)間由單個(gè)機(jī)器修改。

• （2）死鎖 - 兩個(gè)或多個(gè)操作等待彼此無限期完成。

• （3）不一致 - 數(shù)據(jù)的部分失敗。

1.4 Zookeeper相關(guān)筆記

• ZK 手寫筆記（1）：概述+CPA+環(huán)境搭配+一致性協(xié)議+基本使用

• ZK 手寫筆記（2）：源碼解析+應(yīng)用場(chǎng)景

二、Nginx高并發(fā)分流進(jìn)階實(shí)戰(zhàn)

2.1 nginx如何實(shí)現(xiàn)高并發(fā)

• 簡(jiǎn)單來講，就是異步，非阻塞，使用了epoll和大量的底層代碼優(yōu)化。

• 稍微詳細(xì)一點(diǎn)展開的話，就是nginx的特殊進(jìn)程模型和事件模型的設(shè)計(jì)。

2.2 進(jìn)程模型

• nginx采用一個(gè)master進(jìn)程，多個(gè)woker進(jìn)程的模式。

• master進(jìn)程主要負(fù)責(zé)收集、分發(fā)請(qǐng)求。當(dāng)一個(gè)請(qǐng)求過來時(shí)，master拉起一個(gè)worker進(jìn)程負(fù)責(zé)處理這個(gè)請(qǐng)求。

• master進(jìn)程也要負(fù)責(zé)監(jiān)控woker的狀態(tài)，保證高可靠性

• woker進(jìn)程一般設(shè)置為跟cpu核心數(shù)一致。nginx的woker進(jìn)程跟apache不一樣。apche的進(jìn)程在同一時(shí)間只能處理一個(gè)請(qǐng)求，所以它會(huì)開很多個(gè)進(jìn)程，幾百甚至幾千個(gè)。而nginx的woker進(jìn)程在同一時(shí)間可以處理額請(qǐng)求數(shù)只受內(nèi)存限制，因此可以處理多個(gè)請(qǐng)求。

2.3 事件模型

nginx是異步非阻塞的。

每進(jìn)來一個(gè)request，會(huì)有一個(gè)worker進(jìn)程去處理。但不是全程的處理，處理到什么程度呢？處理到可能發(fā)生阻塞的地方，比如向上游（后端）服務(wù)器轉(zhuǎn)發(fā)request，并等待請(qǐng)求返回。那么，這個(gè)處理的worker不會(huì)這么傻等著，他會(huì)在發(fā)送完請(qǐng)求后，注冊(cè)一個(gè)事件：“如果upstream返回了，告訴我一聲，我再接著干”。于是他就休息去了。此時(shí)，如果再有request 進(jìn)來，他就可以很快再按這種方式處理。而一旦上游服務(wù)器返回了，就會(huì)觸發(fā)這個(gè)事件，worker才會(huì)來接手，這個(gè)request才會(huì)接著往下走。

web server的工作性質(zhì)決定了每個(gè)request的大部份生命都是在網(wǎng)絡(luò)傳輸中，實(shí)際上花費(fèi)在server機(jī)器上的時(shí)間片不多。這是幾個(gè)進(jìn)程就解決高并發(fā)的秘密所在。

2.4 Nginx相關(guān)筆記

• Nginx 常見應(yīng)用技術(shù)指南[Nginx Tips]

• 深入剖析Nginx

三、rabbitMQ消息中間件

• （1）Broker：消息中間件實(shí)例, 可能是單個(gè)節(jié)點(diǎn)也可能是運(yùn)行在多節(jié)點(diǎn)集群上的邏輯實(shí)體

• （2）消息(Message)：消息由消息頭和消息體兩部分組成。消息頭中包括routing-key、priority等標(biāo)準(zhǔn)消息頭以及其它自定義消息頭，用于定義RabbitMQ對(duì)消息行為。消息體是字節(jié)流，包含消息內(nèi)容。

• （3）連接(Connection)：客戶端與 Broker 之間的 TCP連接

• （4）信道(Channel) ：Channel 是建立在 TCP 連接上的邏輯(虛擬)連接。多個(gè) Channel 復(fù)用同一個(gè) TCP 連接, 以避免建立 TCP 連接的巨大開銷。 RabbitMQ 官方要求每個(gè)線程使用獨(dú)立的 Channel, 禁止多個(gè)線程共用 Channel。

• （5）生產(chǎn)者(Publisher)：發(fā)送消息的客戶端線程

• （6）消費(fèi)者(Consumer)：處理消息的客戶端線程

• （7）交換機(jī)(Exchange)：交換機(jī)負(fù)責(zé)將消息投遞到相應(yīng)的隊(duì)列

• （8）隊(duì)列(Queue)：接收并保存交換機(jī)投遞的消息，直至被消費(fèi)者成功消費(fèi)。邏輯結(jié)構(gòu)遵循先進(jìn)先出FIFO。

• （9）綁定(Binding)：將隊(duì)列(Queue)注冊(cè)到交換機(jī)(Exchange)的路由表

• （10）虛擬主機(jī)(Vhost)：每個(gè)Broker下可建立多個(gè)vhost, 每個(gè) vhost 可建立獨(dú)立的 Exchange、Queue、綁定及權(quán)限系統(tǒng)。同一個(gè) Broker 下的 vhost 共享 Connection、Channel 和 用戶系統(tǒng)，就是說可以使用同一個(gè)用戶身份使用同一個(gè) Channel 訪問不同 vhost。

3.1 rabbitMQ消息中間件相關(guān)筆記

• RabbitMQ-最完整最全教程

• RabbitMQ實(shí)戰(zhàn)指南

四、ActiveMQ消息中間件

• （1）多種語言和協(xié)議編寫客戶端。語言: Java,C,C++,C#,Ruby,Perl,Python,PHP。應(yīng)用協(xié)議: OpenWire,Stomp REST,WS Notification,XMPP,AMQP

• （2）完全支持JMS1.1和J2EE 1.4規(guī)范 (持久化，XA消息，事務(wù))

• （3） 對(duì)Spring的支持，ActiveMQ可以很容易內(nèi)嵌到使用Spring的系統(tǒng)里面去，而且也支持Spring2.0的特性

• （4） 通過了常見J2EE服務(wù)器(如 Geronimo,JBoss 4,GlassFish,WebLogic)的測(cè)試，其中通過JCA 1.5 resource adaptors的配置，可以讓ActiveMQ可以自動(dòng)的部署到任何兼容J2EE 1.4 商業(yè)服務(wù)器上

• （5） 支持多種傳送協(xié)議:in-VM,TCP,SSL,NIO,UDP,JGroups,JXTA

• （6）支持通過JDBC和journal提供高速的消息持久化

• （7）從設(shè)計(jì)上保證了高性能的集群，客戶端-服務(wù)器，點(diǎn)對(duì)點(diǎn)

• （8） 支持Ajax

• （9）支持與Axis的整合

• （10）可以很容易的調(diào)用內(nèi)嵌JMS provider，進(jìn)行測(cè)試

五、Kafka百萬級(jí)吞吐實(shí)戰(zhàn)

kafka 最初是 LinkedIn 的一個(gè)內(nèi)部基礎(chǔ)設(shè)施系統(tǒng)。最初開發(fā)的起因是，LinkedIn 雖然有了數(shù)據(jù)庫(kù)和其他系統(tǒng)可以用來存儲(chǔ)數(shù)據(jù)，但是缺乏一個(gè)可以幫助處理持續(xù)數(shù)據(jù)流的組件。所以在設(shè)計(jì)理念上，開發(fā)者不想只是開發(fā)一個(gè)能夠存儲(chǔ)數(shù)據(jù)的系統(tǒng)，如關(guān)系數(shù)據(jù)庫(kù)、Nosql 數(shù)據(jù)庫(kù)、搜索引擎等等，更希望把數(shù)據(jù)看成一個(gè)持續(xù)變化和不斷增長(zhǎng)的流，并基于這樣的想法構(gòu)建出一個(gè)數(shù)據(jù)系統(tǒng)，一個(gè)數(shù)據(jù)架構(gòu)。

Kafka外在表現(xiàn)很像消息系統(tǒng)，允許發(fā)布和訂閱消息流，但是它和傳統(tǒng)的消息系統(tǒng)有很大的差異，

• 首先，Kafka是個(gè)現(xiàn)代分布式系統(tǒng)，以集群的方式運(yùn)行，可以自由伸縮。

• 其次，Kafka可以按照要求存儲(chǔ)數(shù)據(jù)，保存多久都可以。

• 第三，流式處理將數(shù)據(jù)處理的層次提示到了新高度，消息系統(tǒng)只會(huì)傳遞數(shù)據(jù)，Kafka 的流式處理能力可以讓我們用很少的代碼就能動(dòng)態(tài)地處理派生流和數(shù)據(jù)集。所以 Kafka 不僅僅是個(gè)消息中間件

Kafka 不僅僅是一個(gè)消息中間件，同時(shí)它是一個(gè)流平臺(tái)，這個(gè)平臺(tái)上可以發(fā)布和訂閱數(shù)據(jù)流（Kafka 的流，有一個(gè)單獨(dú)的包 Stream 的處理），并把它們保存起來，進(jìn)行處理，這個(gè)是 Kafka 作者的設(shè)計(jì)理念。

5.1 Kafka百萬級(jí)吞吐實(shí)戰(zhàn)相關(guān)筆記

• 手寫“Kafka筆記”

• Kafka源碼解析與實(shí)戰(zhàn)

六、Redis高性能緩存數(shù)據(jù)庫(kù)

6.1 Redis的數(shù)據(jù)結(jié)構(gòu)和相關(guān)常用命令

• Key：Redis采用Key-Value型的基本數(shù)據(jù)結(jié)構(gòu)，任何二進(jìn)制序列都可以作為Redis的Key使用（例如普通的字符串或一張JPEG圖片）

• String：String是Redis的基礎(chǔ)數(shù)據(jù)類型，Redis沒有Int、Float、Boolean等數(shù)據(jù)類型的概念，所有的基本類型在Redis中都以String體現(xiàn)。

• SET：為一個(gè)key設(shè)置value，可以配合EX/PX參數(shù)指定key的有效期，通過NX/XX參數(shù)針對(duì)key是否存在的情況進(jìn)行區(qū)別操作，時(shí)間復(fù)雜度O(1)

• GET：獲取某個(gè)key對(duì)應(yīng)的value，時(shí)間復(fù)雜度O(1)

• GETSET：為一個(gè)key設(shè)置value，并返回該key的原value，時(shí)間復(fù)雜度O(1)

• MSET：為多個(gè)key設(shè)置value，時(shí)間復(fù)雜度O(N)

• MSETNX：同MSET，如果指定的key中有任意一個(gè)已存在，則不進(jìn)行任何操作，時(shí)間復(fù)雜度O(N)

• MGET：獲取多個(gè)key對(duì)應(yīng)的value，時(shí)間復(fù)雜度O(N)

• INCR：將key對(duì)應(yīng)的value值自增1，并返回自增后的值。只對(duì)可以轉(zhuǎn)換為整型的String數(shù)據(jù)起作用。時(shí)間復(fù)雜度O(1)

• INCRBY：將key對(duì)應(yīng)的value值自增指定的整型數(shù)值，并返回自增后的值。只對(duì)可以轉(zhuǎn)換為整型的String數(shù)據(jù)起作用。時(shí)間復(fù)雜度O(1)

• DECR/DECRBY：同INCR/INCRBY，自增改為自減。

6.2 Redis高性能緩存數(shù)據(jù)庫(kù)相關(guān)筆記

• Redis高性能緩存

• Redis實(shí)戰(zhàn)

• Redis設(shè)計(jì)與實(shí)現(xiàn)

六、分布式系統(tǒng)常用技術(shù)及案例分析（PDF）

本PDF分為三大部分，即分布式系統(tǒng)基礎(chǔ)理論、分布式系統(tǒng)常用技術(shù)以及經(jīng)典的分布式系統(tǒng)案例分析。

• 第一部分主要介紹分布式系統(tǒng)基礎(chǔ)理論知識(shí)，總結(jié)一些在設(shè)計(jì)分布式系統(tǒng)時(shí)需要考慮的范式、知識(shí)點(diǎn)以及可能會(huì)面臨的問題，其中包括線程、通信、一致性、容錯(cuò)性、CAP理論、安全性和并發(fā)等相關(guān)內(nèi)容;同時(shí)講述分布式系統(tǒng)的常見架構(gòu)體系，其中也包括最近比較火的RESTful風(fēng)格架構(gòu)、微服務(wù)、容器技術(shù)等

• 第二部分主要列舉了在分布式系統(tǒng)應(yīng)用中經(jīng)常用到的一些主流技術(shù)，并介紹這些技術(shù)的作用和用法;這些技術(shù)涵蓋了分布式消息服務(wù)、分布式計(jì)算、分布式存儲(chǔ)、分布式監(jiān)控系統(tǒng)、分布式版本控制、RESTful、微服務(wù)、容器等領(lǐng)域的內(nèi)容。

• 第三部分選取了以淘寶網(wǎng)和Twitter為代表的國(guó)內(nèi)外知名互聯(lián)網(wǎng)企業(yè)的大型分布式系統(tǒng)案例，分析其架構(gòu)設(shè)計(jì)以及演變過程;這部分相當(dāng)于是對(duì)第二部分零散的技術(shù)點(diǎn)做一個(gè)“串燒”，讓讀者可以結(jié)合技術(shù)的理論，看到實(shí)戰(zhàn)的效果。

最后

手繪了下圖所示的kafka知識(shí)大綱流程圖（xmind文件不能上傳，導(dǎo)出圖片展現(xiàn)），但都都可提供源文件給每位愛學(xué)習(xí)的朋友，獲取鏈接：戳這里免費(fèi)下載

存儲(chǔ)、分布式監(jiān)控系統(tǒng)、分布式版本控制、RESTful、微服務(wù)、容器等領(lǐng)域的內(nèi)容。

• 第三部分選取了以淘寶網(wǎng)和Twitter為代表的國(guó)內(nèi)外知名互聯(lián)網(wǎng)企業(yè)的大型分布式系統(tǒng)案例，分析其架構(gòu)設(shè)計(jì)以及演變過程;這部分相當(dāng)于是對(duì)第二部分零散的技術(shù)點(diǎn)做一個(gè)“串燒”，讓讀者可以結(jié)合技術(shù)的理論，看到實(shí)戰(zhàn)的效果。

最后

手繪了下圖所示的kafka知識(shí)大綱流程圖（xmind文件不能上傳，導(dǎo)出圖片展現(xiàn)），但都都可提供源文件給每位愛學(xué)習(xí)的朋友，獲取鏈接：戳這里免費(fèi)下載

[外鏈圖片轉(zhuǎn)存中…(img-7vnUS5rL-1621056991940)]

總結(jié)

以上是生活随笔為你收集整理的深入理解Nginx：java业务逻辑层都用什么技术的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。