改變思維的角度：故障無(wú)處不在

? ??? 當(dāng)微服務(wù)規(guī)模化后，故障是無(wú)可避免的，以往我們總是想盡力避免故障的發(fā)生，而當(dāng)故障實(shí)際發(fā)生時(shí)，我們往往束手無(wú)策。我們花了很多時(shí)間在流程設(shè)計(jì)和應(yīng)用設(shè)計(jì)的層面上來(lái)阻止故障的發(fā)生，但實(shí)際上很少花費(fèi)時(shí)間思考如何第一時(shí)間從故障中恢復(fù)過(guò)來(lái)。

? ? ? 一些公司喜歡組織活動(dòng)，活動(dòng)當(dāng)天系統(tǒng)會(huì)被關(guān)掉以模擬故障發(fā)生，然后不同團(tuán)隊(duì)演練如何應(yīng)對(duì)這種情況。這些項(xiàng)目中最著名的是混亂猴子（Chaos Monkey），在一天的特定時(shí)間隨機(jī)停掉服務(wù)器，這促使開(kāi)發(fā)人員在構(gòu)建系統(tǒng)時(shí)不得不為它做好準(zhǔn)備。猴子軍隊(duì)可以在系統(tǒng)中注入網(wǎng)絡(luò)延遲，也可以隨機(jī)關(guān)閉整個(gè)可用區(qū)，這可以讓你的系統(tǒng)得到終極驗(yàn)證。SimianArmy就是這樣的一個(gè)項(xiàng)目。

? ? ? 通過(guò)讓軟件擁抱和引發(fā)故障，并構(gòu)建系統(tǒng)來(lái)應(yīng)對(duì)。

?

了解什么指標(biāo)是我們必須關(guān)注的

? ? ??企業(yè)Wiki一個(gè)月發(fā)生故障兩天，我們認(rèn)為是可以接受的，電商網(wǎng)站一天停一個(gè)小時(shí)也是不可接受的。我們需要正確地理解這些需求，以便采取合適的技術(shù)。

? ? ? 我們建議有一些默認(rèn)的指標(biāo)必須予以關(guān)注。

? ??? 1.響應(yīng)時(shí)間/延遲

? ? ? 鑒于網(wǎng)絡(luò)的性質(zhì)，你經(jīng)常會(huì)遇到異常值，所以將監(jiān)控的響應(yīng)目標(biāo)設(shè)置成一個(gè)百分比是合理的。

? ? ? 舉例：我期望這個(gè)網(wǎng)站，當(dāng)每秒處理200個(gè)并發(fā)連接時(shí)，90%的響應(yīng)時(shí)間在2秒以內(nèi)。

? ? ??2.可用性

? ? ? 評(píng)價(jià)可用性，我們可以從歷史報(bào)告來(lái)分析，以跟我們的期望值相對(duì)比。

? ? ??3.數(shù)據(jù)持久性

? ? ? 用戶的登錄會(huì)話只需要保持一年，金融交易記錄則需要保存很多年。

?

一.從體驗(yàn)上來(lái)解決：功能降級(jí)

? ? ??當(dāng)購(gòu)物車功能不可用時(shí)，你可以隱藏掉這個(gè)圖標(biāo)，并提示“馬上”，或者變成一個(gè)可下單的電話號(hào)碼。

? ? ? 對(duì)于每個(gè)使用多個(gè)微服務(wù)的面向用戶的界面，或每個(gè)依賴多個(gè)下游合作者的微服務(wù)來(lái)說(shuō)，你都需要問(wèn)自己“如果這個(gè)微服務(wù)宕掉會(huì)發(fā)生什么”，然后你就知道該如何做了。

?

二.從請(qǐng)求/響應(yīng)上來(lái)解決

? ??? 1.超時(shí)機(jī)制

? ? ? 給所有的跨進(jìn)程調(diào)用設(shè)置超時(shí)，當(dāng)發(fā)生超時(shí)時(shí)記錄到日志中，并相應(yīng)地調(diào)他們。

? ? ??2.斷路器

? ? ? 當(dāng)對(duì)下游的請(qǐng)求發(fā)生一定數(shù)量的失敗后，斷路器會(huì)打開(kāi)，接下來(lái)，所有的請(qǐng)求在斷路器打開(kāi)的情況下會(huì)快速地失敗，一段時(shí)間后，客戶端發(fā)送一些請(qǐng)求查看下游服務(wù)是否已經(jīng)恢復(fù)，如果它得到了正常的響應(yīng)，將重置斷路器。

使用斷路器，我們可以在請(qǐng)求失敗后把這些請(qǐng)求存起來(lái)，然后稍后重試它們，也可以直接使用功能降級(jí)。Hystrix就是一個(gè)基于JVM的開(kāi)源斷路器。

? ? ??3.艙壁

這是一種把自己從故障中隔離開(kāi)的方式，如果我們使用下游多個(gè)服務(wù)，而其中一個(gè)服務(wù)占用了過(guò)多的連接池，由于是共用連接池，這勢(shì)必會(huì)對(duì)其他的服務(wù)調(diào)用造成影響，艙壁的處理辦法，即是為每個(gè)下游服務(wù)建立一個(gè)單獨(dú)的連接池，我們當(dāng)然也可以跟斷路器聯(lián)合起來(lái)使用。

? ? ? 在很多方面，艙壁是三個(gè)模式中最重要的，超時(shí)和斷路器能夠幫助你在資源受限時(shí)釋放它們，但艙壁可以在第一時(shí)間確保它們不成為限制，它可以拒絕請(qǐng)求以避免資源達(dá)到飽和。

?

三.從服務(wù)依賴性上解決：隔離

? ??? 一個(gè)服務(wù)依賴于另一個(gè)服務(wù)，另一個(gè)服務(wù)的健康將能影響其正常工作的能力，如果我們使用的集成技術(shù)允許下游服務(wù)器離線，上游服務(wù)便不太可能受到計(jì)劃內(nèi)或計(jì)劃外宕機(jī)的影響。

? ? ? Jekins的master/slave即是這樣的解決思路。

?

四.從處理結(jié)果上解決：冪等

? ??? 對(duì)冪等操作而言，多次執(zhí)行所產(chǎn)生的影響均與一次執(zhí)行的同，如果操作是冪等的，我們可以對(duì)其重復(fù)多閃調(diào)用，而不必?fù)?dān)任會(huì)有不利影響。當(dāng)我們不確定否被執(zhí)行，想要重新處理消息，從而從錯(cuò)誤中恢復(fù)時(shí)，冪等會(huì)非常有用。

?

五.從應(yīng)用上解決：擴(kuò)展應(yīng)用

? ??? 更強(qiáng)大的主機(jī)、一臺(tái)主機(jī)一個(gè)微服務(wù)、關(guān)鍵業(yè)務(wù)彈性部署、多云服務(wù)數(shù)據(jù)商備份、異地災(zāi)備、負(fù)載均衡、重構(gòu)系統(tǒng)、作業(yè)隊(duì)列。

?

六.從數(shù)據(jù)庫(kù)上解決：擴(kuò)展數(shù)據(jù)庫(kù)

? ????方法1：主從復(fù)制

? ? ? 當(dāng)主數(shù)據(jù)庫(kù)出現(xiàn)故障，可以馬上啟動(dòng)備份數(shù)據(jù)庫(kù)，并提升至主數(shù)據(jù)庫(kù)。

? ? ??方法2：讀寫分離——擴(kuò)展讀操作

? ? ? 讀操作使用的數(shù)據(jù)庫(kù)和寫操作使用的數(shù)據(jù)庫(kù)分開(kāi)，但這會(huì)造成數(shù)據(jù)暫時(shí)不一致的情況。

? ? ??方法3：讀寫分離——擴(kuò)展寫操作

? ? ? 可以使用分片的方式來(lái)擴(kuò)展寫操作，當(dāng)你有一塊數(shù)據(jù)要寫入時(shí)，對(duì)數(shù)據(jù)的關(guān)鍵字應(yīng)用一個(gè)哈希函數(shù)，并基于這個(gè)函數(shù)的結(jié)果將數(shù)據(jù)發(fā)送到哪個(gè)分片。

? ? ? 但分片擴(kuò)展會(huì)導(dǎo)致在查詢上復(fù)雜起來(lái)，如果要查詢所有年滿18歲的顧客，那么要查詢所有分片，然后在內(nèi)存中拼起來(lái)；或者有一個(gè)替代的讀數(shù)據(jù)訓(xùn)包含所有的數(shù)據(jù)集。

? ? ? 分片擴(kuò)展的另一個(gè)問(wèn)題是，如果想添加新的數(shù)據(jù)庫(kù)節(jié)點(diǎn)，我們需要大量的宕機(jī)時(shí)間然后重新分配數(shù)據(jù)

? ? ??方法4：CQRS——命令查詢職責(zé)分離

? ? ? 在傳統(tǒng)的系統(tǒng)中，數(shù)據(jù)的修改和查詢使用的是同一個(gè)系統(tǒng)，使用CQRS后，系統(tǒng)的一部分負(fù)責(zé)獲取修改狀態(tài)的請(qǐng)求命令并處理它，而另一部分則負(fù)責(zé)處理查詢。

?

七.從緩存上解決：緩存

??? ??1.客戶端、代理服務(wù)器和服務(wù)器端緩存

? ? ? 使用客戶端緩存，客戶端會(huì)緩存存儲(chǔ)的結(jié)果，由客戶端決定何時(shí)獲取最新副本。我們可以通過(guò)服務(wù)來(lái)告訴客戶端應(yīng)該更新緩存了。

? ? ? 代理服務(wù)器緩存，將一個(gè)代理服務(wù)放在客戶端和服務(wù)端之間，反向代碼或CDN就是這樣的例子。

? ? ? 服務(wù)器緩存，由服務(wù)器端處理緩存，Redis、Memcache、內(nèi)存緩存就是這樣的系統(tǒng)。

? ??? 2.HTTP緩存

? ? ? 標(biāo)準(zhǔn)的靜態(tài)網(wǎng)站，像CSS或圖片，很適合用HTTP中的cache-control和Expires指令，另外還可以使用HTTP的ETag來(lái)標(biāo)示資源是否已改變，如果我更新了客戶記錄， ? ? ?雖然訪問(wèn)資源的URI相同，但值已經(jīng)不同，所以我會(huì)改變ETag。

? ??? 3.使用寫緩存

? ? ? 你可以先寫入本地緩存，并在之后的某個(gè)時(shí)刻將緩存中的數(shù)據(jù)寫入下游，當(dāng)你有爆發(fā)式的寫操作時(shí)，或同樣的數(shù)據(jù)可能被寫入多次時(shí)，或下游服務(wù)不可用時(shí)，這種方式都是很有用的。

? ? ??4.為彈性使用緩存

? ? ? 我們可以緩存一個(gè)時(shí)間點(diǎn)的數(shù)據(jù)，在故障發(fā)生時(shí)提供這個(gè)時(shí)間點(diǎn)的數(shù)據(jù)，雖然可能不完全正確，最起碼可以用。

? ??? 5.隱藏源服務(wù)

? ? ? 有可能我們系統(tǒng)的80%請(qǐng)求都是通過(guò)緩存，那么緩存一旦失敗，請(qǐng)求都將進(jìn)入源服務(wù)，源服務(wù)從來(lái)沒(méi)有處理過(guò)這么多請(qǐng)求，這將是災(zāi)難性的，我們可以阻塞請(qǐng)求，并在后臺(tái)異步重建緩存。

? ??? 6.避免過(guò)多地使用緩存

? ? ? 緩存越多，就越難評(píng)估數(shù)據(jù)的新鮮程度。

? ??? 7.防止緩存中毒

? ? ? 你可能在系統(tǒng)中將HTTP緩存頭的過(guò)期時(shí)間設(shè)置為Expires:Never，這樣除非用戶手工清除他們（也許CDN也會(huì)緩存這些內(nèi)容），否則永遠(yuǎn)不會(huì)失效，這時(shí)我們唯一的選擇就是：改變這些網(wǎng)頁(yè)的URL，以便能夠重新獲取它們。

?

使用自動(dòng)伸縮

? ??? 現(xiàn)在的云服務(wù)提供商允許你制定自動(dòng)伸縮服務(wù)的策略，通過(guò)響應(yīng)式伸縮或者預(yù)測(cè)式伸縮幫助你在高峰（有可能是秒殺，有可能是突發(fā)式新聞，也有可能是因?yàn)橹苣?#xff09;到來(lái)的時(shí)候提供服務(wù)。

?

CAP理論

??? ? Eric Brewer的CAP理論告訴我們，一致性（Consistency）、可用性（Availability）和分區(qū)容忍性（Partition Tolerance），最多只能同時(shí)保證三個(gè)中的兩個(gè)。

?

?

? ? ? 犧牲一致性：

? ? ? 我們只需要數(shù)據(jù)保持最終一致就可以了，因?yàn)槲覀冃枰謪^(qū)來(lái)保證數(shù)據(jù)的安全性，同時(shí)保證系統(tǒng)的可用性。博客園我更新博客時(shí)，每個(gè)月份的博客統(tǒng)計(jì)數(shù)不會(huì)馬上更新就是這樣。

? ? ? 犧牲可用性：

? ? ? 像12306這樣的網(wǎng)站每天晚上維護(hù)就是犧牲了可用性。

? ? ? 犧牲容忍性：

? ? ? 既然是分布式系統(tǒng)，這種情況是肯定不存在的。

?

服務(wù)發(fā)現(xiàn)、注冊(cè)與編排

? ???方法1：DNS

? ? ? DNS讓我們將一個(gè)名稱與一個(gè)或多個(gè)機(jī)器的IP地址相關(guān)聯(lián)，例如我們可決定在accounts.hello.com上發(fā)現(xiàn)賬戶服務(wù)，這個(gè)域名會(huì)關(guān)聯(lián)到運(yùn)行該服務(wù)的主機(jī)的IP上或負(fù)載均衡器上。

? ? ? DNS的好處在于它是，但不好的地方在于更新它不是那么容易，而且對(duì)于一個(gè)新的節(jié)點(diǎn)，DNS不能“發(fā)現(xiàn)”這個(gè)節(jié)點(diǎn)。

? ??? 方法2：Zookeeper

? ? ? 它支持配置管理、服務(wù)間的數(shù)據(jù)同步、leader選舉、消息隊(duì)列和命名服務(wù)。它的核心是提供了一個(gè)用于存儲(chǔ)信息的分層命名空間，客戶端可以在此層次結(jié)構(gòu)中，插入新的節(jié)點(diǎn)，更改或查詢它們。

? ? ??方法3：Consul

? ? ? 它也支持配置管理和服務(wù)發(fā)現(xiàn)，但它比Zookeeper更進(jìn)一步，為這些關(guān)鍵使用場(chǎng)景提供了更多支持，如它為服務(wù)發(fā)現(xiàn)提供了一個(gè)HTTP接口，另外它提供了現(xiàn)成的DNS服務(wù)器。

? ? ? Consul還內(nèi)置了一些功能，如對(duì)節(jié)點(diǎn)執(zhí)行健康檢查的能力。

? ? ? Consul從注冊(cè)服務(wù)、查詢鍵/值存儲(chǔ)到插入健康檢查，都使用的是RESTful HTTP接口，這使集成不同技術(shù)棧變得簡(jiǎn)單。

? ? ??方法4：Eureka

? ? ? 它提供了基本的負(fù)載均衡功能，它可以支持服務(wù)實(shí)例的基本輪詢調(diào)度查找，它提供了一個(gè)基于REST的接口，因此你可以編寫自己的客戶端。

?

文檔服務(wù)

? ? ??微服務(wù)非常多，暴露的接口更多，我們希望知道關(guān)于這些接口的說(shuō)明，理想情況下我們會(huì)確保文檔總是和最新微服務(wù)的API文檔同步，并當(dāng)大家需要知道服務(wù)在哪里，能夠很容易地看到這個(gè)文檔。

? ? ??1.Swagger

? ? ? Swagger讓你描述API，產(chǎn)生一個(gè)很友好的Web用戶界面，使你可以查看文檔并通過(guò)Web瀏覽器與API交互，還可以直接執(zhí)行請(qǐng)求。

? ? ??2.HAL和HAL瀏覽器

? ? ? 它是用媒體來(lái)生成我們的文檔。

?

參考

? ? ? 《微服務(wù)設(shè)計(jì)》（Sam Newman 著 / 崔力強(qiáng) 張駿 譯）

相關(guān)文章：?

• 微服務(wù)的概念——《微服務(wù)設(shè)計(jì)》讀書(shū)筆記

• 微服務(wù)架構(gòu)師的職責(zé)——《微服務(wù)設(shè)計(jì)讀書(shū)筆記》

• 建模:確定服務(wù)的邊界——《微服務(wù)設(shè)計(jì)》讀書(shū)筆記

• 微服務(wù)集成——《微服務(wù)設(shè)計(jì)》讀書(shū)筆記

• 服務(wù)的協(xié)作：服務(wù)間的消息傳遞——《微服務(wù)設(shè)計(jì)》讀書(shū)筆記

• 拆分:分解單塊系統(tǒng)——《微服務(wù)設(shè)計(jì)》讀書(shū)筆記

• 部署:持續(xù)集成（CI）與持續(xù)交付（CD）——《微服務(wù)設(shè)計(jì)》讀書(shū)筆記

• 測(cè)試——《微服務(wù)設(shè)計(jì)》讀書(shū)筆記

• 監(jiān)控——《微服務(wù)設(shè)計(jì)》讀書(shū)筆記

• 安全——《微服務(wù)設(shè)計(jì)》讀書(shū)筆記

• 康威定律和系統(tǒng)設(shè)計(jì)——《微服務(wù)設(shè)計(jì)》讀書(shū)筆記

原文地址：http://www.cnblogs.com/gudi/p/6686277.html

---

.NET社區(qū)新聞，深度好文，微信中搜索dotNET跨平臺(tái)或掃描二維碼關(guān)注

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎(jiǎng)勵(lì)來(lái)咯，堅(jiān)持創(chuàng)作打卡瓜分現(xiàn)金大獎(jiǎng)

總結(jié)

以上是生活随笔為你收集整理的规模化微服务——《微服务设计》读书笔记的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。