规模化微服务——《微服务设计》读书笔记
改變思維的角度：故障無處不在
? ??? 當微服務規模化后，故障是無可避免的，以往我們總是想盡力避免故障的發生，而當故障實際發生時，我們往往束手無策。我們花了很多時間在流程設計和應用設計的層面上來阻止故障的發生，但實際上很少花費時間思考如何第一時間從故障中恢復過來。
? ? ? 一些公司喜歡組織活動，活動當天系統會被關掉以模擬故障發生，然后不同團隊演練如何應對這種情況。這些項目中最著名的是混亂猴子（Chaos Monkey），在一天的特定時間隨機停掉服務器，這促使開發人員在構建系統時不得不為它做好準備。猴子軍隊可以在系統中注入網絡延遲，也可以隨機關閉整個可用區，這可以讓你的系統得到終極驗證。SimianArmy就是這樣的一個項目。
? ? ? 通過讓軟件擁抱和引發故障，并構建系統來應對。
?
了解什么指標是我們必須關注的
? ? ??企業Wiki一個月發生故障兩天，我們認為是可以接受的，電商網站一天停一個小時也是不可接受的。我們需要正確地理解這些需求，以便采取合適的技術。
? ? ? 我們建議有一些默認的指標必須予以關注。
? ??? 1.響應時間/延遲
? ? ? 鑒于網絡的性質，你經常會遇到異常值，所以將監控的響應目標設置成一個百分比是合理的。
? ? ? 舉例：我期望這個網站，當每秒處理200個并發連接時，90%的響應時間在2秒以內。
? ? ??2.可用性
? ? ? 評價可用性，我們可以從歷史報告來分析，以跟我們的期望值相對比。
? ? ??3.數據持久性
? ? ? 用戶的登錄會話只需要保持一年，金融交易記錄則需要保存很多年。
?
一.從體驗上來解決：功能降級
? ? ??當購物車功能不可用時，你可以隱藏掉這個圖標，并提示“馬上”，或者變成一個可下單的電話號碼。
? ? ? 對于每個使用多個微服務的面向用戶的界面，或每個依賴多個下游合作者的微服務來說，你都需要問自己“如果這個微服務宕掉會發生什么”，然后你就知道該如何做了。
?
二.從請求/響應上來解決
? ??? 1.超時機制
? ? ? 給所有的跨進程調用設置超時，當發生超時時記錄到日志中，并相應地調他們。
? ? ??2.斷路器
? ? ? 當對下游的請求發生一定數量的失敗后，斷路器會打開，接下來，所有的請求在斷路器打開的情況下會快速地失敗，一段時間后，客戶端發送一些請求查看下游服務是否已經恢復，如果它得到了正常的響應，將重置斷路器。
使用斷路器，我們可以在請求失敗后把這些請求存起來，然后稍后重試它們，也可以直接使用功能降級。Hystrix就是一個基于JVM的開源斷路器。
? ? ??3.艙壁
這是一種把自己從故障中隔離開的方式，如果我們使用下游多個服務，而其中一個服務占用了過多的連接池，由于是共用連接池，這勢必會對其他的服務調用造成影響，艙壁的處理辦法，即是為每個下游服務建立一個單獨的連接池，我們當然也可以跟斷路器聯合起來使用。
? ? ? 在很多方面，艙壁是三個模式中最重要的，超時和斷路器能夠幫助你在資源受限時釋放它們，但艙壁可以在第一時間確保它們不成為限制，它可以拒絕請求以避免資源達到飽和。
?
三.從服務依賴性上解決：隔離
? ??? 一個服務依賴于另一個服務，另一個服務的健康將能影響其正常工作的能力，如果我們使用的集成技術允許下游服務器離線，上游服務便不太可能受到計劃內或計劃外宕機的影響。
? ? ? Jekins的master/slave即是這樣的解決思路。
?
四.從處理結果上解決：冪等
? ??? 對冪等操作而言，多次執行所產生的影響均與一次執行的同，如果操作是冪等的，我們可以對其重復多閃調用，而不必擔任會有不利影響。當我們不確定否被執行，想要重新處理消息，從而從錯誤中恢復時，冪等會非常有用。
?
五.從應用上解決：擴展應用
? ??? 更強大的主機、一臺主機一個微服務、關鍵業務彈性部署、多云服務數據商備份、異地災備、負載均衡、重構系統、作業隊列。
?
六.從數據庫上解決：擴展數據庫
? ????方法1：主從復制
? ? ? 當主數據庫出現故障，可以馬上啟動備份數據庫，并提升至主數據庫。
? ? ??方法2：讀寫分離——擴展讀操作
? ? ? 讀操作使用的數據庫和寫操作使用的數據庫分開，但這會造成數據暫時不一致的情況。
? ? ??方法3：讀寫分離——擴展寫操作
? ? ? 可以使用分片的方式來擴展寫操作，當你有一塊數據要寫入時，對數據的關鍵字應用一個哈希函數，并基于這個函數的結果將數據發送到哪個分片。
? ? ? 但分片擴展會導致在查詢上復雜起來，如果要查詢所有年滿18歲的顧客，那么要查詢所有分片，然后在內存中拼起來；或者有一個替代的讀數據訓包含所有的數據集。
? ? ? 分片擴展的另一個問題是，如果想添加新的數據庫節點，我們需要大量的宕機時間然后重新分配數據
? ? ??方法4：CQRS——命令查詢職責分離
? ? ? 在傳統的系統中，數據的修改和查詢使用的是同一個系統，使用CQRS后，系統的一部分負責獲取修改狀態的請求命令并處理它，而另一部分則負責處理查詢。
?
七.從緩存上解決：緩存
??? ??1.客戶端、代理服務器和服務器端緩存
? ? ? 使用客戶端緩存，客戶端會緩存存儲的結果，由客戶端決定何時獲取最新副本。我們可以通過服務來告訴客戶端應該更新緩存了。
? ? ? 代理服務器緩存，將一個代理服務放在客戶端和服務端之間，反向代碼或CDN就是這樣的例子。
? ? ? 服務器緩存，由服務器端處理緩存，Redis、Memcache、內存緩存就是這樣的系統。
? ??? 2.HTTP緩存
? ? ? 標準的靜態網站，像CSS或圖片，很適合用HTTP中的cache-control和Expires指令，另外還可以使用HTTP的ETag來標示資源是否已改變，如果我更新了客戶記錄， ? ? ?雖然訪問資源的URI相同，但值已經不同，所以我會改變ETag。
? ??? 3.使用寫緩存
? ? ? 你可以先寫入本地緩存，并在之后的某個時刻將緩存中的數據寫入下游，當你有爆發式的寫操作時，或同樣的數據可能被寫入多次時，或下游服務不可用時，這種方式都是很有用的。
? ? ??4.為彈性使用緩存
? ? ? 我們可以緩存一個時間點的數據，在故障發生時提供這個時間點的數據，雖然可能不完全正確，最起碼可以用。
? ??? 5.隱藏源服務
? ? ? 有可能我們系統的80%請求都是通過緩存，那么緩存一旦失敗，請求都將進入源服務，源服務從來沒有處理過這么多請求，這將是災難性的，我們可以阻塞請求，并在后臺異步重建緩存。
? ??? 6.避免過多地使用緩存
? ? ? 緩存越多，就越難評估數據的新鮮程度。
? ??? 7.防止緩存中毒
? ? ? 你可能在系統中將HTTP緩存頭的過期時間設置為Expires:Never，這樣除非用戶手工清除他們（也許CDN也會緩存這些內容），否則永遠不會失效，這時我們唯一的選擇就是：改變這些網頁的URL，以便能夠重新獲取它們。
?
使用自動伸縮
? ??? 現在的云服務提供商允許你制定自動伸縮服務的策略，通過響應式伸縮或者預測式伸縮幫助你在高峰（有可能是秒殺，有可能是突發式新聞，也有可能是因為周末）到來的時候提供服務。
?
CAP理論
??? ? Eric Brewer的CAP理論告訴我們，一致性（Consistency）、可用性（Availability）和分區容忍性（Partition Tolerance），最多只能同時保證三個中的兩個。
?
?
? ? ? 犧牲一致性：
? ? ? 我們只需要數據保持最終一致就可以了，因為我們需要分區來保證數據的安全性，同時保證系統的可用性。博客園我更新博客時，每個月份的博客統計數不會馬上更新就是這樣。
? ? ? 犧牲可用性：
? ? ? 像12306這樣的網站每天晚上維護就是犧牲了可用性。
? ? ? 犧牲容忍性：
? ? ? 既然是分布式系統，這種情況是肯定不存在的。
?
服務發現、注冊與編排
? ???方法1：DNS
? ? ? DNS讓我們將一個名稱與一個或多個機器的IP地址相關聯，例如我們可決定在accounts.hello.com上發現賬戶服務，這個域名會關聯到運行該服務的主機的IP上或負載均衡器上。
? ? ? DNS的好處在于它是，但不好的地方在于更新它不是那么容易，而且對于一個新的節點，DNS不能“發現”這個節點。
? ??? 方法2：Zookeeper
? ? ? 它支持配置管理、服務間的數據同步、leader選舉、消息隊列和命名服務。它的核心是提供了一個用于存儲信息的分層命名空間，客戶端可以在此層次結構中，插入新的節點，更改或查詢它們。
? ? ??方法3：Consul
? ? ? 它也支持配置管理和服務發現，但它比Zookeeper更進一步，為這些關鍵使用場景提供了更多支持，如它為服務發現提供了一個HTTP接口，另外它提供了現成的DNS服務器。
? ? ? Consul還內置了一些功能，如對節點執行健康檢查的能力。
? ? ? Consul從注冊服務、查詢鍵/值存儲到插入健康檢查，都使用的是RESTful HTTP接口，這使集成不同技術棧變得簡單。
? ? ??方法4：Eureka
? ? ? 它提供了基本的負載均衡功能，它可以支持服務實例的基本輪詢調度查找，它提供了一個基于REST的接口，因此你可以編寫自己的客戶端。
?
文檔服務
? ? ??微服務非常多，暴露的接口更多，我們希望知道關于這些接口的說明，理想情況下我們會確保文檔總是和最新微服務的API文檔同步，并當大家需要知道服務在哪里，能夠很容易地看到這個文檔。
? ? ??1.Swagger
? ? ? Swagger讓你描述API，產生一個很友好的Web用戶界面，使你可以查看文檔并通過Web瀏覽器與API交互，還可以直接執行請求。
? ? ??2.HAL和HAL瀏覽器
? ? ? 它是用媒體來生成我們的文檔。
?
參考
? ? ? 《微服務設計》（Sam Newman 著 / 崔力強 張駿 譯）
相關文章：?
微服務的概念——《微服務設計》讀書筆記
微服務架構師的職責——《微服務設計讀書筆記》
建模:確定服務的邊界——《微服務設計》讀書筆記
微服務集成——《微服務設計》讀書筆記
服務的協作：服務間的消息傳遞——《微服務設計》讀書筆記
拆分:分解單塊系統——《微服務設計》讀書筆記
部署:持續集成（CI）與持續交付（CD）——《微服務設計》讀書筆記
測試——《微服務設計》讀書筆記
監控——《微服務設計》讀書筆記
安全——《微服務設計》讀書筆記
康威定律和系統設計——《微服務設計》讀書筆記
原文地址：http://www.cnblogs.com/gudi/p/6686277.html
.NET社區新聞，深度好文，微信中搜索dotNET跨平臺或掃描二維碼關注
創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎總結
以上是生活随笔為你收集整理的规模化微服务——《微服务设计》读书笔记的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： .NET 的一点历史往事：和 Java
- 下一篇： 世界上最大的搜索引擎公司 Google