036 互聯網的框架演變

　　最新要寫這個方面的知識，而後，發現網上的知識層次不一，至於怎麼整理，也是一件比較頭疼的事情。

　　因此，在這裏，先列舉出一些比較好的整理。最後，在此基礎上，進行梳理成本身的文檔。

一：這個是從開始到目前演變中針對技術作的總結

1.說明：

　　大型網站的技術挑戰主要來自於龐大的用戶，高併發的訪問和海量的數據，任何簡單的業務一旦須要處理數以P計的數據和麪對數以億計的用戶，問題就會變得很棘手。大型網站架構主要就是解決這類問題

 

2.各個階段的技術

　　最開始的網站

　　　　

 

　　第一步：物理分離應用數據庫

          網站運營的最開始階段，在天天高峯期的時候老是會出現宕機現象而且常常會有數據庫和網站應用掙搶硬件資源的情況出現，這種狀況下，最簡單的方案就是把應用和數據庫分開部署到不一樣機器上，以提升各自可以佔有的資源。

　　　　

 

          第二步：頁面緩存和靜態化

          隨着網站訪問量的迅猛攀升，系統的響應會開始變慢，主要緣由是由於訪問數據庫的鏈接增多，數據庫服務器的硬件配置又決定了只能提供必定數量的鏈接。因爲網站裏的不少內容是不多更新的。因而能夠把這些頁面緩存起來或者靜態化，減小對數據庫的訪問。這一步對技術上有所要求：頁面緩存技術，模板技術。頁面緩存提議Squid等幾種方案，靜態化可經過生成靜態HTML方式實現。 

           第三步：頁面片斷緩存

           頁面片斷緩存可採用ESI、OSCacheD等框架來進行實現。

           第四步：數據緩存

           數據緩存可採用ehcache、OSCache或獨立實現的緩存框架來實現。這步演變對技術上的要求：Map數據結構、程序語言中的Map數據結構（例如JAVA中的HashMap、TreeMap等）、所採用的緩存框架的實現方式（緩存內容的存儲方式、查找算法和失效算法）

           第五步：水平擴展應用服務器

           若是單純是訪問量高形成了服務器壓力過大，那就只能採用增長應用服務器，進入水平擴展階段。那麼如何讓訪問平均分配到每臺應用服務器上。這裏先用軟件負載均衡技術。軟件負載均衡技術可選：DNS輪詢、Apahce、Nginx、LVS等。又如何保持信息同步呢，如session同步。可採用信息寫入數據庫、寫入共享文件、cookie或在各臺機器上同步狀態信息等。如何保證數據緩存的同步？可採用緩存同步或分佈式緩存。如何讓文件相關的功能繼續可用 ，例如文件上傳功能等。可採用共享文件系統或存儲設備，採用前者的居多一些。這一步須要積累的知識有1.負載均衡技術，包括但不限於硬件負載金衡技術（四層，七層等）、軟件負載均衡技術、負載均衡算法、轉發協議、（如VS/NAT、VS/TUN、VS/DR）所選用的技術的實現細節（如LVS的實現）等。2.容災技術，包括但不限於ARP、Linux Heart-beanting等。3.狀態信息或緩存同步技術，包括但不限於cookie、UDP協議、組播、數據同步框架的實現（例如jgroups等）。4.共鄉文件原理,如NFS等

　　　　

 

            第六步：分庫

            以上工做完成後，你的團隊能夠作各類各樣的小調優工做，例如操做系統調優、Apache調優、JVM調優等等。分庫的實現對技術沒有過高的要求，僅在於整理業務，進行拆分，並相應的對程序進行適當的修改。

            第七步：分表、DAL、分佈式緩存

            因爲數據庫數據量太大，分庫每每不可以解決系統緩慢，這時，須要採起適當的分表和數據庫調優，因爲服務器沒有那麼多內存能夠提供緩存，因此開始採用分佈式緩存。問題： 在進行分表時，發現很明顯的問題：分表後致使訪問數據庫的程序複雜度提升。由於在查表時必然要先考慮分表規則。要將這一層統一 ，最好的辦法就也就是著名的DAL。增長數據訪問層。分佈式緩存可採用的方案有memcache、JbossCache等。分表時應作的知識儲備：動態Hash、Consistent Hash 、分佈式緩存實現原理、數據庫鏈接管理、數據庫操做的控制等。

　　　　

            第八步：改變應用服務器水平擴展環境

            當Apache、nginx或LVS等軟件負載均衡方式已經沒法承受巨大的訪問量的調度壓力時，可考慮購買硬件負載均衡設備。如F五、Netsclar、Athlon等，也可從業務角度進行劃分，構建不一樣的業務軟件負載集羣組。文件共享方案出現瓶頸時，這個時候能夠考慮購買昂貴的存儲設備 。如NAS等，也可考慮自行設計或是採用成熟的分佈式文件系統。

            第九步：數據讀寫分離與廉價的存儲

            如服務器增長太多了，數據庫鏈接至關激烈，讀寫比至關高，這時可構件大型數據庫集羣或數據讀寫分離。數據讀寫分離可選擇的方案或程序級的同步方案，在實現讀寫分離的時候要同步改造DAL，以適應新的演變。廉價的存儲方面有Google的Bigtable、新浪的 Memcachedb等。應具有的知識儲備：數據庫自行復制、同步方案及實現原理（如Oracle的Standby、MySQL的Replication等）；數據延遲以及不一直的解決方案。讀寫分離規則判斷。

　　　　

 

            第十步：使用反向代理與CDN加速網站響應

　　　　　　

 

　　　第十一步：使用分佈式文件系統與分佈式數據庫

　　　　　　

　　　　第十二步：使用nosql與搜索引擎

　　　　　　

　　　　第十三步：業務拆分　　　　

　　　　　　

　　第十四步：大型分佈式應用時代

　　　拆分紅分佈式後一個很明顯的需求就是高效、穩定的通訊和調用框架。

　　　管理好大型分佈式的應用，涉及到陸游、以來、版本、錯誤追蹤、檢測和報警等多方面的問題。

　　　合理拆分，涉及業務的整理和大型系統架構的把握。

　　　這一步涉及不少知識體系：通訊、分佈調用、分佈式事務、消息機制、並行計算、報表、檢測技術、規則策略等。

　　　　

 

 

二：這個是一個比較經典的框架總結（MVC,RPC,SOA,微服務）

　　在較長的一段時間裏，LAMP框架是Web網站的常見方式：Linux+ Apache+ PHP+ MySQL，或者另一套MVC規範，java裏比較常見的選擇一般是Spring +Struts +MyBatis +Tomcat，有時候也會選擇重量級的EJB來實現，儘管在技術細節上的處理各不相同，可是都有一個共性： 垂直應用架構。

　　　　

 

　　1、傳統的垂直應用架構

　　1.MVC架構

　　以經典的MVC垂直應用架構爲栗子，一般分爲三層：

• View展現層，是用戶看到並與之交互的界面。
• Control層，用於前端Web請求的分發，調度後臺的業務處理。
• Model模型層，包含業務數據和執行邏輯。

　　標準的MVC模式並不包括數據訪問層，因此一般還須要專門的ORM框架，能夠屏蔽對底層數據庫鏈接池和數據源的實現，提供對上層JDBC的訪問，提高開發效率，常見的通常都是Hibernate和Mybatis。一般基於MVC框架的應用都會打成一個war包，部署在Tomcat等Web容器中。

　　業務組網也不復雜，一般作好雙熱機便可，可經過watchDog來檢測應用，判斷應用進程是否異常，若是一個出現問題能夠當即啓動到備機，若是考慮到更復雜的併發場景，可在後端作集羣部署，還有前端F5等負載均衡處理。

　　　　

　　

　　2.垂直應用架構的缺陷

1.難以應付複雜的業務場景，且開發和維護的成本會增高。
2.團隊協做效率差，公共功能重複開發，重複率高。
3.系統的可靠性變差，某個節點的故障會致使整個系統的「雪崩效應」。
4.維護和定製困難，複雜應用的業務拆分困難，代碼修改牽一髮而動全身。

　　當垂直應用愈來愈多，應用之間的交互不可避免，將核心業務抽取出來，做爲獨立的服務，逐漸造成穩定的服務中心，使得前端可以更快的相應市場需求，同時將公共的API抽取出來，能夠做爲獨立的公共服務給其餘調用者消費，實現服務的共享和重用，因而有了RPC框架的需求。

　　 2、PRC框架

　　RPC的全稱爲（Remote Procedure Call），遠程過程調用，是一種進程間的通訊方式，在2006年後的移動互聯網時代開始興起，出現了各類各樣的開源RPC框架。

　　　　

　　

　　RPC的框架屏蔽了底層的傳輸方式（TCP/UDP），序列化方式（XML / JASON / ProtoBuf）和通訊細節，使用者只須要知道who（誰）在where（哪裏）提供了what（什麼）服務便可。

　　一個最簡單的RPC框架只須要考慮以下三個部分的實現：

• 服務提供者，運行在服務端，負責提供服務接口定義和實現。
• 服務發佈者，運行在RPC服務端，負責將本地服務發佈成遠程服務，供其餘消費者調用；
• 本地服務代理，運行在RPC客戶端，經過代理調用遠程服務提供者，而後將結果進行封裝返回給本地消費者；

　　2.RPC的不足

　　在大規模服務化之前，應用之前只能經過暴露接口和應用遠程服務的方式去調用，服務愈來愈多的時候會有如下狀況：

• 服務URL的配置管理變的困難
• 服務間的依賴關係變成錯綜複雜，難以分清哪一個應用要在哪一個應用前啓動
• 服務的調用量愈來愈大，服務的容量問題出現問題，某個服務須要多少機器、何時該加機器
• 缺少一個服務註冊中心，動態的註冊和發現服務。

　　服務化以後，隨之而來的就是服務治理問題，如今的RPC框架在這方面都有所欠缺，要解決這些問題必須經過服務框架+服務治理來完成，單憑RPC框架沒法解決服務治理的問題。

　　3、SOA服務化架構

　　SOA，Service-Oriented Architecture，面向服務的架構（SOA）是一個組件模型，是一種粗粒度、鬆耦合的以服務爲中心的架構，接口之間經過定義明確的協議和接口進行通訊。
面向服務的核心是對傳統的垂直架構進行改造，其中的核心技術就是分佈式服務框架，應用也從集中式走向了分佈式，大規模系統的架構設計原則就是儘量的拆分，以達到更好的獨立擴展與伸縮，更靈活的部署、更好的隔離和容錯，更高的開發效率，具體的拆分策略是：橫向拆分和縱向拆分。

　　業務縱向拆分：

　　　　根據業務的特性把應用拆開，不一樣的業務模塊獨立部署，將複雜的業務線拆分紅相對獨立的、靈活的具體能力域，由大到小分而治之。

　　　　　　

 

　　業務橫向拆分：

　　　　將核心的、公共的業務拆分出來，經過分佈式服務框架對業務進行服務化，消費者經過標準的契約來消費這些服務，服務提供者獨立打包、部署，與消費者解耦。

 　　　　

　　服務治理

　　拆分了以後，隨着服務數的增多，亟需一個服務治理框架，有效管理服務，提高服務的運行質量，服務治理須要知足：服務生命週期管理，服務容量規劃，運行期治理和服務安全等。目前較爲成熟的商用服務框架有Spring cloud，阿里巴巴提供的開源的Dubbo框架，非開源的HSF框架，

至於Dubbo和HSF這二者的差異，抄一段來展現：阿里巴巴第一代RPC框架Dubbo是國內第一款成熟的商用級RPC框架，已於2011年正式對外開源，目前已發展成爲國內開源價值最高、用戶使用規模最大的開源軟件之一。2016年度中國開源軟件Top10。最新一代RPC框架HSF，全稱High Speed Framework，也叫"好舒服"，"很舒服"框架，是阿里內部對這一款高性能服務框架的暱稱，是一款面向企業級互聯網架構量身定製的分佈式服務框架。HSF以高性能網絡通訊框架爲基礎，提供了諸如服務發佈與註冊，服務調用，服務路由，服務鑑權，服務限流，服務降級和服務調用鏈路跟蹤等一系列久經考驗的功能特性。

　　架構原理

　　分佈式服務的架構能夠抽象爲三層：

一、RPC層：底層通訊框架（例如NIO框架的封裝），序列化和反序列化框架等。
二、FilterChain層：服務調用職責鏈，例如負載均衡，服務調用性能統計，服務調用完成通知，失敗重發等等。
三、Service層：java動態代理，將服務提供者的接口封裝成遠程服務調用；java反射，服務提供者使用，根據消費者請求消息中的接口名、方法名、參數列表反射調用服務提供者的接口本地實現類。

　　分佈式服務框架的兩個核心功能：服務治理和服務註冊中心，服務中心中dubbo默認使用的是ZooKeeper，HSF默認使用的爲ConfigServer。

　　4、微服務

　　SOA解決了應用服務化的問題，隨着服務化實踐的深刻，服務的規模也愈來愈大，服務治理的問題也愈來愈多，這時候出現了微服務的思想。微服務架構由多個微小服務構成，每一個服務就是一個獨立的可部署單元或組件，它們是分佈式的，相互解耦的，經過輕量級遠程通訊協議（好比REST）來交互，每一個服務可使用不一樣的數據庫，並且是語言無關性的。它的特徵是彼此獨立、微小、輕量、鬆耦合，又能方便的組合和重構，猶如《超能陸戰隊》中的微型機器人，個體簡單，但組合起來威力強大。

微服務之因此這麼火，另外一個緣由是由於 Docker 的出現，它讓微服務有一個很是完美的運行環境，Docker 的獨立性和細粒度很是匹配微服務的理念，Docker的優秀性能和豐富的管理工具，讓你們對微服務有了必定的信息，歸納來講 Docker 有以下四點適合微服務：

• 獨立性：一個容器就是一個完整的執行環境，不依賴外部任何的東西。
• 細粒度：一臺物理機器能夠同時運行成百上千個容器。其計算粒度足夠的小。
• 快速建立和銷燬：容器能夠在秒級進行建立和銷燬，很是適合服務的快速構建和重組。
• 完善的管理工具：數量衆多的容器編排管理工具，可以快速的實現服務的組合和調度。

　　做者：YitaiCloud
　　連接：https://www.jianshu.com/p/62398fa9bc64
　　來源：簡書
　　簡書著做權歸做者全部，任何形式的轉載都請聯繫做者得到受權並註明出處。

 

三：阿里Dubbo上總結的一個圖

　　展現了的小型網站發展到一個大型網站的過程

　　　　

　　

　　單一應用架構

　　　　當網站流量很小時，只需一個應用，將全部功能都部署在一塊兒，以減小部署節點和成本。（減小io的操做，資源的重複利用）
　　　　此時，用於簡化增刪改查工做量的 數據訪問框架(ORM) 是關鍵。

　　垂直應用架構當訪問量逐漸增大，單一應用增長機器帶來的加速度愈來愈小，將應用拆成互不相干的幾個應用，以提高效率。此時，用於加速前端頁面開發的 Web框架(MVC) 是關鍵。
　　分佈式服務架構 
　　　　當垂直應用愈來愈多，應用之間交互不可避免，將核心業務抽取出來，做爲獨立的服務，逐漸造成穩定的服務中心，使前端應用能更快速的響應多變的市場需求。
　　　　此時，用於提升業務複用及整合的 分佈式服務框架(RPC) 是關鍵。
　　流動計算架構 
　　　　當服務愈來愈多，容量的評估，小服務資源的浪費等問題逐漸顯現，此時需增長一個調度中心基於訪問壓力實時管理集羣容量，提升集羣利用率。
　　　　此時，用於提升機器利用率的 資源調度和治理中心(SOA) 是關鍵。
　　---------------------
　　做者：行者man
　　來源：CSDN
　　原文：https://blog.csdn.net/it_manman/article/details/79394226?utm_source=copy
　　版權聲明：本文爲博主原創文章，轉載請附上博文連接！

 

四：總結

1.說明

　　上面有三篇文章，第一張是在技術層面的說法，適合幫助理解網站的發展歷程，沒有明確劃分的界限。

　　第二章與第三章是同樣：ORM,MVC,RPC,SOA（微服務屬於SOA）

 

2.所以

　　對於演變，仍是說明後一種更合適一點。