分布式服務體系框架

分布式服務體系框架第一頁，編輯于星期六：十三點十八分。應用架構(gòu)的發(fā)展需求隨著互聯(lián)網(wǎng)業(yè)務的發(fā)展，網(wǎng)站應用的規(guī)模不斷擴大，常規(guī)的企業(yè)級垂直應用架構(gòu)已無法應對，服務式的應用架構(gòu)以及分布式服務框架勢在必行，用戶亟需一個治理系統(tǒng)確保架構(gòu)有條不紊的演進。單一應用垂直應用拆分服務，RPC調(diào)用分布式服務框架第二頁，編輯于星期六：十三點十八分。網(wǎng)站應用架構(gòu)的演進FrameworkArchitectureClusterAllinOne1~10垂直應用分布式服務彈性服務框架ORMMVCRPCSOA應用服務10~10001000~1000010000+單一應用架構(gòu)當網(wǎng)站流量很小時，只需一個應用，將所有功能都部署在一起，以減少部署節(jié)點和成本。此時，用于簡化增刪改查工作量的

數(shù)據(jù)訪問框架(ORM)

是關鍵。垂直應用架構(gòu)當訪問量逐漸增大，單一應用增加機器帶來的加速度越來越小，將應用拆成互不相干的幾個應用，以提升效率。此時，用于加速前端頁面開發(fā)的

Web框架(MVC)

是關鍵。分布式服務架構(gòu)當垂直應用越來越多，應用之間交互不可避免，將核心業(yè)務抽取出來作為獨立的可以復用的服務，使前端應用能更快速的響應多變的市場需求。此時，RPC技術是關鍵。流動計算架構(gòu)當服務越來越多，容量的評估，小服務資源的浪費等問題逐漸顯現(xiàn)，此時需增加一個調(diào)度中心基于訪問壓力實時管理集群容量，提高集群利用率。此時，用于提高設施利用率的資源調(diào)度和治理中心(SOA)

是關鍵。3第三頁，編輯于星期六：十三點十八分。單一的應用架構(gòu)應用All數(shù)據(jù)庫AllinOne1~10ORM單一應用架構(gòu)當網(wǎng)站流量很小時，只需一個應用，將所有功能都部署在一起，以減少部署節(jié)點和成本。此時，用于簡化增刪改查工作量的

數(shù)據(jù)訪問框架(ORM)

是關鍵。應用All應用All應用All負載均衡器每個節(jié)點服務器中，包換應用的全部功能模塊代碼應用系統(tǒng)很臃腫，維護和版本升級開銷非常非常大使用負載均衡分散訪問會話，提高并發(fā)處理能力網(wǎng)站初期或者規(guī)模較小，整體上容易把控4第四頁，編輯于星期六：十三點十八分。垂直拆分應用架構(gòu)垂直應用MVC10~1000垂直應用架構(gòu)當訪問量逐漸增大，單一應用增加機器帶來的加速度越來越小，將應用拆成互不相干的幾個應用，以提升效率。此時，用于加速前端頁面開發(fā)的

Web框架(MVC)

是關鍵。應用A應用B應用C應用D數(shù)據(jù)庫緩存系統(tǒng)搜索引擎應用E應用F應用All各應用中存在重復的業(yè)務功能和代碼，甚至在一個應用中也會存在冗余的代碼邏輯應用系統(tǒng)依然很臃腫，業(yè)務邏輯處理和界面交互的代碼還是堆放在一起維護和版本升級開銷都很大，穩(wěn)定性不夠理想適用于中小型網(wǎng)站規(guī)模，整體上容易把控第五頁，編輯于星期六：十三點十八分。服務式應用架構(gòu)服務式RPC1000~10000服務式應用架構(gòu)當垂直應用越來越多，應用之間交互不可避免，將核心業(yè)務抽取出來作為獨立的可以復用的服務，使前端應用能更快速的響應多變的市場需求。此時，RPC技術是關鍵。服務1應用A應用B應用C應用D數(shù)據(jù)庫應用E應用F服務2服務3服務4分布式文件系統(tǒng)搜索引擎緩存系統(tǒng)應用G應用服務增加服務層，把冗余的代碼和可以復用的業(yè)務應用進行拆分提取，封裝成服務系統(tǒng)架構(gòu)更加清晰，代碼質(zhì)量提高，利于升級和維護，穩(wěn)定性高應用層可以更專注在與前端用戶如何交互，業(yè)務處理放在服務層來進行服務和應用的管理不是自動化，服務層能夠?qū)崿F(xiàn)HA的功能適用中大型網(wǎng)站系統(tǒng)的場景中第六頁，編輯于星期六：十三點十八分。分布式服務框架應用服務分布式服務框架SOA10000+流動計算架構(gòu)當服務越來越多，容量的評估，小服務資源的浪費等問題逐漸顯現(xiàn)，此時需增加一個調(diào)度中心基于訪問壓力實時管理集群容量，提高集群利用率。此時，用于提高設施利用率的資源調(diào)度和治理中心(SOA)

是關鍵。服務框架應用1（服務調(diào)用者）服務框架服務框架服務框架服務中心服務框架服務框架應用2（服務調(diào)用者）新應用1（服務調(diào)用者）服務A（服務提供者）服務B（服務提供者）新服務A（服務提供者）注冊訂閱推送服務列表調(diào)用調(diào)用調(diào)用分布式架構(gòu)，應用層和服務層可根據(jù)需求進行動態(tài)水平擴展，應用與服務實現(xiàn)負載均衡，通過隨機、輪詢、權(quán)重等策略開放式、標準化的框架，滿足接口調(diào)用的服務都可以接入服務框架（RPC）監(jiān)控服務調(diào)用情況，可進一步對服務層再分層，根據(jù)業(yè)務需求和對服務運行情況對服務進行編排和梳理，以及服務治理適用大型及超大型網(wǎng)站應用架構(gòu)推送服務列表服務調(diào)用者和提供者直接建立連接服務列表保存在應用的本地（注冊查找）基于服務式應用架構(gòu)基礎上，引入服務注冊中心，用于保存服務列表；實現(xiàn)自動化服務體系框架第七頁，編輯于星期六：十三點十八分。服務分層8前端集成核心服務分層注冊中心治理中心調(diào)度中心監(jiān)控中心服務編排服務容器服務質(zhì)量協(xié)定服務容量評估服務調(diào)用統(tǒng)計依賴關系服務文檔負責人審批流程服務測試服務注冊與發(fā)現(xiàn)服務降級對服務進行監(jiān)控、統(tǒng)計、評估、測試服務粗粒度，可針對業(yè)務需求對服務進行編排對服務進行治理，服務的依賴關系、調(diào)整服務權(quán)重等維護服務登記文檔服務權(quán)限，服務分組第八頁，編輯于星期六：十三點十八分。消息中間件既然應用拆分了，形成了服務層，應用由緊耦合變?yōu)樗神詈?，那么應用之間、服務之間、應用與服務之間如何通訊？應用解耦，最終數(shù)據(jù)一致性異步通訊、操作的異步有些場景中，利用消息系統(tǒng)確保分布式數(shù)據(jù)庫的弱事務性服務1應用A應用B服務2消息中間件MQ應用C服務3主庫從庫服務注冊查找中心9第九頁，編輯于星期六：十三點十八分。分布式服務框架服務體系框架系統(tǒng)特色：作為高性能分布式RPC服務調(diào)用中間件，SAF服務注冊訂閱中心負責服務的注冊與訂閱，部署在業(yè)務應用中的客戶端負責RPC調(diào)用；遠程方法調(diào)用透明，簡單配置，無API入侵。SAF具有FailOver特性，提供調(diào)用跟蹤、服務路由、軟負載均衡，實現(xiàn)高可用的服務，方便實現(xiàn)服務能力水平伸縮。SAF還可提供更多服務治理功能，由專家小組提供支持。服務注冊中心Registry服務提供者查看服務消費者查看注冊中心管理端路由管理屬性配置服務上下線Eon-SAF服務體系框架調(diào)用過程統(tǒng)一RPC調(diào)用框架，技術對齊，系統(tǒng)SOA化，滿足業(yè)務的快速變化需求；開發(fā)人員提升開發(fā)效率、保證服務質(zhì)量；服務提供者Provider服務提供者Provider服務注冊服務注冊服務調(diào)用服務調(diào)用訂閱服務得到服務列表推送服務列表服務消費者Consumer監(jiān)控Monitor同步（長連接）異步（短連接）采集服務調(diào)用次數(shù)和調(diào)用時間10第十頁，編輯于星期六：十三點十八分?？蚣艿膶哟位鱾€應用系統(tǒng)中有相同的業(yè)務功能，提取出來這部分冗余的功能在服務中心以服務的方式供大家一起使用。讓應用層更加專注的去解決與瀏覽器交互的工作，而不必過多的關注業(yè)務邏輯的事情。業(yè)務數(shù)據(jù)的操作由服務層封裝。業(yè)務功能之間訪問不僅是單機內(nèi)部訪問，還有遠程服務調(diào)用。把數(shù)據(jù)交互的工作封裝成數(shù)據(jù)訪問層，服務層不直接與數(shù)據(jù)庫交互，由數(shù)據(jù)訪問層來提供數(shù)據(jù)的訪問策略。幫助服務層完成數(shù)據(jù)的拆分以及整