timg.jpg

什么是微服務(wù)架構(gòu)

• 說(shuō)到微服務(wù)必須提到的兩個(gè)人馬丁福勒(Martin Flower)和克羅夫特(Adrian Cockcroft),馬丁福勒在2014年在他的博客上寫過(guò)一篇文章,介紹微服務(wù)架構(gòu)
• 微服務(wù)架構(gòu)的特點(diǎn)
  • 一組小的服務(wù)
    • 微服務(wù)架構(gòu)主張
  • 獨(dú)立的進(jìn)程
  • 輕量級(jí)通信
  • 基于業(yè)務(wù)能力
  • 獨(dú)立部署
  • 無(wú)集中式管理

架構(gòu)師如何權(quán)衡微服務(wù)的利弊

• 微服務(wù)利
  • 強(qiáng)模塊化邊界
  • 可獨(dú)立部署
  • 技術(shù)多樣性
• 微服務(wù)弊
  • 分布式復(fù)雜性
  • 最終一致性
  • 運(yùn)維復(fù)雜性
  • 測(cè)試復(fù)雜性

康威法則和微服務(wù)給架構(gòu)師怎樣的啟示康威法則:是一個(gè)叫康威的人在1967年提出來(lái)的;設(shè)計(jì)系統(tǒng)的組織掺涛，其產(chǎn)生的設(shè)計(jì)等同于組織之內(nèi)筑悴、組織之間的溝通結(jié)構(gòu)。

• 康威法則和微服務(wù)的關(guān)系
  • 一個(gè)公司隨著業(yè)務(wù)增加項(xiàng)目變大,需要多個(gè)團(tuán)隊(duì)協(xié)同工作,這時(shí)候如果項(xiàng)目還是一整塊的,那么項(xiàng)目和團(tuán)隊(duì)就是不匹配.多個(gè)團(tuán)多很多人在協(xié)同工作的時(shí)候溝通成本變高,協(xié)同效率變低;當(dāng)某個(gè)團(tuán)隊(duì)在自己的業(yè)務(wù)部分有改動(dòng)時(shí)需要其它團(tuán)隊(duì)配合,溝通成本是較高的,中間甚至?xí)霈F(xiàn)摩擦
  • 微服務(wù)解決了這個(gè)問(wèn)題,我們把單塊的應(yīng)用拆解出來(lái),拆分成多個(gè)微服務(wù),每個(gè)團(tuán)隊(duì)負(fù)責(zé)維護(hù)自己的服務(wù),相互之間互不干擾;這樣某個(gè)團(tuán)隊(duì)或個(gè)人負(fù)責(zé)的部分交付的時(shí)候變得更加方便,不需要其它團(tuán)隊(duì)協(xié)同.這樣多團(tuán)隊(duì)和多服務(wù)之間的聯(lián)系變得清晰緊密,它符合了康威法則,整體的研發(fā)效率和業(yè)務(wù)支持變得更高效

企業(yè)應(yīng)該在什么時(shí)候開(kāi)始考慮引入微服務(wù)

• 企業(yè)應(yīng)該在什么時(shí)間段引入微服務(wù)
  • 從生產(chǎn)力和項(xiàng)目復(fù)雜性來(lái)考慮,在開(kāi)始項(xiàng)目的時(shí)候業(yè)務(wù)復(fù)雜性不高,用戶量也不大,這時(shí)候我們應(yīng)該優(yōu)先考慮單塊應(yīng)用,不推薦微服務(wù),因?yàn)槲⒎?wù)是有基礎(chǔ)設(shè)施要求的,需要前期的投資,團(tuán)隊(duì)不大生成力也會(huì)降低;而隨著項(xiàng)目越來(lái)越成功,用戶量的增加,系統(tǒng)的復(fù)雜性也變高,這時(shí)候團(tuán)隊(duì)變得越來(lái)越大,就會(huì)出現(xiàn)團(tuán)隊(duì)規(guī)模與項(xiàng)目不匹配的情況,違反康威法則,生產(chǎn)力隨著系統(tǒng)復(fù)雜性逐漸下降,這時(shí)候就該考慮引入微服務(wù)
• 項(xiàng)目架構(gòu)設(shè)計(jì)一開(kāi)始就設(shè)計(jì)微服務(wù),還是做單塊應(yīng)用
  • 單塊優(yōu)先,項(xiàng)目一開(kāi)始,你對(duì)項(xiàng)目問(wèn)題不是很理解,跟難把控怎么來(lái)拆分服務(wù),劃分服務(wù)的邊界,而且還未被客戶驗(yàn)證,可能會(huì)失敗;我們先做單塊應(yīng)用,隨著業(yè)務(wù)不斷擴(kuò)展,團(tuán)隊(duì)規(guī)模不斷擴(kuò)展,你的項(xiàng)目業(yè)務(wù)架構(gòu)越來(lái)越清晰,單塊應(yīng)用已經(jīng)無(wú)法滿足需求,研發(fā)效率開(kāi)始下降,達(dá)到一個(gè)臨界點(diǎn),發(fā)現(xiàn)我們需要把某些個(gè)業(yè)務(wù)模塊拆分出來(lái),這樣就慢慢變成一個(gè)微服務(wù)架構(gòu)
• 好的架構(gòu)是設(shè)計(jì)出來(lái)的還是演化出來(lái)的
  • 系統(tǒng)架構(gòu)的目標(biāo)是解決利益相關(guān)者的關(guān)注點(diǎn)煤惩。架構(gòu)系統(tǒng)前架構(gòu)師的首要任務(wù)是盡最大可能找出所有利益相關(guān)者;架構(gòu)師常犯的錯(cuò)誤就是漏掉利益相關(guān)者,溝通不充分,都會(huì)造成架構(gòu)有欠缺,不能滿足相關(guān)利益者的需求师倔。架構(gòu)是對(duì)一個(gè)系統(tǒng)起關(guān)鍵作用的設(shè)計(jì)決策毁涉，架構(gòu)定系統(tǒng)就基本成型了联贩。進(jìn)一步說(shuō)愿险，架構(gòu)的目標(biāo)是用于管理復(fù)雜性、易變性和不確定性漾脂，以確保在長(zhǎng)期的系統(tǒng)演化過(guò)程中假颇，一部分的架構(gòu)變化不會(huì)對(duì)其它部分產(chǎn)生不必要的負(fù)面影響。這樣做可以確保業(yè)務(wù)和研發(fā)效率的敏捷骨稿，讓應(yīng)用的易變部分能夠頻繁的變化笨鸡，對(duì)應(yīng)于其它部分的影響盡可能的少。業(yè)務(wù)架構(gòu)是生產(chǎn)力坦冠，應(yīng)用架構(gòu)是生產(chǎn)關(guān)系形耗，技術(shù)架構(gòu)是生產(chǎn)工具。業(yè)務(wù)架構(gòu)決定應(yīng)用架構(gòu)辙浑，應(yīng)用架構(gòu)需要適配業(yè)務(wù)架構(gòu)激涤，并隨著業(yè)務(wù)架構(gòu)不斷進(jìn)化，同時(shí)應(yīng)用架構(gòu)依托技術(shù)架構(gòu)最終落地判呕。
  • 好架構(gòu)是進(jìn)化來(lái)的不是設(shè)計(jì)來(lái)的倦踢；我們?cè)诿總€(gè)階段，找到對(duì)應(yīng)該階段網(wǎng)站架構(gòu)所面臨的問(wèn)題侠草，然后在不斷解決這些問(wèn)題的過(guò)程中辱挥，整個(gè)戰(zhàn)略的架構(gòu)就是在不斷的演進(jìn)了。網(wǎng)站在不同的階段遇到的問(wèn)題不一樣边涕，而解決這些問(wèn)題使用的技術(shù)也不一樣晤碘，流量小的時(shí)候，我們主要目的是提高開(kāi)發(fā)效率功蜓，在早期要引入 ORM园爷，DAO 這些技術(shù)。隨著流量變大式撼，使用動(dòng)靜分離童社、讀寫分離、主從同步端衰、垂直拆分叠洗、CDN、MVC 等方式不斷提升網(wǎng)站的穩(wěn)定性旅东。面對(duì)更大的流量時(shí)，通過(guò)垂直拆分十艾、服務(wù)化抵代、反向代理、開(kāi)發(fā)框架（站點(diǎn)/服務(wù)）等等忘嫉，不斷提升高可用荤牍。
  • 一個(gè)優(yōu)秀的架構(gòu)不可能一下就設(shè)計(jì)出來(lái)案腺，是需要不斷進(jìn)化的，當(dāng)然精心的設(shè)計(jì)也是必不可少的康吵；好的架構(gòu)需要經(jīng)過(guò)這么幾個(gè)過(guò)程：精心設(shè)計(jì) – 進(jìn)化 – 進(jìn)化 …… – 被推翻 – 再設(shè)計(jì)劈榨，是這樣循環(huán)往復(fù)的過(guò)程。最開(kāi)始的架構(gòu)晦嵌，肯定是從無(wú)到有同辣，根據(jù)產(chǎn)品的需求和當(dāng)時(shí)業(yè)務(wù)的需求設(shè)計(jì)出來(lái)的。一個(gè)系統(tǒng)的演化惭载，一般會(huì)經(jīng)過(guò)這樣的階段：第一個(gè)系統(tǒng)肯定是under-engineer的旱函，從無(wú)到有被設(shè)計(jì)出來(lái)后，肯定是不完善的描滔；第二個(gè)版本棒妨，一般是over-engineer的，因?yàn)殡S著之前那個(gè)版本的使用含长，積累了一定量需求后券腔，會(huì)發(fā)現(xiàn)想要增加很多內(nèi)容在上面；到第三個(gè)版本拘泞，應(yīng)該是最恰當(dāng)?shù)穆簦瑴p去了一些沒(méi)必要的設(shè)計(jì)之后，更合適田弥。但當(dāng)?shù)搅四骋粋€(gè)時(shí)間點(diǎn)涛酗，發(fā)現(xiàn)現(xiàn)有的系統(tǒng)架構(gòu)已經(jīng)沒(méi)有辦法再維持下去，跟不上需求增長(zhǎng)時(shí)偷厦，就需要推倒再重新設(shè)計(jì)商叹。

什么樣的組織架構(gòu)更適合微服務(wù)

• 傳統(tǒng)技術(shù)團(tuán)隊(duì)
  • 產(chǎn)品管理專家團(tuán)隊(duì)、用戶體驗(yàn)專家團(tuán)隊(duì)只泼、研發(fā)專家團(tuán)隊(duì)剖笙、測(cè)試專家團(tuán)隊(duì)、DBA專家團(tuán)隊(duì)请唱、運(yùn)維專家團(tuán)隊(duì)
• 新型微服務(wù)團(tuán)隊(duì)
  • 跨職能微服務(wù)團(tuán)隊(duì)-API-平臺(tái)團(tuán)隊(duì)
    • 微服務(wù)整個(gè)團(tuán)隊(duì)圍繞產(chǎn)品做決定弥咪，團(tuán)隊(duì)內(nèi)部的人同時(shí)負(fù)責(zé)：架構(gòu)、設(shè)計(jì)十绑、開(kāi)發(fā)聚至、評(píng)審、測(cè)試本橙、發(fā)布扳躬、運(yùn)行、支持，形成閉環(huán)贷币；團(tuán)隊(duì)規(guī)模一般十幾個(gè)人击胜；誰(shuí)開(kāi)發(fā)誰(shuí)構(gòu)建誰(shuí)運(yùn)行發(fā)布

如何理解阿里巴巴提出的微服務(wù)中臺(tái)戰(zhàn)略

• 大中臺(tái)，小前臺(tái)：馬云在2015年參觀完歐洲一家技術(shù)公司有此感悟役纹，提出了中臺(tái)戰(zhàn)略
• 互聯(lián)網(wǎng)公司組織架構(gòu)
  • Iaas云平臺(tái)(基礎(chǔ)設(shè)施及服務(wù))
    • 計(jì)算偶摔、存儲(chǔ)、網(wǎng)絡(luò)促脉、監(jiān)控辰斋、安全、IDC
  • Pass云平臺(tái)
    • 大數(shù)據(jù)嘲叔、AI亡呵；應(yīng)用監(jiān)控、持續(xù)交付硫戈、服務(wù)框架锰什、資源調(diào)度、后臺(tái)服務(wù)
  • 核心業(yè)務(wù)層(領(lǐng)域核心服務(wù))
  • 應(yīng)用層
    • 主站丁逝、app汁胆；第三方接入渠道
• 技術(shù)中臺(tái)和業(yè)務(wù)中臺(tái)是大中臺(tái),當(dāng)中臺(tái)比較完善,它對(duì)上層應(yīng)用的支撐能力就越強(qiáng),使前臺(tái)更加靈活,快速響應(yīng)市場(chǎng)需求

如何給出一個(gè)清晰簡(jiǎn)潔的微服務(wù)分層方式

• 基礎(chǔ)服務(wù):別名-核心領(lǐng)域服務(wù)\公共服務(wù)\中間服務(wù)
• 聚合服務(wù):別名-適配服務(wù)\邊界服務(wù)——>webBFF、MobileBFF霜幼、publicBFF

微服務(wù)總體技術(shù)架構(gòu)體系是怎樣設(shè)計(jì)的

• 接入層：外部+內(nèi)部
• 網(wǎng)關(guān)層：內(nèi)部網(wǎng)關(guān)嫩码、H5網(wǎng)關(guān)、無(wú)線網(wǎng)關(guān)罪既、第三方網(wǎng)關(guān)铸题、平臺(tái)開(kāi)放網(wǎng)關(guān)
  • 網(wǎng)關(guān)層在微服務(wù)有重要地位，它主要做反向路由琢感、限流熔斷丢间、安全...
• 業(yè)務(wù)服務(wù)層:聚合層、基礎(chǔ)層
• 支撐服務(wù)：注冊(cè)發(fā)現(xiàn)驹针、集中配置烘挫、容錯(cuò)限流、認(rèn)證授權(quán)柬甥、日志集合饮六、監(jiān)控警告、后臺(tái)服務(wù)
• 平臺(tái)服務(wù)：發(fā)布系統(tǒng)苛蒲、集群資源調(diào)度卤橄、鏡像治理、資源治理撤防、IAM
• 基礎(chǔ)設(shè)施：計(jì)算虽风、網(wǎng)絡(luò)棒口、存儲(chǔ)寄月、NOC監(jiān)控辜膝、安全、IDC
• 縱向能力：微服務(wù)開(kāi)發(fā)框架漾肮、持續(xù)交付流水線厂抖、端到端的工具鏈、工程實(shí)踐與規(guī)范

微服務(wù)最經(jīng)典的三種服務(wù)發(fā)現(xiàn)機(jī)制

• 在一個(gè)分布式架構(gòu)中有很多服務(wù)克懊，這些服務(wù)中有生成者有消費(fèi)者忱辅，這些消費(fèi)者如何去發(fā)現(xiàn)生成者，這就需要微服務(wù)的服務(wù)發(fā)現(xiàn)
• 傳統(tǒng)Load Balancer做服務(wù)發(fā)現(xiàn)和負(fù)載均衡
  • DNS->Consumer->Load Balancer->Service provider
  • 申請(qǐng)DNS域名谭溉、配負(fù)載均衡器墙懂、域名指向后臺(tái)服務(wù)
• 進(jìn)程內(nèi)Load模式發(fā)現(xiàn)服務(wù)
  • service Register->Consumer(Load Balancer)->Service Provider(定期發(fā)送心跳)->service Register：性能好，升級(jí)成本高
• 主心獨(dú)立Load模式
  • 和進(jìn)程內(nèi)load模式類似扮念，只不過(guò)是在每臺(tái)消費(fèi)者主機(jī)上部署Load Balancer损搬；應(yīng)用成本較高
• 服務(wù)網(wǎng)格：服務(wù)網(wǎng)格是用于控制和監(jiān)控微服務(wù)應(yīng)用程序中的內(nèi)部服務(wù)到服務(wù)流量的軟件基礎(chǔ)結(jié)構(gòu)層。它通常采取與應(yīng)用程序代碼一起部署柜与，作為網(wǎng)絡(luò)代理的 "數(shù)據(jù)平面" 和與這些代理交互的 "控制平面" 的形式巧勤。在此模型中，服務(wù)網(wǎng)格對(duì)于開(kāi)發(fā)人員 (服務(wù)所有者) 是透明的弄匕， 而運(yùn)維人員 (平臺(tái)工程師) 則被授予一套新的工具颅悉，以確保可靠性迁匠、安全性和可見(jiàn)性剩瓶。

微服務(wù)api服務(wù)網(wǎng)關(guān)原理與開(kāi)源網(wǎng)關(guān)

• 網(wǎng)關(guān)就相當(dāng)于一個(gè)門衛(wèi)，外部不同的業(yè)務(wù)調(diào)用不同的微服務(wù)功能時(shí)城丧，我們不希望外部看到微服務(wù)細(xì)節(jié)延曙，通過(guò)網(wǎng)關(guān)使外界看起來(lái)是一個(gè)統(tǒng)一的服務(wù)
• 外部接入設(shè)備->負(fù)載均衡器->網(wǎng)關(guān)層->微服務(wù)
  • 網(wǎng)關(guān)功能
    • 反向路由：將外部請(qǐng)求轉(zhuǎn)換為內(nèi)部的對(duì)應(yīng)微服務(wù)調(diào)用
    • 認(rèn)證安全：對(duì)請(qǐng)求進(jìn)來(lái)的信息進(jìn)行安全認(rèn)證
    • 限流熔斷：有突發(fā)的大流量沖進(jìn)來(lái)時(shí)限流熔斷避免服務(wù)器承受不了而癱瘓
    • 日志監(jiān)控:對(duì)訪問(wèn)進(jìn)行記錄保存起來(lái)，可以進(jìn)行分析監(jiān)控
• 開(kāi)源網(wǎng)關(guān)zuul
  • zuul網(wǎng)關(guān)核心sevlet
  • zuul網(wǎng)關(guān)核心組件zuul Runner：Zuul Runner管理內(nèi)部過(guò)濾器
    • Pre Routing filters(前置路由過(guò)濾器)：這里可以加自己定制的過(guò)濾器芙贫，通過(guò)Http Request調(diào)用
    • Routing Filters(路由過(guò)濾器)：調(diào)用后臺(tái)微服務(wù)
    • Post Routing Filters(后置路由過(guò)濾器)：這里設(shè)置error filters搂鲫，任何環(huán)節(jié)報(bào)錯(cuò)，拋給錯(cuò)誤過(guò)濾器處理磺平；通過(guò)HttpResponse返回魂仍，可以做統(tǒng)計(jì)監(jiān)控的功能
  • zuul中的過(guò)濾器是動(dòng)態(tài)插拔的，有靈活的過(guò)濾器上傳加載機(jī)制拣挪，zuul網(wǎng)關(guān)通過(guò)Request Context共享信息
    • 開(kāi)發(fā)完過(guò)濾器可以上傳到過(guò)濾器存儲(chǔ)數(shù)據(jù)庫(kù)中擦酌，后臺(tái)有一個(gè)過(guò)濾器Poller，定期從數(shù)據(jù)庫(kù)pull過(guò)濾器上傳到過(guò)濾器目錄當(dāng)中菠劝，網(wǎng)關(guān)上的過(guò)濾器管理器定期掃目錄赊舶，有新的過(guò)濾器會(huì)加載到網(wǎng)關(guān)中

跟Netfix學(xué)習(xí)微服務(wù)路由發(fā)現(xiàn)體系

• 服務(wù)注冊(cè)中心Eureka:注冊(cè)中心，進(jìn)行服務(wù)治理，哪些服務(wù)可以隨便調(diào)用笼平，哪些服務(wù)通過(guò)網(wǎng)關(guān)訪問(wèn)
  • zuul核心組件：服務(wù)發(fā)現(xiàn)
  • 基礎(chǔ)服務(wù)：服務(wù)注冊(cè)
  • 聚合服務(wù)：服務(wù)注冊(cè)园骆、服務(wù)發(fā)現(xiàn)

集中式配置中心的作用和原理是什么

• 為什么需要引入配置中心
  • 開(kāi)發(fā)人員一般都把配置放在配置文件中，各自有各自的做法寓调，這樣格式不標(biāo)準(zhǔn)锌唾，不統(tǒng)一，有很多隱患夺英；上線后修改不方便晌涕；沒(méi)有完整的配置系統(tǒng)，誰(shuí)修改了配置痛悯，無(wú)法追溯余黎。
• 哪些可以在配置中心進(jìn)行配置
  • 連接字符串-消息隊(duì)列連接字符串-緩存連接字符串、動(dòng)態(tài)調(diào)整參數(shù)-客戶端超時(shí)設(shè)置-限流閾值载萌、業(yè)務(wù)開(kāi)關(guān)-某服務(wù)只對(duì)某個(gè)地區(qū)生效-某共能只在大促時(shí)開(kāi)放
• 配置中心原理
  • 用戶通過(guò)一個(gè)界面修改配置惧财，不同的微服務(wù)可以從配置中心更新配置(手動(dòng)拉或自動(dòng)推)
• 協(xié)程Apollo配置中心

微服務(wù)通訊方式RPC vs REST

微服務(wù)框架需要考慮哪些治理環(huán)節(jié)

• 后臺(tái)服務(wù)集成：數(shù)據(jù)訪問(wèn)服務(wù)澄步、緩存服務(wù)、消息服務(wù)
• 服務(wù)注冊(cè)發(fā)現(xiàn)：消費(fèi)者如何發(fā)現(xiàn)服務(wù)
• 負(fù)載軟路由：應(yīng)對(duì)大流量的負(fù)載均衡和泌，灰度發(fā)布需要軟路由能力
• 日志：日志對(duì)于后期排錯(cuò)找問(wèn)題很重要
• Metrics：對(duì)服務(wù)的調(diào)用量村缸、延遲、出錯(cuò)數(shù)進(jìn)行監(jiān)控
• 調(diào)用鏈埋點(diǎn)：調(diào)用鏈監(jiān)控幫助開(kāi)發(fā)人員快速定位問(wèn)題
• 限流熔斷：避免某個(gè)服務(wù)出現(xiàn)故障或延遲時(shí)整個(gè)系統(tǒng)的癱瘓
• 安全訪問(wèn)控制：有些服務(wù)涉及敏感信息的需要有安全策略武氓，黑名單梯皿、訪問(wèn)控制策略來(lái)限制對(duì)這些服務(wù)的訪問(wèn)
• REST/PRC：好的框架同時(shí)支持兩種通訊方式的調(diào)用仇箱，不同場(chǎng)景使用不同通訊方式
• 序列化XML/JSON/二進(jìn)制：靈活配置消息序列化協(xié)議
• 代碼生成：大規(guī)模開(kāi)發(fā)時(shí)，推崇契約驅(qū)動(dòng)的開(kāi)發(fā)方法东羹，先定義契約剂桥，然后代碼生成自動(dòng)生成服務(wù)器端和客戶端，生成的代碼比較規(guī)整
• 統(tǒng)一異常處理：異常處理的統(tǒng)一標(biāo)準(zhǔn)化
• 文檔：好的文檔體系幫助開(kāi)發(fā)人員更好的利用微服務(wù)
• 配置集成：配置中心靈活調(diào)整配置

微服務(wù)監(jiān)控系統(tǒng)分層和監(jiān)控架構(gòu)

• 端用戶體驗(yàn)監(jiān)控
  • 性能百姓、返回碼渊额、城市地區(qū)况木、運(yùn)營(yíng)商垒拢、版本系統(tǒng)等
• 業(yè)務(wù)監(jiān)控
  • 核心指標(biāo)監(jiān)控、登錄注冊(cè)火惊、下單求类、支付等
• 應(yīng)用監(jiān)控
  • url、service屹耐、sql尸疆、cache可用率、響應(yīng)時(shí)間惶岭、qps等
• 系統(tǒng)監(jiān)控
  • 物理機(jī)寿弱、虛擬機(jī)、os：CPU按灶、memory症革、network、disk等
• 基礎(chǔ)設(shè)施監(jiān)控
  • 網(wǎng)絡(luò)鸯旁、交換機(jī)噪矛、網(wǎng)絡(luò)流量、丟包铺罢、錯(cuò)包艇挨、連接數(shù)等
• 監(jiān)控哪些方面
  • 日志監(jiān)控、Metrics監(jiān)控韭赘、健康檢查缩滨、調(diào)用鏈監(jiān)控、告警系統(tǒng)

微服務(wù)的調(diào)用鏈監(jiān)控該如何選型

微服務(wù)的容錯(cuò)限流是如何工作的

Hystrix的熔斷：

• 分布式系統(tǒng)中常見(jiàn)的容錯(cuò)模式：熔斷贼陶、隔離刃泡、限流巧娱、降級(jí)
• Hystrix內(nèi)部設(shè)計(jì)和調(diào)用流程：
  • 調(diào)用請(qǐng)求：同步調(diào)用、異步調(diào)用烘贴、響應(yīng)式調(diào)用
  • 電路判斷：如果電路是打開(kāi)的(不通了)禁添，直接導(dǎo)入->getFallback(),如果提供了降級(jí)函數(shù)直接調(diào)用->返回，也可能拋出異常桨踪，這是短路流程老翘；如果電路是閉合的(通的，沒(méi)有熔斷)->看線程是否ok锻离，隊(duì)列資源是否滿了(是會(huì)去降級(jí)請(qǐng)求)->運(yùn)行調(diào)用(運(yùn)行超時(shí)铺峭，去降級(jí))->調(diào)用成功(失敗去調(diào)用降級(jí))->獲取正確的響應(yīng)->返回到請(qǐng)求方；運(yùn)行是否成功汽纠，調(diào)用是否超時(shí)都會(huì)以message形式反饋給內(nèi)部計(jì)算電路健康的組件卫键，反饋給內(nèi)部熔斷器，從而決定下次電路的開(kāi)啟關(guān)閉

Docker容器部署技術(shù)&持續(xù)交付流水線

• docker容器技術(shù)解決的問(wèn)題和帶來(lái)的好處
  • 環(huán)境一致性：容器技術(shù)把依賴包全部打包在容器鏡像中虱朵，不存在依賴不一致問(wèn)題
  • 鏡像部署：它把構(gòu)建和發(fā)布隔離莉炉，提供抽象發(fā)布機(jī)制；鏡像當(dāng)中有操作系統(tǒng)碴犬、依賴包絮宁、微服務(wù)應(yīng)用程序
• 交付流水線：Jenkins-鏡像治理中心(測(cè)試環(huán)境-UAT環(huán)境-生成環(huán)境);在生產(chǎn)環(huán)境發(fā)布比較嚴(yán)格，可以采用藍(lán)綠發(fā)布和灰度發(fā)布機(jī)制
  • 藍(lán)綠部署原理：我們有藍(lán)色版本和綠色版本服协，依賴于路由器(網(wǎng)關(guān)或內(nèi)部服務(wù)發(fā)現(xiàn)系統(tǒng))绍昂；當(dāng)升級(jí)時(shí)切換到綠色版本；
  • 灰度發(fā)布就是我們不一下子把流量全部切換到綠色版本蚯涮，而是先切換10%看運(yùn)行情況治专，有問(wèn)題切換回來(lái)，沒(méi)問(wèn)題再切50%遭顶，然后逐步切換

容器集群調(diào)度和基于容器的發(fā)布體系

• 容器資源調(diào)度平臺(tái)Mesos：他會(huì)幫你管理,這個(gè)計(jì)算機(jī)有足夠多計(jì)算資源和內(nèi)存資源,看上去是個(gè)超級(jí)的操作系統(tǒng),管理下面张峰；master負(fù)責(zé)管理可以運(yùn)行容器物理機(jī)虛擬機(jī)的slave機(jī)器，上面有zookeeper來(lái)幫助他,有個(gè)leader來(lái)管理slave,leader出問(wèn)題,zookeeper會(huì)選舉一個(gè)slave是不同的機(jī)器,把自己的使用情況,內(nèi)存情況等等匯報(bào)給master,master把這些信息報(bào)告Framework,master只管資源的調(diào)度

• 容器發(fā)布體系：
  微信截圖_20191008074041.png

微信圖片_20191007223334.jpg