互聯網公司分佈式集羣架構圖入門解析（簡單通俗易懂，超詳細）
1、小型公司網絡架構
狗子是某大學計算機專業本科應屆畢業生，因爲本身的技術不錯，再加上互聯網產業的巨大利潤的驅使，狗子決定走上創業這條路，因而，狗子聯合了同窗二黑，雞子，狗蛋等人花費了幾個月的時間寫出了一套網站，是關於足球資訊的pc端網站加上手機APP客戶端。如今產品測試成功了，準備發佈了，狗子想到了兩個問題：java
1.網站須要服務器
狗子以前全部的代碼測試都是在本地服務器或者局域網上進行的，如今須要把產品發佈到外網上，讓全部的人都能訪問，所以再用本身的電腦當服務器顯然很不現實，因而，狗子去買了一臺服務器，在上面裝了jdk,tomcat，mysql等必備環境，把網站搭了起來，又通過了不少測試，運行毫無問題了，經過網站的ip能夠訪問而且實現功能了，並且app的後臺也在服務器上測試成功了，目前公司的架構如圖所示：
那麼問題又來了：mysql
2.網站須要域名
顯然，若是讓各地的用戶須要記住你服務器的ip地址才能訪問你的網站的話，那是會被用戶拿刀追着砍的。所以，狗子須要一個便於記住的域名，之後在瀏覽器輸入這個域名就可以訪問這個網站，因此，狗子拿着申請下來的各類資質，找到了域名販賣商，通常是騰訊阿里巴巴這種代理販賣商，花了一筆錢，從它們的手上購買了域名，完全實現了網站經過域名就能訪問的功能。這裏須要講解一下經過域名訪問的原理：nginx
域名訪問原理
經過ip訪問至關於用戶直接訪問輸入的ip所指向的服務器，而經過域名訪問，是用戶輸入域名以後，請求先被髮送到域名管理者所控制的DNS服務器中，DNS服務器中有一個數據庫，數據庫中存有這個域名所對相應的ip地址，DNS服務器當了一箇中間人，將請求轉發到這個ip地址對應的服務器，就實現了經過域名訪問，所以，經過域名訪問本質上仍是經過ip訪問。那麼，狗子公司的架構圖就應該是下面這樣：
程序員
解決了這兩個問題，狗子的產品順利的發佈了，通過一兩個月的運營，慢慢地發掘了一小批用戶，實現了小幅盈利，狗子開始沾沾自喜了，原來，掙錢就這麼容易啊。然而很快，現實給了初出茅廬的狗子當頭一棒：一個連黑客都算不上的惡意用戶，經過本身寫的一個小小的程序，竟然把狗子的服務器搞崩了，這是怎麼一回事呢？redis
服務器防火牆概念
讀者可能也瞭解一些，用戶經過網站向服務器發送請求，服務器處理請求再對用戶進行響應對服務器的內存是有開銷的，可是，讀者可能不清楚的是，這種開銷有多麼大。每當一個用戶向服務器發送請求，服務器都要啓動一個線程去處理這個請求而且響應給用戶。這之中耗費的服務器內存差很少是1mb以上級別的，更別說是再加上其中的服務器處理數據進行的各類操做了。也就是說，用戶發送一個東西，服務器會損失1mb以上的內存，多發幾個，服務器就該受不了了。sql
攻擊狗子服務器的人就是寫了一個簡簡單單的小程序，重複屢次地向服務器發送請求，服務器在短期以內沒有這麼多內存去處理這麼多請求，天然就宕機了，就崩了。數據庫
搞懂了這些，狗子天然就想出了應對策略，因而，他給本身的服務器開啓了防火牆，經過配置防火牆，實現了禁止同一個用戶在短期內重複屢次頻繁發送請求，他的服務器也能夠安心地工做了。編程
固然，有的讀者可能會問了，那麼，防火牆禁止了單一用戶短期內屢次重複發送請求，那麼若是我是一個黑客，經過種木馬等黑客手段控制了數以千計甚至更多的其餘用戶的電腦，讓這些不一樣的電腦去短期內攻擊服務器，可不能夠攻擊成功呢？答案是確實能夠，這些被控制的電腦就是DDOS攻擊中的肉雞，這裏有些跑題了，在本文再也不贅述。注意，配置這種攔截單一ip防火牆只是基本操做，甚至買來的服務器會自帶。之因此狗子的服務器沒有是由於只有他足夠的「初出茅廬」，才能給讀者解釋清楚：）。小程序
那麼，咱們如今的架構圖就應該是這樣：
瀏覽器
2、中型公司網絡架構
狗子的公司越辦越大，愈來愈多的用戶開始使用他的軟件看各類足球諮詢，並且，用於用戶的基數變大了，天天增加的用戶數量都在變多，之前多是天天有十個新用戶，那麼如今就是天天有了一百個新用戶。在一個晚上的服務器宕機事故出現以後，狗子終於意識到，本身的單臺服務器應對日益龐大的用戶羣已經開始體力不支了。因而，他用了以前積攢下來的收益，又購入了三臺服務器，而且用其中一臺服務器單獨運行數據庫，做爲數據庫服務器。
那麼如今問題來了，這四臺服務器怎麼一塊兒使用，同時服務於一個網站的運營呢?
解決方案有兩個：
1.三個服務器同時運行相同的代碼，在代碼頁設置三個用戶入口，若是用戶進入一個入口發現進不去，就選擇另外一個入口，每一個入口對應一臺服務器
這樣作的好處是簡單方便，直接把代碼往另外兩個服務器一拷貝 而後更改一些其中的設置，再設置三個入口就好了。可是缺點也是很明顯的，顯然用戶的第一反應都是點擊第一個入口，只有當第一個入口進不去的時候纔會選擇另外兩個服務器，並且等到之後用戶數量愈來愈大，難道咱們要設置幾十幾百個入口讓用戶一個一個去試嗎？這顯然又是一個被用戶追着拿刀砍的行爲。（當程序員能夠體驗死亡如風，常伴吾身的感受）因此，這個方法顯然不太現實，不過這個方法也是有它的應用場景的，好比說在一些學校的官網的在校生入口，因爲在校生是畢業一批又新來一批，因此用戶體量不會有太大的增加，所以纔可使用這個方法。這種方法的架構圖是這樣的：
2.負載均衡
狗子諮詢了一些在中大型互聯網公司的學長，終於找到了一種解決這個問題還不像第一種方法那樣容易有生命危險的辦法，那就是nginx。
nginx是個什麼東西呢？是用來作服務器負載均衡的，說白了就是當用戶發送請求的時候，先通過nginx這個中間人，nginx會去感覺哪一個服務器比較閒，就會把請求發送到這個比較閒的服務器上去，這樣運行多了，就能夠作到每一個服務器相對的負擔比較平衡，這就是負載均衡。nginx能夠放在服務器本機，也能夠放在單獨的一個服務器中，nginx這個中間人會向各個服務器分發請求，而且nginx的性能十分高超，每秒百萬級如下數量的請求均可以處理。你可能要問了，若是狗子把nginx單獨放在一個服務器上，那麼他的三臺服務器怎麼對應到同一個域名上呢？他是否須要給每一個nginx分發的服務器也就是那三臺購買三個域名呢？固然不用，事實上，如今咱們對外的公共ip已經變成了安裝nginx的服務器的ip了，也就是說，咱們只要把域名映射到這個nginx服務器就能夠了，而後nginx中會有配置，咱們只要在配置中寫下三個服務器的ip，nginx之後就能把請求分發過去了。那麼，咱們如今的架構圖就變成了下圖這樣：
狗子還想對服務器作作優化，像是session這種東西，只是簡簡單單的一個session請求，卻要耗費服務器那麼多的性能，有沒有一種方法，可以對這方面作一些改進呢？
固然有，解決方案就是redis。
redis的做用
redis是一種數據庫，咱們比較熟知的數據庫有mysql，sqlServer，oracle等，那麼這個redis又是個什麼玩意？
redis和上述幾種數據庫不一樣，它是緩存數據庫，也就是說，redis是致力於短時存儲的，redis並非從硬盤中拿取和處理數據，它對數據的處理都是在內存中，因爲內存的數據處理速度不知道比磁盤高到哪裏去了，因此redis的性能也是碾壓mysql，sqlServer，oracle這種數據庫的，這無關於軟件優劣，純粹是由於硬件層面的因素。不過redis由於是在內存中，所以只要機器一關閉，內存中redis存儲的東西就會消失了，不過redis也能夠將數據持久化存儲到mysql這些數據庫中，可是一涉及到對硬盤的操做，redis的性能就下來了。所以，咱們的redis經常是用來存儲像是用戶的登陸狀態這種短時須要的數據，而去把用戶登陸註冊的時間備份到硬盤上的數據庫。那麼，咱們如今的架構圖就變成了以下這樣：
又過了一段時間，隨着用戶體量愈來愈大，數量級達到了上萬上十萬的時候，狗子發現一直以來，本身都忽略了一個問題，儘管本身增長了服務器，加了負載均衡，還啓用了redis緩存數據庫，爲了使用戶訪問的速度增長還有讓服務器的負載不那麼大，可是，網站處理數據的方式本質上是對數據庫進行增刪改查，而如今咱們的數據庫服務器只有一臺，數據庫處理數據自己就是一項複雜耗費內存的工做，如今的一臺數據庫服務器更是杯水車薪，所以，在中小型公司的網站架構中，最早撐不住的每每是數據庫服務器。
固然，狗子又有了解決辦法。他又購入了兩臺服務器看成數據庫服務器，而後把數據庫進行了分庫分表的操做，分別把數據存在三臺數據庫服務器上。固然狗子以爲這還不夠，所以，他又使用了一種技術，將數據庫進行了讀寫分離。
讀寫分離理解起來很簡單，和它的字面意思同樣，就是把從數據庫中寫入數據和從數據庫中拿取數據進行分離，以此來達到減小數據庫服務器負擔的做用。用來讀取數據的服務器和用來寫入數據的服務器會在用戶進行操做以後延遲一段時間進行數據同步，通常來講延遲時間不會太長，極可能用戶都不會覺察到。那麼，咱們如今的架構圖就變成了下圖這樣：
能夠看到，咱們的圖上新出現了「集羣」這個詞，不錯，互聯網常常說起的xxx集羣終於在咱們眼前解開了神祕面紗，也就是多臺服務器同時協同處理事務，就能夠稱做一個服務器集羣。
3、大型公司網絡架構
時光飛逝，轉眼間五年的時間過去了，狗子已經從一箇中小型互聯網公司的小老闆搖身一變成了一個上市公司總裁，和馬雲馬化騰等it行業巨佬互動成了他的平常，他的一句話能夠動搖it界，他的網站也擁有了上億的用戶。。。。。
到了這種程度，狗子的公司網絡架構已經變成了下圖這樣：
（內容比較多，看不清記得放大哦）
能支持上億人訪問的服務器確定不止這麼幾個，只是象徵性地畫了幾個。同時，咱們把redis服務器與mysql服務器進行了連線，是由於咱們前面說過redis能夠將數據存入持久性數據庫，這裏咱們能夠用來記錄登陸時間之類的信息。同時，圖中的mysql服務器是重疊在一塊兒的，不要覺得僅僅只有兩臺服務器。
隨着公司變爲巨頭，狗子的經驗不斷累積，他發現本身的公司雖然體量很大，開發的產品愈來愈多，功能愈來愈全面，可是老是有那麼一部分的功能是重複的。假如在一個新的頁面或者產品中，剛開始開發時有那麼10%是和之前開發過的頁面或者產品的功能是重複的，那麼，等到這個新東西的功能開發接近完善的時候，就可能會有70%的功能和從前開發的同樣。仔細想一想這是一件很可怕的事情，狗子竟然畫了70%的開發時間和開發成本在作之前早就作過的事情。
這狗子就不能忍了，因而他想到了一個好辦法，既然面向對象編程語言中有封裝的這種概念，把代碼的重複部分封裝起來便於重複使用，那麼產品和產品之間爲什麼不能封裝相同的東西便於使用呢？
因而，他開始實現微服務的概念，解釋起來可能一上來比較難於接受，咱們先來看，剛剛咱們的架構圖中的產品實際上能夠當作一整個系統，假設這個系統叫作系統A。那麼，咱們如今開發出來了其它的各類產品或者各類頁面，也能夠看做是新的系統B和系統C。如今，系統ABC之間有不少重複的部分，因而，咱們想到了將這些重複的部分放到一塊兒，供三個系統同時調用。那麼實際上，這個重複的部分就是被封裝起來的微服務，微服務是一種模塊化開發，把產品的功能提煉成多個模塊，在開發時把模塊拼接起來，就能夠省去大量的工做。爲了實現一個模塊，模塊中也須要帶有服務器集羣等東西。聽了這些，咱們下面的架構圖看起來應該沒有那麼難懂了：
這些與技術無關，而是一種開發理念，一種思想，有了這種思想，才能在成千上萬的用戶需求之間找到共通，提高開發效率，節省成本。
狗子有了這種思想，並實現了他，終於戰勝了全部競爭對手，迎娶白富美，走上了人生巔峯。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
後來，他夢醒了。。。