主題：微服務(wù)的安全認(rèn)證
一侵贵、認(rèn)識(shí)微服務(wù)
1.1 微服務(wù)的出道
軟件架構(gòu)（Software Architecture）是有關(guān)軟件整體結(jié)構(gòu)與組件的抽象描述咳燕。
根據(jù)軟件系統(tǒng)在運(yùn)行期的表現(xiàn)風(fēng)格和部署結(jié)構(gòu)啊掏，可以粗略地將其劃分為兩大類：“單體架構(gòu)”（Monolithic Architecture）境氢、“分布式架構(gòu)”（Distributed Architecture）臼膏。
四個(gè)時(shí)期：單體結(jié)構(gòu)危尿、垂直架構(gòu)、SOA架構(gòu)朗和、微服務(wù)架構(gòu)
（A）單體架構(gòu)
? 當(dāng)網(wǎng)站流量很小時(shí)错沽，只需一個(gè)應(yīng)用，將所有功能都部署在一起眶拉，以減少部署節(jié)點(diǎn)和成本千埃。這種將所有功能都部署在一個(gè)web容器中運(yùn)行的系統(tǒng)就叫做單體架構(gòu)（也叫：巨石型應(yīng)用）。
<span style="font-size:14pt;">簡(jiǎn)單單體模式</span>
? 代碼層面沒有拆分忆植，所有的業(yè)務(wù)邏輯都在一個(gè)項(xiàng)目（Project）里打包成一個(gè)二進(jìn)制的編譯后文件放可，通過(guò)這個(gè)文件進(jìn)行部署，并提供業(yè)務(wù)能力朝刊。最典型的就是LAMP系統(tǒng)（Linux+PHP+Apache+MySQL）,這種部署結(jié)構(gòu)過(guò)于龐大耀里，導(dǎo)致業(yè)務(wù)系統(tǒng)啟動(dòng)很慢。
? 隨著網(wǎng)站的上線拾氓，訪問(wèn)量逐步上升备韧，單臺(tái)機(jī)器的性能遇到瓶頸的時(shí)候，最先采取的是：web 服務(wù)器和數(shù)據(jù)庫(kù)服務(wù)器拆分開來(lái)痪枫，這樣做的話不僅提高了單機(jī)的負(fù)載能力织堂，也提高了整個(gè)系統(tǒng)的容災(zāi)能力。
? 隨著訪問(wèn)量的繼續(xù)不斷增加奶陈，單臺(tái)應(yīng)用服務(wù)器已經(jīng)無(wú)法滿足我們的需求易阳。 假設(shè)數(shù)據(jù)庫(kù)服務(wù)器還沒有遇到性能問(wèn)題，那我們可以通過(guò)增加應(yīng)用服務(wù)器的方式來(lái)將應(yīng)用服務(wù)器集群化吃粒，這樣就可以將用戶請(qǐng)求分流到各個(gè)服務(wù)器中潦俺，從而達(dá)到繼續(xù)提升系統(tǒng)負(fù)載能力的目的。此時(shí)各個(gè)應(yīng)用服務(wù)器之間沒有直接的交互徐勃，他們都是依賴數(shù)據(jù)庫(kù)各自對(duì)外提供服務(wù)事示。
? 集群架構(gòu)(屬于水平拓展) 相當(dāng)于把同一個(gè)項(xiàng)目部署到多個(gè)服務(wù)器上（相當(dāng)于復(fù)制備份），然后通過(guò)負(fù)載均衡服務(wù)器nginx將請(qǐng)求分別均衡的派發(fā)到不同的tomcat服務(wù)器上僻肖，不同服務(wù)器上運(yùn)行的是同一個(gè)web項(xiàng)目肖爵。
特點(diǎn)：
1、所有的功能集成在一個(gè)項(xiàng)目工程中臀脏。
2劝堪、所有的功能打一個(gè)war包部署到服務(wù)器冀自。
3、通過(guò)部署應(yīng)用集群和數(shù)據(jù)庫(kù)集群來(lái)提高系統(tǒng)的性能秒啦。
優(yōu)點(diǎn)：
項(xiàng)目架構(gòu)簡(jiǎn)單熬粗，前期開發(fā)成本低，周期短余境，小型項(xiàng)目的首選驻呐。
缺點(diǎn)：
1、全部功能集成在一個(gè)工程中芳来，對(duì)于大型項(xiàng)目不易開發(fā)含末、擴(kuò)展及維護(hù)。
2绣张、單點(diǎn)容錯(cuò)率低，并發(fā)能力差关带。
<span style="font-size:14pt;">垂直架構(gòu)</span>
?
? 當(dāng)訪問(wèn)量逐漸增大侥涵，單一應(yīng)用無(wú)法滿足需求，此時(shí)為了應(yīng)對(duì)更高的并發(fā)和業(yè)務(wù)需求宋雏，我們根據(jù)業(yè)務(wù)功能對(duì)系統(tǒng)進(jìn)行拆分芜飘。
<span style="color: blue; font-size: 12pt">MVC 模式</span>
? 系統(tǒng)內(nèi)每個(gè)模塊的功能組件按照不同的職責(zé)劃分為模型（Model）、視圖（View）磨总、控制器（Controller）等角色嗦明，并以此來(lái)組織研發(fā)實(shí)現(xiàn)工作，整個(gè)系統(tǒng)由多個(gè)模塊組成蚪燕，每個(gè)模塊又由這種不同的部分組成娶牌。
? SpringMVC的流程簡(jiǎn)略示意圖：
?
? 利用框架可以簡(jiǎn)化各層的開發(fā)：表現(xiàn)層使用SpringMVC或者Struts2，持久層使用Mybatis或Hibernate馆纳，使用spring管理表現(xiàn)層诗良，業(yè)務(wù)層和持久層三層之間的關(guān)系。
<span style="color: blue; font-size: 12pt">前后端分離模式</span>
? 將前后端代碼耦合的設(shè)計(jì)改為前端邏輯和后端邏輯獨(dú)立編寫實(shí)現(xiàn)的處理模式鲁驶；
? 只要數(shù)據(jù)接口保持穩(wěn)定不變鉴裹，那么前后端系統(tǒng)可以各自獨(dú)立發(fā)展和維護(hù)。目前最主流的三種前端開發(fā)框架（React钥弯、AngularJS径荔、Vue），都遵循著這種設(shè)計(jì)理念脆霎。
特點(diǎn)：
1总处、以單體結(jié)構(gòu)規(guī)模的項(xiàng)目為單位進(jìn)行垂直劃分，一個(gè)大項(xiàng)目拆分成一個(gè)一個(gè)單體結(jié)構(gòu)項(xiàng)目睛蛛。
2辨泳、項(xiàng)目之間的接口多為數(shù)據(jù)同步功能虱岂，如：數(shù)據(jù)庫(kù)之間通過(guò)網(wǎng)絡(luò)接口進(jìn)行數(shù)據(jù)庫(kù)同步。
優(yōu)點(diǎn)：
1菠红、系統(tǒng)拆分實(shí)現(xiàn)了流量分擔(dān)第岖，解決了并發(fā)問(wèn)題
2、可以針對(duì)不同模塊進(jìn)行優(yōu)化
3试溯、方便水平擴(kuò)展蔑滓，負(fù)載均衡，容錯(cuò)率提高
4遇绞、系統(tǒng)間相互獨(dú)立
缺點(diǎn)：
1键袱、服務(wù)之間相互調(diào)用，如果某個(gè)服務(wù)的端口或者ip地址發(fā)生改變摹闽，調(diào)用的系統(tǒng)得手動(dòng)改變
2蹄咖、搭建集群之后，實(shí)現(xiàn)負(fù)載均衡比較復(fù)雜
（B）分布式架構(gòu)（RPC）
? 當(dāng)垂直應(yīng)用越來(lái)越多付鹿，應(yīng)用之間交互不可避免澜汤，將核心業(yè)務(wù)抽取出來(lái)，作為獨(dú)立的服務(wù)舵匾，逐漸形成穩(wěn)定的服務(wù)中心俊抵，使前端應(yīng)用能更快速的響應(yīng)多變的市場(chǎng)需求。此時(shí)坐梯，用于提高業(yè)務(wù)復(fù)用及整合的分布式調(diào)用是關(guān)鍵徽诲。
? 分布式架構(gòu)就是多個(gè)子系統(tǒng)互相協(xié)作才能完成整個(gè)業(yè)務(wù)流程，系統(tǒng)之間需要進(jìn)行通信吵血。分布式系統(tǒng)作為一個(gè)整體對(duì)用戶提供服務(wù)谎替，而整個(gè)系統(tǒng)的內(nèi)部的協(xié)作對(duì)用戶來(lái)說(shuō)是透明的，用戶就像是只使用一個(gè)系統(tǒng) 一樣蹋辅。分布式系統(tǒng)中的多臺(tái)計(jì)算機(jī)之間在空間位置上可以隨意分布院喜，同時(shí)，機(jī)器的分布情況也會(huì)隨時(shí)變動(dòng)晕翠。
? RPC（Remote Procedure Call）它是一種進(jìn)程間通信方式喷舀，允許像調(diào)用本地服務(wù)一樣調(diào)用遠(yuǎn)程服務(wù)， ——從遠(yuǎn)程主機(jī)調(diào)用一個(gè)過(guò)程/函數(shù)淋肾。 兩臺(tái)服務(wù)器A硫麻、B，分別部署不同的應(yīng)用a樊卓，b拿愧。當(dāng)A服務(wù)器想要調(diào)用B服務(wù)器上應(yīng)用b提供的函數(shù)或方法的時(shí)候，由于不在一個(gè)內(nèi)存空間碌尔，不能直接調(diào)用浇辜，需要通過(guò)網(wǎng)絡(luò)來(lái)表達(dá)調(diào)用的語(yǔ)義傳達(dá)調(diào)用的數(shù)據(jù)券敌。 2006年之后，隨著移動(dòng)互聯(lián)網(wǎng)的發(fā)展柳洋，各種智能終端的普及待诅，遠(yuǎn)程分布式調(diào)用已經(jīng)成為主流，RPC框架也如雨后春筍般誕生熊镣，開源和自研的RPC框架的普及標(biāo)志著傳統(tǒng)垂直應(yīng)用架構(gòu)時(shí)代的終結(jié)卑雁。
分布式的演進(jìn)
分布式架構(gòu)的應(yīng)用
- 分布式文件系統(tǒng)
例如：出名的有 Hadoop 的 HDFS, 還有 google的 GFS , 淘寶的 TFS 等
- 分布式緩存
例如：memcache , hbase, mongdb 等
- 分布式數(shù)據(jù)庫(kù)
例如：mysql, mariadb, postgreSql 等
……
優(yōu)點(diǎn)：
將基礎(chǔ)服務(wù)進(jìn)行了抽取，系統(tǒng)間相互調(diào)用 (RPC Remote Procedure Call 遠(yuǎn)程過(guò)程調(diào)用)绪囱，提高了代碼復(fù)用和開發(fā)效率
<span style="font-size:14pt;">面向服務(wù)架構(gòu)（SOA）</span>
分布式出現(xiàn)的問(wèn)題
服務(wù)越來(lái)越多测蹲，需要管理每個(gè)服務(wù)的地址
調(diào)用關(guān)系錯(cuò)綜復(fù)雜，難以理清依賴關(guān)系
服務(wù)過(guò)多鬼吵，服務(wù)狀態(tài)難以管理扣甲，無(wú)法根據(jù)服務(wù)情況動(dòng)態(tài)管理
? <span style="color: blue; font-size: 15pt">資源調(diào)度和治理中心(SOA Service-Oriented Architecture)</span>
? SOA( 面向服務(wù)架構(gòu))，是一種開發(fā)思想 齿椅，是一種松耦合框架琉挖，不是一種具體的開發(fā)技術(shù)，讓軟件超越開發(fā)語(yǔ)言
SOA 要做什么媒咳？
1粹排、服務(wù)注冊(cè)中心种远，實(shí)現(xiàn)服務(wù)自動(dòng)注冊(cè)和發(fā)現(xiàn)涩澡，無(wú)需人為記錄服務(wù)地址
2、服務(wù)自動(dòng)訂閱坠敷，服務(wù)列表自動(dòng)推送妙同，服務(wù)調(diào)用透明化，無(wú)需關(guān)心依賴關(guān)系
3膝迎、動(dòng)態(tài)監(jiān)控服務(wù)狀態(tài)監(jiān)控報(bào)告粥帚，人為控制服務(wù)狀態(tài)
? SOA中有一個(gè)服務(wù)注冊(cè)中心，所有的服務(wù)都會(huì)在這里進(jìn)行注冊(cè)限次，表明自己提供了哪些服務(wù)芒涡。當(dāng)一個(gè)請(qǐng)求到來(lái)時(shí)，會(huì)先負(fù)載均衡卖漫，分流到某個(gè)具體的服務(wù)器费尽，服務(wù)器在調(diào)用后端服務(wù)的時(shí)候，會(huì)先去服務(wù)注冊(cè)中心獲取數(shù)據(jù)羊始，緩存到本地并查找服務(wù)地址旱幼，最后才是真正的遠(yuǎn)程服務(wù)調(diào)用（RPC SOA的具體實(shí)現(xiàn)方式）。
缺點(diǎn)：
服務(wù)間會(huì)有依賴關(guān)系突委，一旦某個(gè)環(huán)節(jié)出錯(cuò)會(huì)影響較大
服務(wù)關(guān)系復(fù)雜柏卤，運(yùn)維冬三、測(cè)試部署困難
<span style="font-size:14pt;">微服務(wù)架構(gòu)（MSA）</span>
Martin Fowler與James Lewis于2014年共同提出 微服務(wù)架構(gòu)思想 的文章—《Microservices》
? 簡(jiǎn)而言之，微服務(wù)架構(gòu)風(fēng)格是一種將單個(gè)應(yīng)用程序開發(fā)為一套小型服務(wù)的方法缘缚，每個(gè)小型服務(wù)都在自己的流程中運(yùn)行勾笆，并與輕量級(jí)機(jī)制（通常是HTTP資源API）進(jìn)行通信。這些服務(wù)圍繞業(yè)務(wù)功能構(gòu)建忙灼，可通過(guò)全自動(dòng)部署機(jī)制獨(dú)立部署匠襟。這些服務(wù)至少集中管理，可以用不同的編程語(yǔ)言編寫该园，并使用不同的數(shù)據(jù)存儲(chǔ)技術(shù)酸舍。 ——————— 來(lái)自google無(wú)責(zé)任翻譯
<center>
<span style="color: blue;font-size: 17pt" >
** 微服務(wù)就是一個(gè)輕量級(jí)的服務(wù)治理方案 **
</span>
<span style="color: blue; font-size: 17pt" >
** 是SOA思想的一種更加簡(jiǎn)單、輕便里初、敏捷的實(shí)現(xiàn) **
</span>
<span style="color: green; font-size: 14pt" >
** 微服務(wù)架構(gòu) = 80%的SOA服務(wù)架構(gòu)思想 + 100%的組件化架構(gòu)思想 + 80%的領(lǐng)域建模思想 **
</span>
</center>
微服務(wù)的特點(diǎn)
-
按照業(yè)務(wù)劃分成獨(dú)立運(yùn)行的程序啃勉，即服務(wù)單元
根絕Martin Fowler的定義，微服務(wù)的“微”是按照業(yè)務(wù)劃分双妨。傳統(tǒng)的軟件開發(fā)模式通常由UI團(tuán)隊(duì)淮阐、服務(wù)端團(tuán)隊(duì)數(shù)據(jù)庫(kù)團(tuán)隊(duì)和運(yùn)維團(tuán)隊(duì)構(gòu)成，并相應(yīng)的將軟件按照職能劃分為各個(gè)模塊刁品。通常開發(fā)人員都是各司其職泣特，很少能跨職能去工作。如果是按照業(yè)務(wù)來(lái)劃分服務(wù)挑随，每個(gè)服務(wù)都要獨(dú)立的UI状您、服務(wù)端、數(shù)據(jù)庫(kù)和運(yùn)維兜挨，所以就需要跨職能團(tuán)隊(duì)膏孟，一個(gè)團(tuán)隊(duì)負(fù)責(zé)一個(gè)服務(wù)的所有工作。當(dāng)這個(gè)負(fù)責(zé)這個(gè)服務(wù)的團(tuán)隊(duì)只有1~2人的時(shí)候拌汇，就對(duì)開發(fā)人員提出了更高的要求柒桑。
-
服務(wù)之間通過(guò)HTTP協(xié)議互相通信
微服務(wù)單元獨(dú)立部署，并運(yùn)行在各自的進(jìn)程中噪舀，微服務(wù)單元之間的通信方式一般傾向于使用HTTP這種簡(jiǎn)單的通訊機(jī)制魁淳，更多的時(shí)候是使用Restful API。不同服務(wù)可以采用不同語(yǔ)言与倡，部署在不同平臺(tái)界逛。
服務(wù)與服務(wù)之間也可以通過(guò)輕量級(jí)的消息總線來(lái)通信，例如RabbitMQ蒸走，Kafka等仇奶。通過(guò)發(fā)送消息或者訂閱消息來(lái)達(dá)到服務(wù)于服務(wù)之間的通信的目的。（弊端：會(huì)有失敗）
通信的數(shù)據(jù)格式：JSON该溯、XML岛抄、Protobuf (序列化后的二進(jìn)制數(shù)據(jù))
-
微服務(wù)的數(shù)據(jù)庫(kù)獨(dú)立
服務(wù)與服務(wù)之間是無(wú)耦合，數(shù)據(jù)庫(kù)也是獨(dú)立的狈茉。典型的微服務(wù)架構(gòu)就是每個(gè)微服務(wù)都有自己獨(dú)立的數(shù)據(jù)庫(kù)夫椭，數(shù)據(jù)庫(kù)之間沒有任何聯(lián)系。單個(gè)業(yè)務(wù)的數(shù)據(jù)量少氯庆，易于維護(hù)和遷移蹭秋。每個(gè)數(shù)據(jù)庫(kù)所使用的數(shù)據(jù)存儲(chǔ)技術(shù)可以根據(jù)業(yè)務(wù)需要來(lái)選擇。
- 自動(dòng)化部署
可以用不同的編程語(yǔ)言
可以用不同的存儲(chǔ)技術(shù)
服務(wù)集中化管理
微服務(wù)是一個(gè)分布式系統(tǒng)
微服務(wù)的優(yōu)點(diǎn)
優(yōu)點(diǎn)：
1堤撵、服務(wù)拆分粒度更細(xì)仁讨，有利于資源重復(fù)利用，提高開發(fā)效率实昨。
2洞豁、可以更加精準(zhǔn)的制定每個(gè)服務(wù)的優(yōu)化方案，提高系統(tǒng)可維護(hù)性荒给。
3丈挟、微服務(wù)架構(gòu)采用去中心化思想，服務(wù)之間采用RESTful等輕量協(xié)議通信志电，相比ESB更輕量曙咽。
4、適用于互聯(lián)網(wǎng)時(shí)代挑辆，產(chǎn)品迭代周期更短例朱。
微服務(wù)的設(shè)計(jì)原則
四個(gè)原則推薦給大家：
-
(1) AKF拆分原則
AKF擴(kuò)展立方體.jpeg
AKF擴(kuò)展立方體(參考《The Art of Scalability》)，是一個(gè)叫AKF的公司的技術(shù)專家抽象總結(jié)的應(yīng)用擴(kuò)展的三個(gè)維度之拨。理論上按照這三個(gè)擴(kuò)展模式茉继，可以將一個(gè)單體系統(tǒng)咧叭，進(jìn)行無(wú)限擴(kuò)展蚀乔。
X 軸 ：指的是水平復(fù)制，很好理解菲茬，就是講單體系統(tǒng)多運(yùn)行幾個(gè)實(shí)例吉挣，做個(gè)集群加負(fù)載均衡的模式。
Z 軸 ：是基于類似的數(shù)據(jù)分區(qū)婉弹，比如一個(gè)互聯(lián)網(wǎng)打車應(yīng)用突然或了睬魂，用戶量激增，集群模式撐不住了镀赌，那就按照用戶請(qǐng)求的地區(qū)進(jìn)行數(shù)據(jù)分區(qū)氯哮，北京、上海商佛、四川等多建幾個(gè)集群喉钢。
Y 軸 ：就是我們所說(shuō)的微服務(wù)的拆分模式姆打，就是基于不同的業(yè)務(wù)拆分。
-
(2) 前后端分離
前后端分離.jpeg
? 推薦的模式是最好直接采用物理分離的方式部署肠虽，進(jìn)一步促使進(jìn)行更徹底的分離幔戏。不要繼續(xù)以前的服務(wù)端模板技術(shù)，比如JSP 税课，把Java JS HTML CSS 都堆到一個(gè)頁(yè)面里闲延，稍復(fù)雜的頁(yè)面就無(wú)法維護(hù)。這種分離模式的方式有幾個(gè)好處：
- 前后端技術(shù)分離韩玩，可以由各自的專家來(lái)對(duì)各自的領(lǐng)域進(jìn)行優(yōu)化垒玲，這樣前端的用戶體驗(yàn)優(yōu)化效果會(huì)更好。
- 分離模式下找颓，前后端交互界面更加清晰侍匙，就剩下了接口和模型，后端的接口簡(jiǎn)潔明了叮雳，更容易維護(hù)想暗。
- 前端多渠道集成場(chǎng)景更容易實(shí)現(xiàn)，后端服務(wù)無(wú)需變更帘不，采用統(tǒng)一的數(shù)據(jù)和模型说莫，可以支撐前端的web UI\ 移動(dòng)App等訪問(wèn)。
-
(3) 無(wú)狀態(tài)服務(wù)
無(wú)狀態(tài)服務(wù).jpeg
對(duì)于無(wú)狀態(tài)服務(wù)寞焙，首先說(shuō)一下什么是狀態(tài)：如果一個(gè)數(shù)據(jù)需要被多個(gè)服務(wù)共享储狭，才能完成一筆交易，那么這個(gè)數(shù)據(jù)被稱為狀態(tài)捣郊。進(jìn)而依賴這個(gè)“狀態(tài)”數(shù)據(jù)的服務(wù)被稱為有狀態(tài)服務(wù)辽狈，反之稱為無(wú)狀態(tài)服務(wù)。
那么這個(gè)無(wú)狀態(tài)服務(wù)原則并不是說(shuō)在微服務(wù)架構(gòu)里就不允許存在狀態(tài)呛牲，表達(dá)的真實(shí)意思是要把有狀態(tài)的業(yè)務(wù)服務(wù)改變?yōu)闊o(wú)狀態(tài)的計(jì)算類服務(wù)刮萌，那么狀態(tài)數(shù)據(jù)也就相應(yīng)的遷移到對(duì)應(yīng)的“有狀態(tài)數(shù)據(jù)服務(wù)”中。
場(chǎng)景說(shuō)明：例如我們以前在本地內(nèi)存中建立的數(shù)據(jù)緩存娘扩、Session緩存着茸，到現(xiàn)在的微服務(wù)架構(gòu)中就應(yīng)該把這些數(shù)據(jù)遷移到分布式緩存中存儲(chǔ)，讓業(yè)務(wù)服務(wù)變成一個(gè)無(wú)狀態(tài)的計(jì)算節(jié)點(diǎn)琐旁。遷移后涮阔，就可以做到按需動(dòng)態(tài)伸縮，微服務(wù)應(yīng)用在運(yùn)行時(shí)動(dòng)態(tài)增刪節(jié)點(diǎn)灰殴，就不再需要考慮緩存數(shù)據(jù)如何同步的問(wèn)題敬特。
-
Restful通信風(fēng)格
RestFulAPI.jpeg
作為一個(gè)原則來(lái)講本來(lái)應(yīng)該是個(gè)“無(wú)狀態(tài)通信原則”，在這里我們直接推薦一個(gè)實(shí)踐優(yōu)選的Restful 通信風(fēng)格 ，因?yàn)樗泻芏嗪锰帲?/p>
- 無(wú)狀態(tài)協(xié)議HTTP伟阔，具備先天優(yōu)勢(shì)尸变，擴(kuò)展能力很強(qiáng)。例如需要安全加密是减俏，有現(xiàn)成的成熟方案HTTPS可用召烂。
- JSON 報(bào)文序列化，輕量簡(jiǎn)單娃承，人與機(jī)器均可讀奏夫，學(xué)習(xí)成本低，搜索引擎友好历筝。
- 語(yǔ)言無(wú)關(guān)酗昼，各大熱門語(yǔ)言都提供成熟的Restful API框架，相對(duì)其他的一些RPC框架生態(tài)更完善梳猪。
當(dāng)然在有些特殊業(yè)務(wù)場(chǎng)景下麻削，也需要采用其他的RPC框架，如Thrift春弥、Avro-rpc呛哟、Grpc。但絕大多數(shù)情況下Restful就足夠用了匿沛。
微服務(wù)應(yīng)用平臺(tái)的運(yùn)行視圖
微服務(wù)容器
微服務(wù)帶來(lái)的難題
- 微服務(wù)的復(fù)雜度
- 分布式事物
- 服務(wù)的劃分
- 服務(wù)的部署
1.2 第一代微服務(wù)架構(gòu)
[圖片上傳失敗...(image-f835a6-1551540278906)]
[圖片上傳失敗...(image-d62dd3-1551540278906)]
微服務(wù)工具包扫责，為開發(fā)者提供了在分布式系統(tǒng)的配置管理、
服務(wù)發(fā)現(xiàn)逃呼、斷路器鳖孤、智能路由、微代理抡笼、控制總線等開發(fā)工具包
Spring Cloud包含了多個(gè)子項(xiàng)目,比如：Spring Cloud Config苏揣、
Spring Cloud Netflix、Spring Cloud CloudFoundry推姻、
Spring Cloud AWS平匈、Spring Cloud Security、Spring Cloud Commons拾碌、
Spring Cloud Zookeeper吐葱、Spring Cloud CLI等項(xiàng)目
[圖片上傳失敗...(image-a0dcc7-1551540278906)]
這是一個(gè)完整的Spring Cloud生態(tài)簡(jiǎn)圖街望。
Spring Cloud是一個(gè)基于Spring Boot實(shí)現(xiàn)的微服務(wù)架構(gòu)開發(fā)工具校翔。它為微服務(wù)架構(gòu)中涉及的服務(wù)治理、斷路器灾前、負(fù)載均衡防症、配置管理、控制總線和集群狀態(tài)管理等操作提供了一種簡(jiǎn)單的開發(fā)方式。
1蔫敲、外部或者內(nèi)部的非Spring Cloud項(xiàng)目都統(tǒng)一通過(guò)API網(wǎng)關(guān)（Zuul）來(lái)訪問(wèn)內(nèi)部服務(wù)饲嗽。
2、網(wǎng)關(guān)接收到請(qǐng)求后奈嘿，從注冊(cè)中心（Eureka）獲取可用服務(wù)貌虾。
3、由Ribbon進(jìn)行均衡負(fù)載后裙犹，分發(fā)到后端的具體實(shí)例尽狠。
4、微服務(wù)之間通過(guò)Feign進(jìn)行通信處理業(yè)務(wù)叶圃。
5袄膏、Hystrix負(fù)責(zé)處理服務(wù)超時(shí)熔斷。
6掺冠、Turbine監(jiān)控服務(wù)間的調(diào)用和熔斷相關(guān)指標(biāo)沉馆。
(圖中沒有畫出配置中心，配置中心管理各微服務(wù)不同環(huán)境下的配置文件德崭。)
二斥黑、安全認(rèn)證
2.1 什么是認(rèn)證？
2.2 常見的認(rèn)證方案
三眉厨、微服務(wù)安全認(rèn)證方案
? 安全認(rèn)證方面心赶，我們基于Spring Security結(jié)合OAuth2再加上JWT (Json Web Token)做安全令牌，實(shí)現(xiàn)統(tǒng)一的安全認(rèn)證與鑒權(quán)缺猛，使得微服務(wù)之間能夠按需隔離和安全互通缨叫。后續(xù)在統(tǒng)一認(rèn)證和權(quán)限方面我們產(chǎn)品會(huì)陸續(xù)推出較完善并且擴(kuò)展性良好的微服務(wù)組件，可以作為微服務(wù)平臺(tái)的公共的認(rèn)證和鑒權(quán)服務(wù)荔燎。 再啰嗦一句耻姥，認(rèn)證鑒權(quán)一定是個(gè)公共的服務(wù)，而不是多個(gè)系統(tǒng)各自建設(shè)有咨。
3.1 Spring Boot Security
現(xiàn)在的好多項(xiàng)目都是基于APP移動(dòng)端以及前后端分離的項(xiàng)目琐簇，之前基于Session的前后端放到一起的項(xiàng)目已經(jīng)慢慢失寵并淡出我們視線，尤其是當(dāng)基于Spring Cloud的微服務(wù)架構(gòu)以及Vue座享、React單頁(yè)面應(yīng)用流行起來(lái)后婉商，情況更甚。為此基于前后端分離的項(xiàng)目用戶認(rèn)證也受到眾人關(guān)注的一個(gè)焦點(diǎn)渣叛，不同以往的基于Session用戶認(rèn)證丈秩，基于Token的用戶認(rèn)證是目前主流選擇方案(至于什么是Token認(rèn)證，網(wǎng)上有相關(guān)的資料淳衙，大家可以看看),而且基于Java的兩大認(rèn)證框架有Apache Shiro和Spring Security蘑秽，我在此就不討論孰優(yōu)孰劣的饺著，大家可自行百度看看，本文主要討論的是基于Spring Security的用戶認(rèn)證肠牲。
3.1.1 什么是Spring Boot Security
3.1.2 微服務(wù)案例展示
3.2 Spring Cloud OAuth2
3.2.1 什么是OAuth2幼衰？
3.2.2 OAuth2模型初探
3.3 Spring Security OAuth2 + JWT
3.3.1 什么是JWT？
3.3.2 微服務(wù)案例展示
3.4 Spring Security OAuth2 + JWT+Redis
3.4.1 什么是Redis缀雳？
3.4.2 微服務(wù)案例展示
四渡嚣、綜合案例展示
4.1 Spring Cloud 微服務(wù)架構(gòu)
4.2 使用Spring Cloud構(gòu)建微服務(wù)的綜合案例
附錄
1、資源鏈接
2肥印、參考文章
[1] 微服務(wù)的4個(gè)設(shè)計(jì)原則和19個(gè)解決方案 http://server.51cto.com/Micro-551054.htm
[2] 圖解分布式架構(gòu) https://www.cnblogs.com/dump/p/8125539.html
[3] 負(fù)載均衡基礎(chǔ)知識(shí) (https://www.cnblogs.com/danbing/p/7459224.html) https://www.cnblogs.com/danbing/p/7459224.html
[4] Martin Fowler提出微服務(wù) https://martinfowler.com/articles/microservices.html
[5] 引領(lǐng)新未來(lái)SOA服務(wù)框架严拒，未來(lái)發(fā)展的方向 https://blog.csdn.net/u011687186/article/details/52126212
[6] 什么是分布式系統(tǒng)，如何學(xué)習(xí)分布式系統(tǒng) https://www.cnblogs.com/xybaby/p/7787034.html
[7] Web Service學(xué)習(xí)https://www.cnblogs.com/xdp-gacl/p/4048937.html
[8] 什么是微服務(wù)架構(gòu)竖独？微服務(wù)架構(gòu)與SOA架構(gòu)區(qū)別 https://www.shsxt.com/it/java/1299.html
[9] 微服務(wù)數(shù)據(jù)管理（譯）：每個(gè)服務(wù)一個(gè)數(shù)據(jù)庫(kù)模式 http://www.reibang.com/p/cd726b32342e
[10] 微服務(wù)架構(gòu)下的數(shù)據(jù)一致性保證 https://www.cnblogs.com/duanxz/p/7866516.html
