微服務(wù)設(shè)計(jì)的方法是什么

這篇文章主要講解了“微服務(wù)設(shè)計(jì)的方法是什么”，文中的講解內(nèi)容簡(jiǎn)單清晰，易于學(xué)習(xí)與理解，下面請(qǐng)大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“微服務(wù)設(shè)計(jì)的方法是什么”吧！

一、微服務(wù)架構(gòu)理論

1.六邊形架構(gòu)
1)六邊形架構(gòu)（Hexagonal Architecture），又稱為端口和適配器架構(gòu)風(fēng)格；使用適配器與外界進(jìn)行交互，外界通過應(yīng)用層API與內(nèi)部進(jìn)行交互。
2)經(jīng)典分層架構(gòu)更多的精力放在抽象的分離上，每個(gè)層的職責(zé)分的很明確。 在六邊形架構(gòu)中，是用“組件化”的形式來避免耦合的出現(xiàn)，每個(gè)業(yè)務(wù)單元盡可能的最小化，這種方式用一個(gè)詞來概括，那就是“扁平化”。
3)經(jīng)典分層架構(gòu)分為四層，而對(duì)于六邊形架構(gòu)，一般會(huì)分成三層：領(lǐng)域?qū)?、端口層、適配器層。
2.服務(wù)的大小
1)某些場(chǎng)景下，認(rèn)為每個(gè)微服務(wù)的開發(fā)工作量不應(yīng)大于2個(gè)周。
2)黃金法則，對(duì)一個(gè)微服務(wù)的修改及部署，不影響其他服務(wù)。
3.微服務(wù)的優(yōu)勢(shì)
1)技術(shù)異構(gòu)性
2)高容錯(cuò)，服務(wù)可降級(jí)(艙壁)。單個(gè)服務(wù)故障，不會(huì)引起整個(gè)系統(tǒng)故障。
3)已于擴(kuò)展 只需擴(kuò)展高負(fù)載的應(yīng)用即可。
4)簡(jiǎn)化部署 相對(duì)于部署單一大型應(yīng)用，更簡(jiǎn)單。
5)與組織結(jié)構(gòu)相匹配，易于工作分派。
6)組合、重用性。
7)可替代性優(yōu)化 可以避免無法改造大型單一應(yīng)用的痛苦。
4.OSGI
OSGI(Open Services Gateway Initiative)支持模塊熱部署，方便模塊管理.但是其最終基于jvm，一個(gè)服務(wù)的故障依然會(huì)導(dǎo)致整個(gè)jvm crush.osgi適合構(gòu)建單一服務(wù)節(jié)點(diǎn)的內(nèi)部應(yīng)用，對(duì)于微服務(wù)架構(gòu)來說，大部分場(chǎng)景下有點(diǎn)不實(shí)用；java9之后推出JPMS方式，OSGI的應(yīng)用場(chǎng)景就更受擠壓了。

二、微服務(wù)架構(gòu)師

1.原則
1)演化 架構(gòu)師應(yīng)該從演化的角度看待問題，不應(yīng)關(guān)注具體技術(shù)細(xì)節(jié)，追求完美。
2)分區(qū) 架構(gòu)師不應(yīng)過多關(guān)注服務(wù)內(nèi)部的問題，而應(yīng)更多的關(guān)注區(qū)域之間的問題。
3)戰(zhàn)略目標(biāo)的設(shè)定不是架構(gòu)師的職責(zé)
4)代碼治理 把控范例
5)評(píng)估技術(shù)債務(wù)
6)進(jìn)行例外管理
7)集中治理和團(tuán)隊(duì)建設(shè)
2.設(shè)計(jì)標(biāo)準(zhǔn)
1)監(jiān)控 健康監(jiān)控應(yīng)該標(biāo)準(zhǔn)化，不應(yīng)該為特定服務(wù)改變監(jiān)控服務(wù)。
2)接口
a.API應(yīng)該與消費(fèi)方解耦，應(yīng)選擇技術(shù)不相關(guān)的實(shí)現(xiàn)方式，并易于升級(jí)，如可隨意增加字段，而不影響已有消費(fèi)者。
b.REST API設(shè)計(jì)應(yīng)該基于“資源“，無狀態(tài)，URL中不出現(xiàn)動(dòng)詞，只用名詞，使用GET、POST、DELETE等操作資源。
GET：查詢，POST：新增，PUT：更新，DELETE：刪除
c.API應(yīng)該有版本的概念。
d.使用Token進(jìn)行身份校驗(yàn)，而不是cookie。
e.RFC標(biāo)準(zhǔn)中URL中大小寫是敏感的，雖然實(shí)際使用中不敏感，但應(yīng)統(tǒng)一使用小寫，使用-而不是_做字符串分隔符。搜索引擎認(rèn)為字符"-"是多個(gè)關(guān)鍵詞，IE瀏覽器對(duì)"_"的支持不好。
f.速度限制
如果對(duì)訪問的次數(shù)不加控制，很可能會(huì)被DDos攻擊。為此RFC6585引入了HTTP狀態(tài)碼429（too many requests）。
Github API 使用的三個(gè)相關(guān)的頭部：
X-RateLimit-Limit: 用戶每個(gè)小時(shí)允許發(fā)送請(qǐng)求的最大值
X-RateLimit-Remaining：當(dāng)前時(shí)間窗口剩下的可用請(qǐng)求數(shù)目
X-RateLimit-Rest: 時(shí)間 窗口重置的時(shí)候，到這個(gè)時(shí)間點(diǎn)可用的請(qǐng)求數(shù)量就會(huì)變成X-RateLimit-Limit的值
g.使用HTTP頭處理緩存和并發(fā)
h.對(duì)大結(jié)果集應(yīng)進(jìn)行分頁
i.避免多個(gè)服務(wù)共享一個(gè)數(shù)據(jù)庫(kù)的情況
3)關(guān)注架構(gòu)安全性 應(yīng)妥善處理錯(cuò)誤請(qǐng)求，可使用斷路器

三、微服務(wù)建模

1.原則 高內(nèi)聚 松耦合
2.使用領(lǐng)域工程和界限上下文來劃分服務(wù)
3.避免過早劃分服務(wù)
4.優(yōu)先考慮地理位置和組織結(jié)構(gòu)，按照技術(shù)接縫劃分并不一定正確。

四、集成

1.選擇合理的接口技術(shù)
2.合理選擇編排與協(xié)同
通常協(xié)同可以更好的降低耦合度

3.避免災(zāi)難性故障轉(zhuǎn)移 如：會(huì)導(dǎo)致消費(fèi)者崩潰的消息，應(yīng)設(shè)置最大重試次數(shù)，并及時(shí)移入死信隊(duì)列。
4.按引用訪問服務(wù)資源 如調(diào)用郵件發(fā)送模塊時(shí)，往往是延遲發(fā)送的，發(fā)送內(nèi)容可能已經(jīng)被修改了，正確的方式是，只發(fā)送引用，在發(fā)送郵件時(shí)，再查詢?cè)敿?xì)信息。
5.服務(wù)應(yīng)該采用容錯(cuò)性讀取。
Postel法則，魯棒性原則 每個(gè)模塊都應(yīng)該寬進(jìn)嚴(yán)出，對(duì)自己發(fā)送的東西嚴(yán)格，對(duì)接收的東西容錯(cuò)。

五、分解單塊系統(tǒng)

1.通過界限上下文，找出系統(tǒng)接縫，通過接縫拆分服務(wù)及數(shù)據(jù)庫(kù)。 重構(gòu)數(shù)據(jù)庫(kù)的最佳實(shí)踐是，先分離數(shù)據(jù)庫(kù)，再拆分應(yīng)用。

六、部署

1.CI(Continuous Integration,持續(xù)集成)
CD(Continuous Delivery,持續(xù)交付)
a.構(gòu)建流水線，將構(gòu)建分解為多個(gè)階段，快速失敗。
b.在項(xiàng)目初始階段，所有服務(wù)可以放在一個(gè)構(gòu)建里，當(dāng)服務(wù)穩(wěn)定后，應(yīng)該每個(gè)微服務(wù)都有自己的構(gòu)建。
c.定制化鏡像，加速部署；將微服務(wù)本身也預(yù)安裝在鏡像中，將鏡像作為構(gòu)建物。
d.統(tǒng)一配置文件管理，開發(fā)專用部署系統(tǒng)。

七、測(cè)試

1.消費(fèi)者驅(qū)動(dòng)契約測(cè)試(Consumer-Driven Contract,CDC)
CDC可以有效避免變更破壞新服務(wù)的消費(fèi)者。CDC會(huì)定義消費(fèi)者的期望，這些期望會(huì)變成對(duì)生產(chǎn)者的測(cè)試代碼。
2.部署后再測(cè)試
僅僅依靠部署之前的測(cè)試，不可能把缺陷率將為0。部署與上線是不同的階段，可以通過藍(lán)綠部署，部署兩套系統(tǒng)，但只有一套系統(tǒng)接受真正的請(qǐng)求。 也可以采用金絲雀發(fā)布，將一小部分真正的流量引向新版本，進(jìn)行驗(yàn)證。
3.平居故障修復(fù)時(shí)間MTTR勝過平均故障間隔時(shí)間MTBF
4.Scrum敏捷軟件開發(fā)中，將自動(dòng)化測(cè)試分為了單元測(cè)試、服務(wù)測(cè)試、用戶界面測(cè)試三層。

八、監(jiān)控

1.使用語義監(jiān)控，我們可以在生產(chǎn)環(huán)境運(yùn)行一些測(cè)試用例，當(dāng)這些案例如果沒有達(dá)到我們預(yù)期的值時(shí)，我們會(huì)認(rèn)為生產(chǎn)環(huán)境的某個(gè)環(huán)境出問題了；如定時(shí)打開首頁等。
2.通過關(guān)聯(lián)標(biāo)識(shí)，標(biāo)記調(diào)用鏈，例如在HTTP首部追加標(biāo)識(shí)。
3.建立標(biāo)準(zhǔn)化的日志，以標(biāo)準(zhǔn)格式記錄日志，統(tǒng)一服務(wù)指標(biāo)名稱(響應(yīng)時(shí)間、錯(cuò)誤率、應(yīng)用指標(biāo)等)。

九、安全

1.身份驗(yàn)證和授權(quán)方式
1)SSO
2)SAML安全斷言標(biāo)記語言 基于XML/SOAP的開源標(biāo)準(zhǔn)數(shù)據(jù)格式
3)OpenID Connect協(xié)議 4)單點(diǎn)登錄網(wǎng)關(guān) 使用網(wǎng)關(guān)驗(yàn)證身份與授權(quán)；認(rèn)證通過后，網(wǎng)關(guān)將主體信息放在HTTP頭上。
應(yīng)該進(jìn)行深度防御，不應(yīng)完全依賴單點(diǎn)登陸網(wǎng)關(guān)。也可以在網(wǎng)關(guān)上終止HTTPS，進(jìn)行入侵檢測(cè)等。
單點(diǎn)登陸網(wǎng)關(guān)應(yīng)該只負(fù)責(zé)粗粒度的授權(quán)，細(xì)粒度的授權(quán)應(yīng)該在服務(wù)中實(shí)現(xiàn)。
2.服務(wù)間身份驗(yàn)證和授權(quán)
1)在邊界內(nèi)允許一切。
2)使用HTTPS基本身份驗(yàn)證
3)使用SAML或OpenID Connect
4)使用客戶端證書
5)在HTTP之上使用HAMC
當(dāng)使用HTTPS性能損耗較大，且不能緩存時(shí)，可以使用HMAC。
HMAC(Hash-based Message Authentication Code,基于HASH的消息碼)，它使用對(duì)稱密鑰，將請(qǐng)求的主體和密鑰一起，進(jìn)行HASH處理。
服務(wù)器也進(jìn)行hash就知道數(shù)據(jù)是否被篡改了，但不能防止數(shù)據(jù)泄露。在亞馬遜S3中使用了該方式。
6)API密鑰
7)SSL之上的流量不能被反向代理服務(wù)器緩存。HTTPS的CDN價(jià)格較高。
8)混淆代理人問題
成功通過認(rèn)證的用戶可能會(huì)偽裝成其他用戶，訪問他人數(shù)據(jù)。
3.數(shù)據(jù)安全
使用加鹽的密碼hash
不應(yīng)把敏感的數(shù)據(jù)寫入日志
4.深度防御
防火墻/日志/入侵檢測(cè)/網(wǎng)絡(luò)隔離/操作系統(tǒng)
5.OWASP安全框架 安全威脅Top10

十、組織與系統(tǒng)設(shè)計(jì)的關(guān)系

1.康威定律
任何組織所交付的設(shè)計(jì)方案在結(jié)構(gòu)上都與該組織的溝通結(jié)構(gòu)保持一致。
反向康威定律
設(shè)計(jì)糟糕的系統(tǒng)有時(shí)迫使組織修改其結(jié)構(gòu)，以適應(yīng)系統(tǒng)。
2.組織耦合度
通常松耦合的組織開發(fā)的產(chǎn)品模塊化更好，耦合度更低。
典型的緊耦合組織如商業(yè)產(chǎn)品公司，松耦合組織如開源社區(qū)。
3.組織與軟件質(zhì)量的關(guān)系
在windows vista的開發(fā)中發(fā)現(xiàn)，與組織結(jié)構(gòu)相關(guān)聯(lián)的指標(biāo)和軟件質(zhì)量的相關(guān)度最高。而非代碼復(fù)雜度等常見指標(biāo)。
4.組織應(yīng)對(duì)服務(wù)的整個(gè)生命周期負(fù)責(zé)
組織應(yīng)對(duì)服務(wù)具有所有權(quán)，而非多個(gè)組織共享服務(wù)所有權(quán)。
在涉及多個(gè)組織的項(xiàng)目中，不共享服務(wù)所有權(quán)，會(huì)帶來溝通問題。較為有效的解決方案是實(shí)行內(nèi)部開源，互相開放代碼與文檔，像開源項(xiàng)目那樣貢獻(xiàn)與合并代碼。
保證代碼質(zhì)量，與持續(xù)可維護(hù)性。
5.組織結(jié)構(gòu)應(yīng)該與界限上下文保持一致。
6.不同業(yè)務(wù)線間的服務(wù)應(yīng)采用異步批處理方式，以便可以隨時(shí)停機(jī)維護(hù)。

十一、規(guī)?；⒎?wù)

1.部署名詞
1)藍(lán)綠部署
同時(shí)部署兩套冗余系統(tǒng)，實(shí)現(xiàn)不停機(jī)升級(jí)。涉及在途業(yè)務(wù)及數(shù)據(jù)遷移。
2)A/B測(cè)試
一部分用戶用老系統(tǒng)/一部分用新系統(tǒng) 驗(yàn)證新系統(tǒng)可靠性。
3)灰度發(fā)布/金絲雀發(fā)布
在保持老版本可用的情況下，部署一套新系統(tǒng)，新系統(tǒng)有問題立即切換回老系統(tǒng)。
4)滾動(dòng)發(fā)布
只有一套集群，無冗余，每次取出一部分，如20%的服務(wù)器升級(jí)，直到全部升級(jí)完成。
2.架構(gòu)安全性措施
在出現(xiàn)故障時(shí)，應(yīng)當(dāng)能夠恰當(dāng)?shù)墓δ芙导?jí)，而非使整個(gè)系統(tǒng)下線。
要防止由于某一服務(wù)的故障導(dǎo)致級(jí)聯(lián)大崩潰。
架構(gòu)安全性措施：
超時(shí)/延遲帶來的危害往往致命，要注意超時(shí)機(jī)制的使用。
斷路器，下游出現(xiàn)問題時(shí)，及時(shí)斷開，快速失敗。
艙壁，隔離影響。
隔離，設(shè)計(jì)上允許下游離線，服務(wù)間相互隔離。
3.冪等
4.擴(kuò)展
垂直擴(kuò)展 更好的主機(jī)
拆分負(fù)載 拆分成不同服務(wù)
分散風(fēng)險(xiǎn) 分散部署
負(fù)載均衡 SSL往往會(huì)在負(fù)載均衡器前終止，為了防止信息泄露，可以嘗試把負(fù)載均衡器與后端實(shí)例放在一個(gè)局域網(wǎng)內(nèi)。
基于worker的系統(tǒng) 除了負(fù)載均衡，也可以通過消息隊(duì)列來降低脆弱性，降低負(fù)載。
5.數(shù)據(jù)庫(kù)擴(kuò)展
讀寫分離 擴(kuò)展緩存往往比讀寫分離更有效。
寫擴(kuò)展 數(shù)據(jù)分片，更好的主機(jī)，分片擴(kuò)展困難，不能解決HA。
避免共享一個(gè)數(shù)據(jù)庫(kù)基礎(chǔ)設(shè)施 一個(gè)物理數(shù)據(jù)庫(kù)建立多個(gè)schema。
嘗試使用CQRS(命令查詢職責(zé)分離模式) 將應(yīng)用程序分為兩部分：命令端和查詢端。命令端處理程序創(chuàng)建，更新和刪除請(qǐng)求，并在數(shù)據(jù)更改時(shí)發(fā)出事件。查詢端負(fù)責(zé)查詢。
6.緩存
1)客戶端緩存/反向代理和CDN緩存/服務(wù)器端緩存(一級(jí)緩存、二級(jí)緩存)
2)HTTP緩存
a.cache-control TTL(Time To Live)指定緩存幾秒
b.設(shè)定Expires頭部 指定緩存到某一具體時(shí)間，如：新版本上線時(shí)間
c.設(shè)置Etag 在URL后增加隨機(jī)字符串
3)必要時(shí)增加寫緩存，先寫緩存，再寫入數(shù)據(jù)庫(kù)。
4)使用彈性緩存 在下游出現(xiàn)故障時(shí)，使用緩存的數(shù)據(jù)，比停止服務(wù)好。
5)隱藏源服務(wù) 在緩存故障或大量失效時(shí)，要避雪崩?？梢酝ㄟ^快速失敗、數(shù)據(jù)庫(kù)本地一級(jí)緩存等措施保護(hù)源服務(wù)。
6)應(yīng)避免多級(jí)緩存，不要使用過長(zhǎng)的緩存過期時(shí)間，在ISP和用戶瀏覽器中的緩存是不受控的。
7)衛(wèi)報(bào)使用了爬蟲技術(shù)，爬取自己的網(wǎng)頁，在系統(tǒng)故障時(shí)，有一個(gè)可使用的靜態(tài)網(wǎng)頁。
7.CAP定理
無法同時(shí)滿足一致性Consistency、可用性Availability、分區(qū)容錯(cuò)性Partition
由于分布式系統(tǒng)必須要分區(qū)，所以往往權(quán)衡選擇AP或CP。
可以在部分功能使用AP、另外一些功能使用CP。

十二、微服務(wù)原則

1.微服務(wù)理念

核心 自治的小服務(wù)
圍繞業(yè)務(wù)概念建模
自動(dòng)化的文化
隱藏內(nèi)部實(shí)現(xiàn)細(xì)節(jié)
一切都去中心化
獨(dú)立部署
隔離失敗
高度可觀察
2.問題
要熟悉業(yè)務(wù)領(lǐng)域，劃分服務(wù)。
集群的部署/監(jiān)控等問題。
不建議從0開發(fā)微服務(wù)，優(yōu)先考慮單體服務(wù)。
不應(yīng)使用數(shù)據(jù)集成。
微服務(wù)應(yīng)面向業(yè)務(wù)建模，而非面向技術(shù)建模；應(yīng)避免技術(shù)導(dǎo)向。

感謝各位的閱讀，以上就是“微服務(wù)設(shè)計(jì)的方法是什么”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對(duì)微服務(wù)設(shè)計(jì)的方法是什么這一問題有了更深刻的體會(huì)，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是億速云，小編將為大家推送更多相關(guān)知識(shí)點(diǎn)的文章，歡迎關(guān)注！