微服務(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ǔ)依賴模塊。