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