微服務的設計思考課件

微服務的設計思考寇宇2017/121ppt課件微服務的設計思考寇宇2017/121ppt課件01微服務的設計02微服務的架構(gòu)模式03微服務的的監(jiān)控PART

ONE2ppt課件010203PARTONE2ppt課件微服務的設計： 概念PART

ONE一種架構(gòu)風格、架構(gòu)模式服務能夠獨立構(gòu)建、獨立部署、獨立擴展松耦合、單一職責、基于限界上下文的一種SOA的落地實現(xiàn)基于Devops，面向運維的架構(gòu)需要團隊組織、文化的調(diào)整和完善的自動化工具實施中體現(xiàn)為：受業(yè)務驅(qū)動，不斷演進的架構(gòu)微服務3ppt課件微服務的設計： 概念PARTONE一種架構(gòu)風格、架構(gòu)模式服微服務的設計常見誤區(qū)：我使用了Springboot或Dubbo等，所以我使用了微服務微服務有助于提升應用性能微服務只是一種新的架構(gòu)模式，開發(fā)中改變下架構(gòu)與設計方法就可以做到微服務我使用了

Docker容器，所以我使用了微服務或者，我們沒上容器，所以沒法使用微服務通過在微服務框架上開發(fā)微服務，仍可以保證事務的實現(xiàn)PART

ONE4ppt課件微服務的設計常見誤區(qū)：PARTONE4ppt課件Monolithic單體應用分層架構(gòu)多種業(yè)務功能耦合MacroServicesSOA類應用粗粒度共享數(shù)據(jù)單體部署MiniServices細粒度（Domain）獨立數(shù)據(jù)獨立部署MicroServices細粒度（Feature）獨立數(shù)據(jù)獨立部署微服務構(gòu)建的演進提高訪問性提高敏捷性提高伸縮性微服務的設計PART

ONE5ppt課件Monolithic單體應用MacroServicesSOADo

right

things! 業(yè)務上真的有需要嗎？微服務不是“銀彈”，并不適合于每個應用和所有環(huán)境；原則：最好不拆！何時采用微服務業(yè)務響應速度已受到嚴重影響，現(xiàn)有常規(guī)辦法已無效果現(xiàn)有架構(gòu)下，再怎樣加硬件也無法改善應用指標…關(guān)鍵問題（一）

：該用微服務嗎PART

ONE準備工作業(yè)務驅(qū)動力業(yè)務需求整體組織架構(gòu)技術(shù)環(huán)境6ppt課件Dorightthings! 業(yè)務上真的有需要嗎？業(yè)務關(guān)鍵問題（二）：怎樣設計出微服務PART

ONE提取組件為服務的標準：通過區(qū)分”限界上下文”，形成微服務標準1：識別整體架構(gòu)內(nèi)的”限界上下文”,把不一致概念的分開。標準2：處理優(yōu)先級。在候選功能中，是否是優(yōu)先的功能提??？第二步：“扼殺舊應用”不斷地提取微服務，直到應用中全部的”限界上下文”都提取為微服務或其中所剩內(nèi)容已無必要再提取。單體應用的分解方法： 拆第一步：構(gòu)建所有的新加特性作為微服務不摧毀應用，也不加入新功能，而是使用微服務方式實現(xiàn)新特性集成新的微服務：anti-corruption

layer，隔離舊應用，提高擴展性策略7ppt課件關(guān)鍵問題（二）：怎樣設計出微服務PARTONE提取組件為服微服務的拆解粒度：how

small

is“small”?最佳實踐：先粗后細：開始拆解時，很難一次性給出合適的粒度，可以先劃分的粗些。不斷調(diào)整：當對服務有了更多認識后，會不斷調(diào)整粒度，進行服務的進一步拆分、合并。“類”與“服務”：類的數(shù)量不是粒度衡量的標準服務實際上是指服務組件，被認為是承擔特定職責的架構(gòu)組件；服務組件怎么實現(xiàn)和用多少類實現(xiàn)，要根據(jù)設計情況定；確定服務粒度的基準測試服務的范圍與功能：分析服務提供的操作的內(nèi)聚層次，拆分指示詞，“并且”、“此外”數(shù)據(jù)庫事務：分布式的影響，ACID

vs.BASE

transactions

，是否服務粒度過細分析服務編織的層次：編織會降低整體性能；影響可用性與健壯性。太多的編織意味著服務粒度過細。請求響應能力與可靠性間的權(quán)衡考慮組織文化、團隊規(guī)模：Two-pizza

Team,Cross關(guān)鍵問題（三）：服務拆到什么程度PART

ONE8ppt課件微服務的拆解粒度：howsmallis“small”?關(guān)關(guān)鍵問題（四）

：反模式PART

ONE“數(shù)據(jù)驅(qū)動遷移”反模式：FunctionalityFirst,Data

Last“共享”反模式：打破了服務間的限界上下文“超時”反模式“Rest”陷阱“靜態(tài)契約”陷阱…9ppt課件關(guān)鍵問題（四）：反模式PARTONE“數(shù)據(jù)驅(qū)動遷移”反模因應業(yè)務發(fā)展而不斷演變！商品庫存價格訂單會員會員購物車促銷電商應用..

.由一個商業(yè)套件實現(xiàn)全部應用功能商品庫存價格訂單購物車會員促銷會員電商應用..

.采用SOA模式，整合各定制的單一分層應用訂單應用開始按照限界上下文進行服務拆分，但粒度較粗..

.微服務的設計： 服務拆分舉例PART

ONE拆歷經(jīng)2-3年歷經(jīng)3-4年10ppt課件因應業(yè)務發(fā)展而不斷演變！商品庫存價格訂單會員會員購物車促銷電業(yè)務驅(qū)動力：單體應用性能差，越來越難以通過硬件擴展來提升服務水平難以快速開發(fā)、全量回歸測試困難、難以快速部署上線，影響公司業(yè)務發(fā)展；希望大幅提升訂單的開發(fā)效率，易于快速開發(fā)、快速測試，降低復雜度；業(yè)務需求：接單：近200種場景的接單；審核與資源處理：處理會員權(quán)益、促銷資格、價格、優(yōu)惠、庫存等；交易處理：支付相關(guān)操作；查詢：按多維度；分發(fā)：同步必要的訂單信息；技術(shù)環(huán)境：基于虛機的私有云環(huán)境；處理單元化（可在分區(qū)內(nèi)完成全部處理），利于跨機房部署；微服務的設計： 服務拆分舉例PART

ONE11ppt課件業(yè)務驅(qū)動力：微服務的設計： 服務拆分舉例PARTONE11訂單的場景：線下門店1.來源渠道2.下單終端3.業(yè)態(tài)分類7.配送方式8.支付方式線上批發(fā)對公/工程零售5.商品分類實體商品虛擬商品服務商品4.業(yè)態(tài)來源電器超市6.經(jīng)營模式自營第三方自營配送商家配送廠家配送門店自提在線支付貨到付款9.支付次數(shù)一次支付二次支付融合支付PC門店APP/WAP電銷..

...

.10.顧客個人企業(yè)11.自營銷售方式先銷后采先采后銷12.線上購物正常搶購閃拍名品特賣海外購13.銷售方式14.商品特性15.發(fā)票正常套餐贈品正常冷鏈送裝一體不打發(fā)票電子發(fā)票普通發(fā)票16.結(jié)算正常分賬微服務的設計： 服務拆分舉例PART

ONE12ppt課件訂單的場景：線下門店1.來源渠道2.下單終端3.業(yè)態(tài)分類7.微服務的設計： 服務拆分舉例PART

ONEfi$

?1..*fi$

fi

fi

fi

fi

fi@fi

fi

fi

fifi

@fifi

fl‰fi

fifi

s?‰‰?{fi

履約訂單交易訂單查詢訂單13ppt課件微服務的設計： 服務拆分舉例PARTONEfi$?1..微服務的設計： 服務拆分舉例PART

ONE交易服務下單；拆單；校驗；支付；– …履約服務庫存調(diào)度物流調(diào)度售后服務調(diào)度– ...查詢服務按用戶查詢；按營業(yè)員查詢；按手機號查詢；– …未來：使用Stratety模式，細分服務！14ppt課件微服務的設計： 服務拆分舉例PARTONE交易服務下單；履Agenda01微服務的設計02微服務的架構(gòu)模式03微服務的的監(jiān)控15ppt課件Agenda01020315ppt課件微服務的架構(gòu)模式PART

TWOFabric

ModelProxy作為API網(wǎng)關(guān)與控制器；簡單易行；適用于從復雜度適中的單體應用轉(zhuǎn)向微服務架構(gòu)的起步階段；MicroservicesReference

Architecture（By

NGINX）RouterMesh

ModelProxy

Model獨立的反代可應對更大的訪問壓力，健壯性好；router

mesh

hub處理服務間通信；提供了更多的控制手段；適用于從更大更復雜的單體應用轉(zhuǎn)為微服務；最高級、最服務的模式；每個service配備一個Proxy；服務間通信通過serviceProxy，對服務進行有針對性的治理；高性能、高彈性；適用于高壓力的場景；16ppt課件微服務的架構(gòu)模式PARTTWOFabricModelPrServiceProxyWebFrontApp3P

AppBrokerOpenAPIAPIGatewayServiceBrokerServiceEndPointEndPoint..

.ServiceProxyEndPointEndPoint..

.ServiceProxyEndPointEndPoint..

.微服務框架的一種實現(xiàn)微服務的架構(gòu)模式PART

TWO17ppt課件ServiceWebFrontApp3PAppBroker微服務框架的一種實現(xiàn)gRPC/thrift/…業(yè)務邏輯通過IDL生成ClientCircuit

breaker Client

logic.

.

. ClientStubServerServer FilterBusiness chainlogicContext lifecycleServiceAdaptor Configuration TransportServerStubRegister ..

.一個協(xié)議無關(guān)的服務框架基于契約優(yōu)先方式開發(fā)服務接口對遠程調(diào)用協(xié)議進行了封裝，優(yōu)化了碼生成的結(jié)構(gòu)與調(diào)用方式，即采用形如“同步”的編碼方式實來進行遠程調(diào)用提供LifeCycle，添加了服務注冊，基于zipkin的調(diào)用鏈等功能添加了Spring

Starter，簡化了服務啟動和客戶端調(diào)用微服務的架構(gòu)模式PART

TWO18ppt課件微服務框架的一種實現(xiàn)gRPC/thrift/…業(yè)務邏輯通過I基于Proxy的服務端治理Proxy是Client訪問的端點Proxy負責服務實例的信息收集和注冊基于Proxy的路由功能結(jié)合語義化版本(X.Y.Z)的概念進行不同服務的版本管理利用Docker簡化部署利用Proxy綁定VIP來簡化客戶端尋址V2V4V1V4V3V2V1V2V3V1V4V1V4V3V2V1V2V3PROXYV1PROXYV2API

GatewayWebAPPServiceServiceInventory服務名稱版本號狀態(tài)IP地址：端口Owner描述+

IDL…注冊VIP微服務的架構(gòu)模式PART

TWO19ppt課件基于Proxy的服務端治理Proxy是Client訪問的端點Agenda01微服務的設計02微服務的架構(gòu)模式03微服務的的監(jiān)控20ppt課件Agenda01020320ppt課件微服務的監(jiān)控PART

THREE）21ppt課件微服務的監(jiān)控PARTTHREE）21ppt課件PART

THREE微服務的監(jiān)控：端到端的全鏈路監(jiān)控網(wǎng)絡、硬件系統(tǒng)資源中間件應用容器..

.客戶是否受影響網(wǎng)絡傳輸是否正常認證服務慢?三方服務QoS低？SQL執(zhí)行效率？SLA不達標基礎(chǔ)設施異常瀏覽器加載慢？ServiceAServiceBServiceCServiceD代碼有問題？日志異常？22ppt課件PARTTHREE微服務的監(jiān)控：端到端的全鏈路監(jiān)控網(wǎng)絡、硬微服務的監(jiān)控PART

THREE分布式追蹤

–

Google

Dapper23ppt課件微服務的監(jiān)控PARTTHREE分布式追蹤–GoogleAPM探針的基本原理

(Java

Instrument)微服務的監(jiān)控PART

THREE24ppt課件APM探針的基本原理(JavaInstrument)微服微服務的監(jiān)控PART

THREE分布式追蹤

–

OpenTracing25ppt課件微服務的監(jiān)控PARTTHREE分布式追蹤–OpenTr微服務的監(jiān)控：動態(tài)拓撲PART

THREE26ppt課件微服務的監(jiān)控：動態(tài)拓撲PARTTHREE26ppt課件微服務的監(jiān)控：事務分析PART

THREE27ppt課件微服務的監(jiān)控：事務分析PARTTHREE27ppt課件THANKS28ppt課件THANKS28ppt課件END29ppt課件END29ppt課件微服務的設計思考寇宇2017/1230ppt課件微服務的設計思考寇宇2017/121ppt課件01微服務的設計02微服務的架構(gòu)模式03微服務的的監(jiān)控PART

ONE31ppt課件010203PARTONE2ppt課件微服務的設計： 概念PART

ONE一種架構(gòu)風格、架構(gòu)模式服務能夠獨立構(gòu)建、獨立部署、獨立擴展松耦合、單一職責、基于限界上下文的一種SOA的落地實現(xiàn)基于Devops，面向運維的架構(gòu)需要團隊組織、文化的調(diào)整和完善的自動化工具實施中體現(xiàn)為：受業(yè)務驅(qū)動，不斷演進的架構(gòu)微服務32ppt課件微服務的設計： 概念PARTONE一種架構(gòu)風格、架構(gòu)模式服微服務的設計常見誤區(qū)：我使用了Springboot或Dubbo等，所以我使用了微服務微服務有助于提升應用性能微服務只是一種新的架構(gòu)模式，開發(fā)中改變下架構(gòu)與設計方法就可以做到微服務我使用了

Docker容器，所以我使用了微服務或者，我們沒上容器，所以沒法使用微服務通過在微服務框架上開發(fā)微服務，仍可以保證事務的實現(xiàn)PART

ONE33ppt課件微服務的設計常見誤區(qū)：PARTONE4ppt課件Monolithic單體應用分層架構(gòu)多種業(yè)務功能耦合MacroServicesSOA類應用粗粒度共享數(shù)據(jù)單體部署MiniServices細粒度（Domain）獨立數(shù)據(jù)獨立部署MicroServices細粒度（Feature）獨立數(shù)據(jù)獨立部署微服務構(gòu)建的演進提高訪問性提高敏捷性提高伸縮性微服務的設計PART

ONE34ppt課件Monolithic單體應用MacroServicesSOADo

right

things! 業(yè)務上真的有需要嗎？微服務不是“銀彈”，并不適合于每個應用和所有環(huán)境；原則：最好不拆！何時采用微服務業(yè)務響應速度已受到嚴重影響，現(xiàn)有常規(guī)辦法已無效果現(xiàn)有架構(gòu)下，再怎樣加硬件也無法改善應用指標…關(guān)鍵問題（一）

：該用微服務嗎PART

ONE準備工作業(yè)務驅(qū)動力業(yè)務需求整體組織架構(gòu)技術(shù)環(huán)境35ppt課件Dorightthings! 業(yè)務上真的有需要嗎？業(yè)務關(guān)鍵問題（二）：怎樣設計出微服務PART

ONE提取組件為服務的標準：通過區(qū)分”限界上下文”，形成微服務標準1：識別整體架構(gòu)內(nèi)的”限界上下文”,把不一致概念的分開。標準2：處理優(yōu)先級。在候選功能中，是否是優(yōu)先的功能提取？第二步：“扼殺舊應用”不斷地提取微服務，直到應用中全部的”限界上下文”都提取為微服務或其中所剩內(nèi)容已無必要再提取。單體應用的分解方法： 拆第一步：構(gòu)建所有的新加特性作為微服務不摧毀應用，也不加入新功能，而是使用微服務方式實現(xiàn)新特性集成新的微服務：anti-corruption

layer，隔離舊應用，提高擴展性策略36ppt課件關(guān)鍵問題（二）：怎樣設計出微服務PARTONE提取組件為服微服務的拆解粒度：how

small

is“small”?最佳實踐：先粗后細：開始拆解時，很難一次性給出合適的粒度，可以先劃分的粗些。不斷調(diào)整：當對服務有了更多認識后，會不斷調(diào)整粒度，進行服務的進一步拆分、合并?！邦悺迸c“服務”：類的數(shù)量不是粒度衡量的標準服務實際上是指服務組件，被認為是承擔特定職責的架構(gòu)組件；服務組件怎么實現(xiàn)和用多少類實現(xiàn)，要根據(jù)設計情況定；確定服務粒度的基準測試服務的范圍與功能：分析服務提供的操作的內(nèi)聚層次，拆分指示詞，“并且”、“此外”數(shù)據(jù)庫事務：分布式的影響，ACID

vs.BASE

transactions

，是否服務粒度過細分析服務編織的層次：編織會降低整體性能；影響可用性與健壯性。太多的編織意味著服務粒度過細。請求響應能力與可靠性間的權(quán)衡考慮組織文化、團隊規(guī)模：Two-pizza

Team,Cross關(guān)鍵問題（三）：服務拆到什么程度PART

ONE37ppt課件微服務的拆解粒度：howsmallis“small”?關(guān)關(guān)鍵問題（四）

：反模式PART

ONE“數(shù)據(jù)驅(qū)動遷移”反模式：FunctionalityFirst,Data

Last“共享”反模式：打破了服務間的限界上下文“超時”反模式“Rest”陷阱“靜態(tài)契約”陷阱…38ppt課件關(guān)鍵問題（四）：反模式PARTONE“數(shù)據(jù)驅(qū)動遷移”反模因應業(yè)務發(fā)展而不斷演變！商品庫存價格訂單會員會員購物車促銷電商應用..

.由一個商業(yè)套件實現(xiàn)全部應用功能商品庫存價格訂單購物車會員促銷會員電商應用..

.采用SOA模式，整合各定制的單一分層應用訂單應用開始按照限界上下文進行服務拆分，但粒度較粗..

.微服務的設計： 服務拆分舉例PART

ONE拆歷經(jīng)2-3年歷經(jīng)3-4年39ppt課件因應業(yè)務發(fā)展而不斷演變！商品庫存價格訂單會員會員購物車促銷電業(yè)務驅(qū)動力：單體應用性能差，越來越難以通過硬件擴展來提升服務水平難以快速開發(fā)、全量回歸測試困難、難以快速部署上線，影響公司業(yè)務發(fā)展；希望大幅提升訂單的開發(fā)效率，易于快速開發(fā)、快速測試，降低復雜度；業(yè)務需求：接單：近200種場景的接單；審核與資源處理：處理會員權(quán)益、促銷資格、價格、優(yōu)惠、庫存等；交易處理：支付相關(guān)操作；查詢：按多維度；分發(fā)：同步必要的訂單信息；技術(shù)環(huán)境：基于虛機的私有云環(huán)境；處理單元化（可在分區(qū)內(nèi)完成全部處理），利于跨機房部署；微服務的設計： 服務拆分舉例PART

ONE40ppt課件業(yè)務驅(qū)動力：微服務的設計： 服務拆分舉例PARTONE11訂單的場景：線下門店1.來源渠道2.下單終端3.業(yè)態(tài)分類7.配送方式8.支付方式線上批發(fā)對公/工程零售5.商品分類實體商品虛擬商品服務商品4.業(yè)態(tài)來源電器超市6.經(jīng)營模式自營第三方自營配送商家配送廠家配送門店自提在線支付貨到付款9.支付次數(shù)一次支付二次支付融合支付PC門店APP/WAP電銷..

...

.10.顧客個人企業(yè)11.自營銷售方式先銷后采先采后銷12.線上購物正常搶購閃拍名品特賣海外購13.銷售方式14.商品特性15.發(fā)票正常套餐贈品正常冷鏈送裝一體不打發(fā)票電子發(fā)票普通發(fā)票16.結(jié)算正常分賬微服務的設計： 服務拆分舉例PART

ONE41ppt課件訂單的場景：線下門店1.來源渠道2.下單終端3.業(yè)態(tài)分類7.微服務的設計： 服務拆分舉例PART

ONEfi$

?1..*fi$

fi

fi

fi

fi

fi@fi

fi

fi

fifi

@fifi

fl‰fi

fifi

s?‰‰?{fi

履約訂單交易訂單查詢訂單42ppt課件微服務的設計： 服務拆分舉例PARTONEfi$?1..微服務的設計： 服務拆分舉例PART

ONE交易服務下單；拆單；校驗；支付；– …履約服務庫存調(diào)度物流調(diào)度售后服務調(diào)度– ...查詢服務按用戶查詢；按營業(yè)員查詢；按手機號查詢；– …未來：使用Stratety模式，細分服務！43ppt課件微服務的設計： 服務拆分舉例PARTONE交易服務下單；履Agenda01微服務的設計02微服務的架構(gòu)模式03微服務的的監(jiān)控44ppt課件Agenda01020315ppt課件微服務的架構(gòu)模式PART

TWOFabric

ModelProxy作為API網(wǎng)關(guān)與控制器；簡單易行；適用于從復雜度適中的單體應用轉(zhuǎn)向微服務架構(gòu)的起步階段；MicroservicesReference

Architecture（By

NGINX）RouterMesh

ModelProxy

Model獨立的反代可應對更大的訪問壓力，健壯性好；router

mesh

hub處理服務間通信；提供了更多的控制手段；適用于從更大更復雜的單體應用轉(zhuǎn)為微服務；最高級、最服務的模式；每個service配備一個Proxy；服務間通信通過serviceProxy，對服務進行有針對性的治理；高性能、高彈性；適用于高壓力的場景；45ppt課件微服務的架構(gòu)模式PARTTWOFabricModelPrServiceProxyWebFrontApp3P

AppBrokerOpenAPIAPIGatewayServiceBrokerServiceEndPointEndPoint..

.ServiceProxyEndPointEndPoint..

.ServiceProxyEndPointEndPoint..

.微服務框架的一種實現(xiàn)微服務的架構(gòu)模式PART

TWO46ppt課件ServiceWebFrontApp3PAppBroker微服務框架的一種實現(xiàn)gRPC/thrift/…業(yè)務邏輯通過IDL生成ClientCircuit

breaker Client

logic.

.

. ClientStubServerServer FilterBusiness chainlogicContext lifecycleServiceAdaptor Configuration TransportServerStubRegister ..

.一個協(xié)議無關(guān)的服務框架基于契約優(yōu)先方式開發(fā)服務接口對遠程調(diào)用協(xié)議進行了封裝，優(yōu)化了碼生成的結(jié)構(gòu)與調(diào)用方式，即采用形如“同步”的編碼方式實來進行遠程調(diào)用提供LifeCycle，添加了服務注冊，基于zipkin的調(diào)用鏈等功能添加了Spring

Starter，簡化了服務啟動和客戶端調(diào)用微服務的架構(gòu)模式PART

TWO47ppt課件微服務框架的一種實現(xiàn)gRPC/thrift/…業(yè)務邏輯通過I基于Proxy的服務端治理Proxy是Client訪問的端點Proxy負責服