微服務設計入門(ppt40頁)(文件)
【正文】 ? 很多事情努力了未必有結果，但是不努力卻什么改變也沒有。 2023年 2月 13日星期一 2023/2/132023/2/132023/2/13 ? 1比不了得就不比，得不到的就不要。 2023/2/132023/2/132023/2/132/13/2023 8:02:56 AM ? 1以我獨沈久，愧君相見頻。 ? 解決方法： ? 需要密切關注服務的職責和 API ? 設計和協(xié)議必須是能夠自動化驗證并不斷強化的 ? 人類有喜歡走捷徑的天性，但是不要總是 “ 走捷徑 ” 微服務的反模式 ——暴怒（ Wrath）：發(fā)生了糟糕的事情就會引發(fā)連鎖爆炸 ? 現(xiàn)象： ? 因為某個消息隊列的擁塞，引發(fā)連鎖反應，最終導致整個系統(tǒng)無法對外提供服務 ? 解決方法 ? 開發(fā)人員需要進行防御式編程，實現(xiàn)一些容錯模式，例如超時時間、重試機制、斷路器、艙壁等等。 微服務架構的幾大特征 ?由一組小的服務組成一個完整的應用（或網(wǎng)站） ?每個服務圍繞一個相對獨立的業(yè)務領域（領域模型）構建 ?服務之間通過輕量級的通信機制互相溝通 ?完全去中心化 ?每個服務都可以獨立部署 ?每個服務可以使用不同的編程語言實現(xiàn) 微服務架構和傳統(tǒng)面向服務架構（ SOA）的區(qū)別 ? SOA沒有為服務如何劃分提出具體指導 ? SOA無法防止服務之間過度耦合 ? SOA通常使用重量級的通信協(xié)議，例如 SOAP/WSDL ? SOA中常常有集中式的服務管理機制，例如 UDDI、 ESB ? SOA未強調(diào)服務的獨立部署 ? SOA難以使用不同的編程語言實現(xiàn) ? SOA的性能和可伸縮性無法滿足面向互聯(lián)網(wǎng)大流量應用的需要 微服務架構能帶來的好處 ——解決傳統(tǒng)單塊風格（ monolithic style）應用的問題 ?單一代碼庫，代碼維護復雜 ? 修改或新增代碼，影響范圍難以清晰估計 ? 迭代周期很長，難以制定周期固定的迭代開發(fā)計劃 ? 對程序員的技能要求很高 ?單一發(fā)布單元，測試困難 ? 設計開發(fā)測試用例需要考慮的問題太多，包括驗收測試、回歸測試、性能測試 微服務架構能帶來的好處 ——解決傳統(tǒng)單塊風格（ monolithic style ）應用的問題 ?單一發(fā)布單元，發(fā)布困難 ? 可能需要停掉整個應用（或網(wǎng)站） ? 每次發(fā)布耗時很長：發(fā)布上百臺服務器、預發(fā)布環(huán)境大量的回歸測試 …… ?對服務器硬件配置要求極高，垂直擴展困難 ? CPU、內(nèi)存、硬盤、網(wǎng)絡帶寬 …… ?無法做到無狀態(tài)，水平擴展困難 ? 無法實現(xiàn)線性水平擴展 ? 難以做容量規(guī)劃 微服務架構能帶來的好處 ——解決集中式服務管理機制的問題 ?常見集中式服務管理機制 ? 企業(yè)服務總線（ ESB） ? Dubbo的服務注冊中心 ? 配置中心 ?集中式服務管理機制的問題 ? 可伸縮性差，容易成為性能瓶頸 ? 有可能出現(xiàn)單點故障 ? 設計開發(fā)難度極高，因為要保證非常高的可用性（ HA） 微服務架構能帶來的好處 ——解決重量級通信機制的問題 ?常見的重量級通信機制 ? 基于 HTTP的各種 RPC（遠程過程調(diào)用）風格協(xié)議： SOAP/WSDL、 XMLRPC、 JSONRPC、 Burlap、 Hessian ? 二進制 DO（分布式對象）風格協(xié)議： Java RMI/EJB、 .NET Remoting ?重量級通信機制的問題 ? 緊耦合 ：服務器端 API做改動后，客戶端必須同時做改動、同時部署 ? 互操作性差 ：客戶端與服務器端常常需要使用相同的編程語言 ? 可伸縮性差 ：尤其是 SOAP、 XMLRPC 設計微服務架構需要掌握的基礎知識 ? 領域驅(qū)動設計（ DDD） ? RESTful API的設計 ? 以及深入理解 HTTP協(xié)議 ? 一種 RESTful API開發(fā)框架 ? Java： Spring MVC、 Play、 Jersey、 RESTEasy、 CXF ? .NET： Web API ? ： Express、 Seneca PM2 ? Python： Django REST Framework、 Flask ? Ruby： Rails、 Sinatra、 Grape 設計微服務架構需要掌握的可選知識 ? 某種為部署微服務而設計
法律信息相關推薦
鄂ICP備17016276號-1