微服務(wù)知識
傳統(tǒng)開發(fā)所有業(yè)務(wù)邏輯都在一個(gè)應(yīng)用中, 開發(fā)漾狼,測試瓢谢,部署隨著需求增加會(huì)不斷為單個(gè)項(xiàng)目增加不同業(yè)務(wù)模塊棍掐;前端展現(xiàn)也不局限于html視圖模板的形式,后端向前端支持需要更多的接口模塊阵赠。
隨著需求增多,項(xiàng)目變大鹤啡,單體系統(tǒng)部署在一個(gè)進(jìn)程內(nèi)部惯驼,往往修改很小的功能,為了部署上線也會(huì)影響其他功能。后期維護(hù)成本會(huì)變得越來越大祟牲,難以控制隙畜。
微服務(wù)架構(gòu)中不同模塊拆分成不同服務(wù),都能獨(dú)立部署和擴(kuò)展说贝,運(yùn)行在自己的進(jìn)程內(nèi)议惰,有穩(wěn)定的邊界,更新也不會(huì)影響其他服務(wù)運(yùn)營乡恕。而且由于是獨(dú)立部署的言询,可以更準(zhǔn)確的為每個(gè)服務(wù)評估性能容量,也更容易發(fā)現(xiàn)系統(tǒng)瓶頸位置。
微服務(wù)帶來的問題
微服務(wù)架構(gòu)有如此多優(yōu)點(diǎn)几颜,單也因?yàn)榉?wù)的拆分引入了許多問題倍试。
運(yùn)維人員需要維護(hù)的進(jìn)程數(shù)量增多了, 所以需要自動(dòng)化的工具讯屈。
服務(wù)拆分了,但業(yè)務(wù)邏輯的依賴不會(huì)消除蛋哭,只是從單體應(yīng)用的代碼依賴變?yōu)榱朔?wù)間的通信依賴, 所以要保證接口的正確調(diào)用,需要完善的接口和版本管理工具涮母。
由于服務(wù)獨(dú)立部署在各自進(jìn)程內(nèi)谆趾,所以它們間通信需要考慮網(wǎng)絡(luò)延遲,分布式事務(wù),異步消息,容錯(cuò)性等。
微服務(wù)實(shí)施
服務(wù)調(diào)用
在微服務(wù)架構(gòu)中通常通過兩種方式互相通信:
使用HTTP的RESTFUL API或輕量級消息發(fā)送協(xié)議, 實(shí)現(xiàn)消息傳遞和服務(wù)調(diào)用的觸發(fā)
通過輕量級消息總線上傳消息叛本,類似RabbitMQ提供可靠異步交換.
去中心化管理
在實(shí)施微服務(wù)架構(gòu)時(shí)沪蓬,希望每一個(gè)服務(wù)都管理其自由的數(shù)據(jù)庫,這就是數(shù)據(jù)管理的去中心化来候。
但隨之而來數(shù)據(jù)一致性也成了需要解決的問題直以跷叉,分布式事務(wù)本身實(shí)現(xiàn)難度就非常大,所以在微服務(wù)架構(gòu)中营搅,強(qiáng)調(diào)在各個(gè)服務(wù)之間進(jìn)行無事務(wù)的調(diào)用云挟,對數(shù)據(jù)一致性,只要求數(shù)據(jù)在最后處理狀態(tài)一致即刻转质;若在過程中發(fā)現(xiàn)錯(cuò)誤园欣, 通過補(bǔ)償機(jī)制來進(jìn)行處理,使得錯(cuò)誤數(shù)據(jù)能夠達(dá)到最終的 一 致性休蟹。
以下內(nèi)容摘自我的領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)(DDD:Domain-Driven Design)筆記
傳統(tǒng)架構(gòu)沸枯,數(shù)據(jù)一般是強(qiáng)一致性的,我們通常會(huì)使用數(shù)據(jù)庫事務(wù)保證一次操作的所有數(shù)據(jù)修改都在一個(gè)數(shù)據(jù)庫事務(wù)里赂弓,從而保證了數(shù)據(jù)的強(qiáng)一致性绑榴。在分布式的場景,我們也同樣希望數(shù)據(jù)的強(qiáng)一致性盈魁,就是使用分布式事務(wù)翔怎。但是眾所周知,分布式事務(wù)的難度备埃、成本是非常高的姓惑,而且采用分布式事務(wù)的系統(tǒng)的吞吐量都會(huì)比較低褐奴,系統(tǒng)的可用性也會(huì)比較低。所以于毙,很多時(shí)候敦冬,我們也會(huì)放棄數(shù)據(jù)的強(qiáng)一致性,而采用最終一致性唯沮;
CQRS(Command Query Responsibility Segregation)架構(gòu) - 命令查詢的責(zé)任分離, 則完全秉持最終一致性的理念脖旱。這種架構(gòu)基于一個(gè)很重要的假設(shè),就是用戶看到的數(shù)據(jù)總是舊的介蛉。比如秒殺的場景萌庆,當(dāng)你下單前,也許界面上你看到的商品數(shù)量是有的币旧,但是當(dāng)你下單的時(shí)候践险,系統(tǒng)提示商品賣完了。
容錯(cuò)設(shè)計(jì)
單體應(yīng)用中, 一般不存在單個(gè)組件故障而其他部件還能運(yùn)行的情況吹菱,通常是一掛全掛巍虫。
在微服務(wù)架構(gòu)中,當(dāng)部分服務(wù)存在故障鳍刷,而導(dǎo)致沒有返回占遥,線程掛起等待,直到超時(shí)才能釋放输瓜。正常服務(wù)頻繁調(diào)用故障服務(wù)瓦胎,導(dǎo)致大量線程被掛起,從而出現(xiàn)故障蔓延尤揣。
所以晶塊檢測出故障源并京可能自動(dòng)恢復(fù)服務(wù)很關(guān)鍵搔啊。通常希望每個(gè)服務(wù)中實(shí)現(xiàn)監(jiān)控和日志記錄,比如服務(wù)狀態(tài)芹缔,斷路器狀態(tài)坯癣,吞吐量,網(wǎng)絡(luò)延遲等關(guān)鍵數(shù)據(jù)的儀表盤最欠。
思想轉(zhuǎn)變
設(shè)計(jì)服務(wù)時(shí)示罗,需要學(xué)習(xí)領(lǐng)域驅(qū)動(dòng)設(shè)計(jì),細(xì)致的分出每個(gè)服務(wù)和相關(guān)邊界芝硬。
實(shí)施微服務(wù)的團(tuán)隊(duì)蚜点,每個(gè)小組都應(yīng)該以做產(chǎn)品的方式,對服務(wù)的整個(gè)生命周期負(fù)責(zé)拌阴。
Spring Cloud 介紹
Spring Cloud 是基于Spring Boot的微服務(wù)架構(gòu)開發(fā)工具绍绘,它為微服務(wù)中涉及的配置管理,服務(wù)治理, 斷路器, 智能路由, 微代理, 控制總線, 全局鎖,決策競選,分布式會(huì)話和集群狀態(tài)管理等操作提供了簡單的開發(fā)方式。
常用子項(xiàng)目:
Spring Cloud Config 配置管理工具, 支持使用Git存儲(chǔ) 配置內(nèi)容, 可以使用它實(shí)現(xiàn)應(yīng)用配置的外部化存儲(chǔ)陪拘, 并支持客戶端配置信息刷新厂镇、 加密/ 解密配置內(nèi)容 等
Spring Cloud Netflix 核心組件,對多個(gè)Netflix OSS套件進(jìn)行整合
Eureka 服務(wù)治理組件左刽,包含服務(wù)注冊中心捺信、 服務(wù)注冊與發(fā)現(xiàn)機(jī)制的實(shí)現(xiàn)。
Hystrix 容錯(cuò)管理組件欠痴,實(shí)現(xiàn)斷路器模式迄靠,幫助服務(wù)依賴中出現(xiàn)的延遲和為故障提供強(qiáng)大的容錯(cuò)能力。
Ribbon 客戶端負(fù)載均衡的服務(wù)調(diào)用組件喇辽。
Feign 基于Ribbon和Hystrix的聲明式服務(wù)調(diào)用組件掌挚。
Zuul 網(wǎng)關(guān)組件,提供智能路由菩咨,訪問過濾等功能吠式。
Archaius 外部化配置組件
Spring Cloud Bus 事件、消息總線旦委。用于傳播集群中的狀態(tài)變化或事件奇徒, 以觸發(fā)后續(xù)的處理, 比如用來動(dòng)態(tài)刷新配置等缨硝。
Spring Cloud Cluster 針對ZooKeeper,Redis,Hazelcast,Consul的選舉算法和通用狀態(tài)模式的實(shí)現(xiàn)。
Spring Cloud Consul 服務(wù)發(fā)現(xiàn)與配置管理工具罢低。
Spring Cloud Stream 通過Redis,Rabbit或Kafka實(shí)現(xiàn)的消費(fèi)微服務(wù),通過簡單的聲明式模型來發(fā)送和接收消息查辩。
Spring Cloud Security 安全工具包,提供在Zuul代理中對OAuth2客戶端請求的中繼器网持。
Spring Cloud Sleuth 分布式跟蹤實(shí)現(xiàn)宜岛,可以完美整合Zipkin
Spring Cloud ZooKeeper 服務(wù)發(fā)現(xiàn)與配置管理工具
Spring Cloud Starters 基于Spring Boot風(fēng)格項(xiàng)目的基礎(chǔ)依賴模塊。