一、 前言 從過去的OA、CRM、ERP等單機即可滿足要求的系統到現代互聯網時代各大公司的分散式、微服務平臺，互聯網架構正在經歷著巨大的變革，技術也在不斷的更新迭代，這也意味著眾多軟體開發者們的壓力和挑戰正在不斷的加大，這種新技術更新的速度甚至讓我們望而卻步，而我們需要做的恐怕不僅僅是學習那麼簡單 ...
一、 前言
從過去的OA、CRM、ERP等單機即可滿足要求的系統到現代互聯網時代各大公司的分散式、微服務平臺，互聯網架構正在經歷著巨大的變革，技術也在不斷的更新迭代，這也意味著眾多軟體開發者們的壓力和挑戰正在不斷的加大，這種新技術更新的速度甚至讓我們望而卻步，而我們需要做的恐怕不僅僅是學習那麼簡單了，更要從巨集觀的角度根據當前的技術形勢及時做出更符合我們發展前景的決定。
這篇文章胖達會跟大家一起探究互聯網架構的演變歷程，並對每個歷程中的相關技術及應用做出合理的解釋，希望各位也能參考架構的這些發展過程，結合自己當前的項目架構有一個適當的定位，同時對自己未來應該學習的東西做出明確的計劃和安排。
二、 架構演變
在上一篇文章中胖達列出了幾種電商、P2P互聯網公司的系統架構，沒有看過的朋友請關註公眾號：Java知識共用，找到文章《電商、P2P等大型互聯網系統包含什麼業務模塊？》閱讀即可，參考文章中的架構圖可以看到大型互聯網公司系統的業務模塊、技術分佈其實是非常複雜，但是架構和技術永遠都不是架構師設計出來的，而是跟隨公司業務的發展不斷進行升級演變出來的，廢話不多說請聽胖達娓娓道來。
01 單機構建系統
這個其實不用多說，剛開始接觸Java的同學應該都非常清楚，做畢設或者平時練手最多的圖書館小項目基本都是這種架構，一個簡單的應用，配置一下資料庫連接，然後部署到自己電腦的tomcat伺服器上，啟動之後興奮的不得了。
02 Nginx負載均衡+伺服器集群
試想一下，如果我們一時興起做了一個個人博客並且部署到了我們的伺服器上，採用的是單機的構建方式，後來因為博客質量高竟然火了，訪問量快速增加，單台伺服器已經無法滿足我們的需求，時不時的就有粉絲抱怨博客沒法訪問了，是不是很頭疼？
穩住，這波不慌，這個時候胖達建議首先想想如何給那台可憐的伺服器泄泄火，讓伺服器的壓力降下來，有一個辦法就是給它加一個或者多個伙伴一塊來分攤下壓力，把這麼多請求分散到每個伙伴身上，從而提高這種負載的能力。
但是伙伴是有了，一系列的問題也就來了，胖達整理了一下，統一回答如下：
問題一：這麼多伙伴，應該識別什麼樣的指令來接收用戶的請求呢？
其實完全不用擔心伙伴們識別什麼樣的指令，只要讓它傻傻的站在那等待分配就可以了，因為有一種東西叫做負載均衡器，專門給伺服器分配這種請求，如果你不知道F5,那你應該知道Nginx,土豪錢多的公司一般會選擇前者這種硬體負載均衡器，但是大多數互聯網公司會選擇後者，因為能從軟體的角度解決的問題為啥用硬體呢，誰不想省錢啊？
瞭解Nginx，必須要知道它的三種功能：
1.反向代理
瞭解反向代理，首先要清楚什麼是正向代理，相信大家訪問國外的學習資源例如某hub（你懂的）的時候都用過FQ軟體-VPN，這種通過VPN訪問谷歌、Youtube等國外網站的過程中，我們知道我們的訪問目標伺服器是什麼，這其實就是正向網路代理。
而反向代理則不同，就像我們上圖中所看到的多台伺服器，如果經過反向代理，那我們其實並不知道實際訪問的伺服器是哪一臺，因為我們的請求被前面架設的Nginx自動分配給了某一臺伺服器，就比如說我們打10086人工客服，你一定記得“你好先生，我是10011號話務員，很高興為您服務”這樣的話，其實我們在打電話的時候並不知道由哪一個話務員來為我們服務，這些分配過程都是由10086服務台自動進行的，這裡的10086服務台其實就是我們系統中的反向代理伺服器，也既圖中的Nginx。
2.動靜分離
在做web開發的時候大家都清楚，js、html、圖片資源、文件資源這些其實都屬於靜態資源，供用戶直接訪問，並不需要編譯或者解釋，是一些放在那裡就可以用的東西，而jsp、java文件這些東西其實都需要被tomcat伺服器解釋一遍才能被機器識別，但是如果把它們都放在一起供用戶訪問，那每台伺服器的壓力豈不是很大，這個時候我們就可以做動靜的分離，將這些靜態的文件放置到Nginx伺服器上，後面的tomcat伺服器用來放動態的jsp、java文件，這樣的話就變向的給伺服器降低了壓力。
3.負載均衡
這個其實很明顯了，簡單來說，通過架設Nginx伺服器，經過一定的均衡演算法將用戶的請求合理分發給後面的伺服器，這個過程很好的降低了請求負載，讓每一臺伺服器都能舒舒服服的承載請求，做好自己的工作。
問題二：能確定伙伴之間公平分散請求嗎？
這個問題就具體到了Nginx的均衡演算法問題，只有通過合適的演算法均衡用戶請求到每台伺服器上才能保證伺服器不打架不撂挑子，否則其中某台伺服器不高興突然間罷工，剩下的伺服器可就遭殃了。
其實Nginx均衡演算法總共有十種，但是常用的一般是這兩種：
1.LC演算法（最近最少使用連接演算法）
這種演算法的規則其實就是判斷哪一臺伺服器一定時間段內的連接數比較少，就把用戶請求分發給它，其實就是誰的活少分配給誰，不能讓他太閑也不能讓其他伺服器太忙，否則就會掐架了。
2.輪詢演算法
輪詢這種演算法還是比較公平的，其實類似我們上學的時候排了一張值日表，周一的時候是小紅，周二的時候是小明等等等等，這樣就把活平均分配給了每一個人也既每一臺伺服器。
3.ip_hash演算法
這種演算法是通過ip取模的方式制定伺服器，首先通過ip欄位轉換成hash值，將取到的hash值與負載伺服器的總數取模，按照模值獲取負載ip列表中的伺服器，最終確定是哪一臺伺服器來承載這次請求，這種方式因為ip的hash值一致性原因，每一臺ip訪問的都是固定的伺服器，用的是同一臺伺服器上的session,從而解決了session一致性的問題。
問題三：這麼多伺服器怎麼返回用戶的請求呢？
其實這個問題換一種問法就是通過什麼樣的集群搭建模式來處理網路問題，常用的包括下麵幾種：
1.NAT模式
也稱為網路地址傳輸模式，用戶在實際訪問項目的時候實際上並不是的時候並不是直接去訪問tomcat伺服器，而首先要經過第一臺Nginx伺服器，但是這台伺服器的ip是虛擬ip，真實要訪問的ip其實是後面的tomcat伺服器ip，那麼在這一步就需要根據均衡演算法在配置中取出後面tomcat伺服器的真實ip並做網路跳轉，已到達訪問的目的，在返回用戶請求的時候，也是如此，必須通過tomcat伺服器的網路跳轉訪問到Nginx,繼而將請求返回到用戶方。
2.DR模式
也稱為直接路由模式，這種方式相較於NAT模式有一個區別就是在返回用戶請求的時候，不再通過中間伺服器進行轉發，而是直接轉發給了用戶，這樣做的目的其實也提高了網路傳輸的速度，降低了Nginx伺服器的壓力。
問題四：用戶每次都去跟不一樣的伙伴勾兌，這次找伙伴1，下次找伙伴2，那怎麼保證session一致呢？
這種情況其實是做負載均衡經常遇到的一個問題，如果不做處理，經常會遇到session丟失的問題，處理這個問題一般有下麵幾種方法：
1.ip_hash演算法固定session
就像上面均衡演算法所說的，通過ip的hash值取模，固定訪問某台伺服器，這樣就確保了用戶的session每次訪問都保存在同一臺伺服器上，不會出現找不到的現象，從而實現session一致性。
2.session廣播
也稱為session複製，就是指每個用戶登錄之後，只要是訪問了我的伺服器記錄了session，就會把session的信息在所有的伺服器上複製一份，這樣就能保證每台伺服器都包含這個用戶的session,當然這也是非常浪費的。
3.session持久化
其實就是將session的信息保存到資料庫、文件或者記憶體中，用這種持久化的方式將其保存到一臺公共伺服器上，這樣就能確保了session一致性，而我們一般採用的方式就是將其保存到redis中，方便存取而且記憶體讀取的效率很高。
4.客戶端存儲
基於cookie實現，將session直接存儲到cookie中，這種方案其實不是很安全，雖然能夠做到加密，但是道高一尺魔高一丈，總會有方法破解，而且cookie最多只能為4K，大小受到限制。
上面講到的這種架構方式，確實能夠短期內解決個人博客訪問量激增帶來的問題，但是有沒有想過一個問題，Nginx也是一臺伺服器，如果他掛了怎麼辦？還有誰能來給我們分配任務呢？難道讓這些伙伴乾瞪眼嘛？其實這種情況引出了一個面試題：如何避免單點故障？不慌，接著來看下一種方案。
03 HA高可用+負載均衡+伺服器集群
想要解決這種問題，大家一定可以想到，再加一臺Nginx不就行了嘛？沒錯，引入HA高可用就能解決這個問題，HA高可用是目前企業防止核心電腦系統因故障停機的最有效手段，但是如何實現這種高可用讓兩台Nginx互相切換呢？下麵還需要瞭解兩個新鮮的技術：LVS+KeepAlived:
1.LVS實現負載均衡
看到這個小標題，有人可能要噴我，說你都用了Nginx做了負載均衡了，為啥還要用LVS這種東西呢？
彆著急首先瞭解下LVS:
LVS的英文全稱是Linux Virtual Server，即Linux虛擬伺服器。它是由國防科大畢業的章文嵩博士開展的一個開源項目，在Linux記憶體2.6版本中已經成為內核的一部分。LVS主要用於多伺服器的負載均衡，工作在七層模型中的第四層-網路層，可以實現高性能，高可用的伺服器集群技術，並且可把許多低性能的伺服器組合在一起形成一個超級伺服器，它的配置非常簡單，有多種負載均衡的方法，而且穩定可靠，即使在集群的伺服器中某台伺服器無法正常工作，也不影響整體效果，另外它的可擴展性也非常好。
那麼這種解釋能解決疑惑嗎？當然不能，且看下麵：
由於LVS屬於內核級別的優化，而且工作在網路層，當做為負載均衡伺服器的Nginx和LVS處理相同的請求時，所有的請求和響應流量都會經過Nginx,但是使用LVS時，僅請求流量經過LVS的網路，響應流量由後端伺服器的網路返回,這樣的話，如果有大量的請求出現，那因為帶寬問題，LVS的效率就會有顯著的表現，Nginx的瓶頸也就出現了。
但是僅僅使用LVS作為負載均衡的話，一旦後端接受到請求的伺服器出了問題，那麼這次請求就失敗了。但是如果在LVS的後端在添加一個Nginx（或者多個），讓Nginx做動靜分離和反向代理，每個Nginx後端再有幾台應用伺服器，那麼結合兩者的優勢，既能避免單Nginx的流量集中瓶頸，又能避免單LVS時請求失敗的問題，何樂而不為呢？
2.KeepAlived實現HA高可用
KeepAlived從字面意思上來講就是保持活著，比如說我們兩台tomcat伺服器就是兩個小伙伴，兩個小伙伴商量著，要不然咱們一個人幹活一個人歇著，但是時長的要互相詢問一句：“老鐵？你累嗎？還能行不？”，如果這個時候他回覆還行，那麼我就安心玩我的就行了，但是如果他一直沒搭理我，怎麼問怎麼不應聲，那它應該是累了，你是不是需要把他的活接過來啊，沒人乾肯定不行。
嚴肅點哈，KeepAlived技術其實主要就是通過發送心跳包的方式，在每台伺服器之間進行狀態偵查，如果發現有宕機或者停止運行的伺服器，立刻讓閑置伺服器運行起來實現主備複製和轉移，當然這其中還需要一種容錯技術來將系統運行的狀態恢復到本應該有的狀態，避免因為某台伺服器的宕機影響執行的結果。
04 CDN內容分髮網絡+Varnish伺服器集群
隨著個人博客用戶量的不斷提升，我們的項目雖然已經可以應付的了這麼多用戶量了，但是略微還有點慢，又或者有點卡，而且還有一個問題，中國的網路環境一般都是南方多用電信網路，北方多用移動聯通的網路，電信的網路訪問聯通的網路明顯能感覺的出來會特別卡，如果我們的博客放到了北方的聯通網路上，而大量的用戶來自於南方，對用戶來講豈不是很痛苦，每次訪問的時候下載一些靜態資源都會特別的慢，時間久了，可能會損失大量的用戶，如何解決這些卡、慢的問題呢，下麵再來看幾種優化技術：
1.CDN內容分髮網絡
CDN內容分髮網絡其實就是構建在網路之上的內容加速器，依靠部署在各地的邊緣伺服器，通過中心平臺的負載均衡、內容分發、調度等功能模塊，使用戶就近獲取所需內容，降低網路擁塞，提高用戶訪問響應速度和命中率。
也就是說，如果我們系統中有一個jquery.min.js,直接放在我們北方的網通伺服器上，南方的用戶下載會特別的慢，但是如果我們直接用某個高速CDN伺服器上的jquery資源引入，那用戶下載的速度豈不是會快速提高，用戶體驗也會變得更好。
2.Varnish伺服器集群
Varnish這個詞很多人都很陌生，其實它就是一個HTTP加速器和反向代理伺服器，也是為了優化方案而引入的技術，這種技術一般被應用在Nginx後面，在tomcat的前面，主要用來優化Nginx的動靜分離功能。
之前提到將html、js這些靜態的資源都放置到Nginx伺服器中，java、jsp等文件放置到tomcat伺服器中，這樣能夠更好的分攤tomcat伺服器的壓力，但是這個地方還有優化的空間，想一想是否在開發過程中存在一些jsp文件、java文件基本上是不變的，也就是說不管怎麼調用，這些東西短期內都是固定的，那我們能不能把這些文件也提出來，讓Nginx直接調用以降低tomcat伺服器壓力呢？答案是可以的，直接將一些短期內不變得文件配置進Varnish伺服器中即可。
05 資料庫讀寫分離
之前的部分我們對tomcat伺服器左側進行了優化，但是右側的資料庫還是孤零零的只有一臺，這樣的話，個人博客項目還好只有讀操作，能夠應付得了，但是如果我們擴展業務，將博客做成了csdn這樣的博客平臺，有大量的用戶頻繁進行讀寫操作，那我們的資料庫還能應付嘛？肯定需要優化了，首先我們會想到的就是把資料庫的讀寫進行分離。
資料庫讀寫的分離一般需要設置主從資料庫，主庫只用來寫數據，從庫用來讀取數據，而兩個資料庫之間則需要實現數據的同步，否則會出現數據差異，實現資料庫同步的方法有很多，mysql提供了一種方法是binlog，目前還是比較普遍的，具體的操作配置步驟這裡不再描述，以後有機會會嘗試寫寫。
06 NOSQL資料庫 + 分散式搜索引擎
讀寫分離做完之後，過不了多久會發現，如此多的用戶讀寫數據，主從庫的壓力也在日益攀升，變得越來越大，那麼如何優化讀取、寫入數據的速度呢？
1.引入redis資料庫
既然我們的Mysql資料庫讀寫壓力那麼大，那麼我們就在它的前面添加一層NOSQL記憶體資料庫作為盾牌,redis作為最常用的NOSQL資料庫一直以來深受大家的歡迎，而且因為是記憶體中讀寫數據，所以效率也是非常的高，將它放到關係資料庫的前面，用來存放一些高頻率、熱點的常用搜索數據，能夠抵抗大量的搜索壓力，這樣的話在讀寫分離，redis分攤壓力的情況下，Mysql的資料庫壓力會大規模降低。
2.增加分散式搜索引擎
你以為這就完了嗎，不，還不夠，為了優化搜索的速度，給用戶帶來更好的體驗效果，引入分散式搜索引擎才是好的選擇，目前行業內使用最廣泛的分散式搜索引擎非Elasticsearch莫屬。
Elasticsearch技術簡稱ES，是一個基於Lucene的搜索伺服器。它提供了一個分散式多用戶能力的全文搜索引擎，基於RESTful web介面。Elasticsearch是用Java開發的，並作為Apache許可條款下的開放源碼發佈，是當前流行的企業級搜索引擎。
Elasticsearch分散式搜索引擎可以進行分散式實時文件存儲，並將每一個欄位都編入索引，使其可以被搜索，並且可以擴展到上百台伺服器，處理PB級別的結構化或非結構化數據，這樣的話我們就可以通過這種方式構建索引，再去查詢就更加減輕了關係資料庫的壓力。
07 NOSQL資料庫（HA）+分庫分表 + MyCat
隨著博客平臺的發展，海量用戶的暴增，搜索類目的多樣性，用戶體驗的實時性，對網站提出了更高的要求，必須滿足高併發、高可用、高性能的要求才能繼續業務的發展，對於我們程式員而言要做的仍然需要更新當前的架構技術，以面對更強大的衝擊和考驗，那麼我們還要如何優化我們的系統呢？第七個階段我們又要引入三種方案：
1.NOSQL資料庫的HA
通過在Mysql伺服器前面添加redis伺服器確實能夠抵禦不少的對Mysql資料庫的讀寫壓力，但是對於前面的盾牌來講，難道它就沒有壓力嗎，怎麼降低redis伺服器的壓力呢，首先我們會想到去配置redis集群的方式加一臺或者幾台伺服器，但是配置redis集群其實經常會出現錯誤，而且對於redis集群來說，經常要求redis伺服器可以自動擴容，為瞭解決這些問題更好的管理redis集群，我們可以選擇引入分散式 Redis 解決方案，前段時間redis官方的3.0出了穩定版，3.0就可以支持集群管理的功能。這裡選擇的是國產的分散式 Redis 解決方案-Codis。
Codis 是一個分散式 Redis 解決方案, 對於上層的應用來說, 連接到 Codis Proxy 和連接原生的 Redis Server 沒有明顯的區別, 上層應用可以像使用單機的 Redis 一樣使用, Codis 底層會處理請求的轉發, 不停機的數據遷移等工作, 所有後邊的一切事情, 對於前面的客戶端來說是透明的, 可以簡單的認為後邊連接的是一個記憶體無限大的 Redis 服務。
2.分庫分表
隨著業務的遞增，分庫分表的技術也需要運用到如此龐大的項目中，主要是因為各種業務表正在變得越來越大，例如用戶表、博客表等等，你會想到如果每個業務表都能分開存放那該多好，添加多個資料庫伺服器，每個伺服器負責一塊業務表的維護管理，資料庫1存放用戶數據，資料庫2存放博客信息，從而達到進一步細分資料庫的目的，而這種拆分資料庫的方式就叫做的垂直拆分方式。
還有一種拆分方式是這樣的，比如說我們的用戶表數據量非常非常大，一張表數據達到了8千萬，那我們查詢讀取這張表的時候會不會特別慢，即便你已經垂直拆分到了一個伺服器上進行管理，但是你仍然不能解決一張表8千萬的問題，那麼如何解決呢？聰明的你會想到分表存放，這種方式就是水平拆分方式，將用戶表分成表1、表2、表3......,通過這樣的方式你可以將這8千萬的用戶分到子表中，而具體的分表方式可以採用很多種方案，例如進行ID取模，具體方式由於篇幅問題不再描述。
3.MyCat
分庫分表之後，你會發現資料庫壓力真的變小了很多，但是也會有很多不方便的事情，比如說
- 分散式事務提交問題
- 分庫分表的運維和獲取問題
- 跨資料庫的join聚合查詢問題
- Mysql中自增欄位（AUTO_INCREMENT)還能用嗎？
- 某些約束條件在分庫分表的環境下會不會特別複雜了？
這個時候你會用到分庫分表中間件-MyCat，它是一個徹底開源的，面向企業應用開發的大資料庫集群，支持事務、ACID、可以替代MySQL的加強版資料庫，一個可以視為MySQL集群的企業級資料庫，用來替代昂貴的Oracle集群 ，一個融合記憶體緩存技術、NoSQL技術、HDFS大數據的新型SQL Server，結合傳統資料庫和新型分散式數據倉庫的新一代資料庫中間件產品。
08 分散式文件系統
在系統的發展過程中，會發現有一些圖片、視頻、Excel等不同格式的大文件也需要做出處理，比如說大型系統中的用戶頭像，8千萬的用戶就需要有8千萬的頭像，每張頭像都需要占用一定的存儲空間（一般來說4K到幾百M都有可能），那麼如何去處理這些文件的存儲呢？保存到資料庫中技術上完全可以，但是僅限於說說哈，如果實際這麼做了可能你的系統會面臨很大的壓力。
為瞭解決這種問題，就出現了分散式文件系統這樣的技術，典型比較通用的包括MogileFS、FastDFS。
MogileFS是一個開源的分散式文件存儲系統，是由LiveJournal旗下的Danga Interactive公司開發。目前使用MogileFS的公司非常多，如日本排名先前的幾個互聯公司以及國內的Yupoo(又拍)、digg、豆瓣、大眾點評、搜狗等，分別為所在的組織或公司管理著海量的圖片。以大眾點評為例，用戶全部圖片均有MogileFS存儲，數據量已經達到500TB以上。
FastDFS是由阿裡資料庫大神開發，是一個開源的輕量級分散式文件系統，它對文件進行管理，功能包括：文件存儲、文件同步、文件訪問（文件上傳、文件下載）等，解決了大容量存儲和負載均衡的問題。特別適合以文件為載體的線上服務，如相冊網站、視頻網站等等。
09 應用服務化拆分 + 消息中間件
如果思考過京東、美團、淘寶等等這些大型互聯網公司的業務模塊，你會發現他們每增加一塊業務，其實就是在增加一個業務組件，比如說某生活服務公司的業務分佈如圖所示：
在上圖中會發現業務組件部分包括了用戶、支付、搜索、推薦、地理位置等等，其中的每一個業務組件其實都對應著一項服務，而且都有專門的資料庫伺服器進行維護管理，也就是之前提到的分庫分表，而分庫分表拆分的是數據，那如何對業務進行拆分，將每一種業務分成一種服務，需要什麼服務就去調用什麼服務，從而讓系統更加的專一和精確，如果對應到我們的架構上，就需要在數據層和應用層添加一個層面——服務組件層，其實這種架構方式就是應用服務化拆分。
提到應用服務化拆分，就不得不提及服務化治理框架，這裡就需要引入三種主流的應用服務化技術：Zookeeper、Dubbo以及消息解耦非同步的消息中間件技術——MQ消息隊列.
1.Zookeeper
一般來說，Zookeeper常常跟dubbo是配合使用的，因為Dubbo需要進行服務註冊，而ZooKeeper 一個最常用的使用場景就是用於擔任服務生產者和服務消費者的註冊中心，服務生產者將自己提供的服務註冊到 ZooKeeper 中心，服務的消費者在進行服務調用的時候先到 ZooKeeper 中查找服務，獲取到服務生產者的詳細信息之後，再去調用服務生產者的內容與數據。
2.Dubbo
提到服務治理，dubbo絕對是一個優秀的服務治理框架，它可以通過透明化的遠程方法調用，就像調用本地方法一樣調用遠程方法，只需簡單配置即可，這樣不管是擴展了幾種業務組件，都可以像調用本地方法一樣調用其他的業務方法，使用起來非常方便，用過的人一般都知道，只需要加一個註解就可以使用其方法，而且調用的效率非常高。
3.MQ消息隊列
MQ消息隊列已經逐漸成為企業IT系統內部通信的核心手段。它具有低耦合、可靠投遞、廣播、流量控制、最終一致性等一系列功能，成為非同步RPC的主要手段之一。比如在電商系統中，來自訂單下載轉化後的大量訂單需要推送到物流配送管理系統中，就需要通過MQ這種技術來處理讓物流系統慢慢的按照資料庫能承受的併發量，從消息隊列中拉取並配送訂單，從而讓流程更加有序、穩定。
當今市面上有很多主流的消息中間件，如老牌的ActiveMQ、RabbitMQ，炙手可熱的Kafka，阿裡巴巴自主開發RocketMQ等。
10 微服務架構
上一個架構演變的階段作為目前主流的系統架構來說，完全可以抵住當前流量所帶來的壓力，但是未來隨著業務和用戶量的增長，仍然還會有更大的挑戰出現，2012年微服務的概念被提了出來，它的基本思想在於考慮圍繞著業務領域組件來創建應用，這些應用可獨立地進行開發、管理和加速。在分散的組件中使用微服務雲架構和平臺，使部署、管理和服務功能交付變得更加簡單。在微服務架構中，每個服務都是自我包含的，並且實現了單一的業務功能，而這種架構也必將成為未來的發展趨勢，目前也有很多微服務的框架已經落地並迅速發展，比如說SpringCloud微服務框架。
Spring Cloud是一系列框架的有序集合。它利用Spring Boot的開發便利性巧妙地簡化了分散式系統基礎設施的開發，如服務發現註冊、配置中心、消息匯流排、負載均衡、斷路器、數據監控等，都可以用Spring Boot的開發風格做到一鍵啟動和部署，在未來的微服務盛行的趨勢下，SpringCloud也必將成為Java程式員必須掌握的框架之一了。
三、 總結
在這篇互聯網架構的演變中，胖達只是簡單的對一些技術進行了說明，重點說明的是每一層的架構所引入的技術到底是為什麼會出現在這一層，具體解決了什麼樣的實際問題，不管怎麼樣，技術發展如此快速的時代，我們每一個程式員都不應該一直埋頭於技術的研究，偶爾抬起頭看看架構的發展和未來的趨勢，或許對我們的程式之路有一個更巨集觀的瞭解，只有這樣，我們才能離職業危機更遠，希望每一位認真閱讀這篇總結文章的朋友都能有所收穫，如果喜歡請關註我的技術公眾號，歡迎互撩交流探討
