微服務(wù)設(shè)計入門(ppt40頁)-文庫吧
2025-01-15 18:11 本頁面
【正文】 ? Consul ? Eureka：基于 AWS的服務(wù)負載均衡 ? Nginx ? HAProxy ? 日志、監(jiān)控 ? ELK： Elasticsearch/Logstash/Kibana ? Zabbix ? 基于 Docker的部署和服務(wù)編排 設(shè)計微服務(wù)架構(gòu)需要解決的主要問題 ? 劃分服務(wù)的原則是什么？ ? 服務(wù)之間選擇何種輕量級的通信協(xié)議？ ? 如何做到服務(wù)的獨立部署？ ? 如何確定該使用何種服務(wù)編程語言？如何控制多語言帶來的復(fù)雜度？ ? 如何做到服務(wù)的去中心化？ ? 如何解決大量微服務(wù)引入的運維成本？ 劃分服務(wù)的原則是什么？ ?參考 DDD中的設(shè)計策略 “ 界定的上下文 ” （ Bounded Context），劃分出系統(tǒng)中不同的領(lǐng)域模型（上下文） ? 每一個領(lǐng)域模型擁有自己獨立的數(shù)據(jù)庫（或其他持久存儲） ? DDD中其他對于劃分服務(wù)有參考價值的設(shè)計策略 ?上下文映射（ Context Map） ?共享內(nèi)核（ Shared Kernel） ?客戶 供應(yīng)商（ CustomerSupplier） ?順從者（ Conformist） ?防崩潰層（ Anticorruption Layer） ?隔離通道（ Separate Way） ?開放主機服務(wù)（ Open Host Service） 劃分服務(wù)的原則是什么？ ? 判斷良好服務(wù)的標準 ? 自身保持高內(nèi)聚，有自己獨立的領(lǐng)域模型（上下文） ? 封裝內(nèi)部變化，通過 API對外暴露功能 ? 只有本服務(wù)自身的代碼可訪問本領(lǐng)域模型的數(shù)據(jù)庫 ? 其他系統(tǒng)只能通過本服務(wù)暴露的 API間接訪問本服務(wù)的數(shù)據(jù) ? 與其他服務(wù)保持松耦合，能夠獨立修改和部署 ? 依賴本服務(wù)的其他系統(tǒng)不必同時修改和部署 ? 能夠?qū)崿F(xiàn)服務(wù)自治，可獨立進化 ? 同一個領(lǐng)域模型（上下文）之上可以有多個發(fā)布單元，但是只有一個是服務(wù) ? 常見的發(fā)布單元劃分方式：一個服務(wù)、一個定時任務(wù)、一個管理后臺 服務(wù)之間選擇何種輕量級的通信協(xié)議？ ? API的實現(xiàn)技術(shù)應(yīng)該避免產(chǎn)生與客戶端的耦合 ? 例如 Java RMI，要求客戶端必須使用 Java語言，耦合很強 ? 應(yīng)該選擇與具體技術(shù)不相關(guān)的 API實現(xiàn)方式，以保證技術(shù)的選擇不被限制 ? 普通場合應(yīng)優(yōu)先選擇基于 HTTP的 RESTful API ? 基于 HTTP協(xié)議，互操作性好，各種編程語言都支持 ? 可伸縮性好 ? 松耦合 ? 易于測試 ? 易于形成統(tǒng)一的編程風格 服務(wù)之間選擇何種輕量級的通信協(xié)議？ ? 在特殊場合可以選擇二進制的 RPC協(xié)議 ? 對低延遲、實時性要求極高 ? 服務(wù)的 API極少變化，因此松耦合不重要 ? 可選的二進制的 RPC協(xié)議： ? 基于 Google Protocol Buffer數(shù)據(jù)交換格式的各種 RPC協(xié)議 ? 基于 Apache Thrift協(xié)議的各種 RPC協(xié)議，例如唯品會的 OSP ? 不建議選擇基于 HTTP的 RPC協(xié)議 ? 緊耦合 ? 可伸縮性差 如何確定使用何種服務(wù)編程語言？ ? 優(yōu)先選擇團隊原先掌握的編程語言 ? 選擇另外一種互補性強的編程語言 ? Java/C 與 ? 根據(jù)對性能的要求 ? 性能要求高： Java/C/? 性能要求不高： Python/Ruby ? 根據(jù)業(yè)務(wù)邏輯的變化頻繁程度 ? 業(yè)務(wù)邏輯相對固定： Java/C ? 業(yè)務(wù)邏輯可能經(jīng)常變化： 如何控制多語言帶來的復(fù)雜度 ? 在一個機構(gòu)內(nèi)，限制編程語言的數(shù)量 ? 服務(wù)編程語言限制在兩種以內(nèi) ? 客戶端編程語言限制在兩種以內(nèi) ? 建立統(tǒng)一的服務(wù) API設(shè)計風格 ? 例如各種語言都很容易實現(xiàn)的 RESTful API 如何做到服務(wù)的獨立部署？ ? 盡量減少服務(wù)之間的依賴 ? 服務(wù)功能做到高內(nèi)聚 ? API設(shè)計做到松耦合 ? 基于通用的通信機制，首選基于 HTTP的 RESTful API ? 服務(wù) API可做的獨立修改 ? 可自由添加非必需的請求參數(shù) ? 可自由修改請求參數(shù)的類型 ? 可自由添加響應(yīng)參數(shù) ? 可自由添加錯誤代碼 ? 可通過超文本通知客戶端相關(guān)聯(lián)的資源 ? 通過服務(wù)版本號控制不兼容的修改 如何做到服務(wù)的去中心化？ ? 不使用集中式的企業(yè)服務(wù)總線或服務(wù)注冊中心
法律信息相關(guān)推薦
鄂ICP備17016276號-1