雲原生模式讀後感(二)

雲原生模式書籍介紹:https://item.jd.com/12704245.html

記錄一些書中的總結

第二部分雲原生模式

7.應用程式生命周期：考慮不斷的變化

(1)在雲原生環境中，必須考慮應用程式的生命周期，并将它看作單獨的邏輯實體，即使每個應用程式執行個體都有自己獨立的生命周期。

(2)還必須仔細關注某個應用程式的生命周期事件，看其會如何影響軟體中其他的應用程式。

(3)隻有當一個應用程式的多個執行個體可以同時支援不同的配置時，才能使用滾動更新的部署方式。否則，必須使用藍/綠更新的部署方式。兩者都可以在零停機時間内完成。

(4)一個精心設計的密碼輪換模式，可以通過滾動更新的方式來實作。

(5)如果人為替換應用程式的執行個體也可以實作這種模式，那麼也可以這樣做。讓我們放下這種偏見。

(6)應用程式日志應該被發送到stdout和stderr，大多數雲原生平台都會在那裡處理它們。

(7)應用程式的狀态必須是可用的，這樣才能持續檢查系統的健康情況，并且所依賴的應用程式才能夠适應變化。

(8)無伺服器計算是雲原生的一種極端形式，它使用了本書中介紹的大多數模式。

8 如何通路應用程式：服務、路由和服務發現

(1)可以用一個簡單的抽象将用戶端和依賴服務之間松耦合。

(2)有兩種主要的負載均衡方法—集中式（或者服務端）和用戶端。每種方法都有各自的優點和缺點。

(3)負載均衡器的配置必須是動态且高度自動化的，因為在雲原生環境中，流量被路由到的執行個體比過去變化的頻率大得多。

(4)諸如DNS之類的名稱服務是服務發現協定的核心，該協定允許用戶端在不斷變化的網絡拓撲中找到相關服務。

(5)在使用域名服務時，作為一名開發人員，你必須考慮到名稱到IP位址的映射表是最終一緻的，你必須考慮到映射記錄可能已經過期的情況。

(6)使用一種服務發現協定可以讓軟體部署變得更有彈性

9 互動備援：重試和其他控制循環

請求重試的基本模式很簡單：應用程式向遠端服務送出請求，如果在合理的時間内沒有接收到響應，将再次嘗試

(1)重試一個逾時請求可以降低本來會通過系統傳播的錯誤。

(2)如果處理不當，即使修複了連接配接性的問題，排隊中的重試請求也會使系統過載。

(3)正确配置的重試既可以顯著降低重試風暴的風險，又可以在不太嚴重的停機事故中提供巨大的好處。

(4)隻有在安全的情況下才使用重試，是一名開發人員應該承擔的責任。

(5)你不僅應該養成實作服務的核心邏輯的習慣，還應該養成在意外情況下實作回退邏輯的習慣。

(6)重試隻是一種控制循環模式的例子。

(7)對于組成雲原生軟體的分布式系統，控制循環是一項必不可少的技術。

10 前沿服務：斷路器和API網關

斷路器

在軟體中，斷路器的運作方式基本相同。當負載過高時，斷路器會打開并阻止流量通過。但是它有兩個不同之處。首先，用來檢測何時應打開斷路器的機制是基于實際的故障，而不是對可能的故障的預測（你肯定不希望電路在檢測到小火苗後才會跳閘）。其次，軟體中的斷路器通常具有内置的自我修複機制（這與讓人類在黑暗的房屋中找到配電闆，并手動翻轉斷路器的方式不同）。

api網關

開源和商業API網關比微服務和基于雲的架構興起得還要早。例如，Apigee（自被Google收購）和Mashery（被Intel收購，然後出售給TIBCO）都是在20世紀00年代初期成立的公司，都專注于開發API網關。API網關在軟體架構中扮演的角色始終如本章标題所述，始終位于實作的最前面，并且提供了大量的服務

服務網格

我們不必一步就實作服務網格（Service Mesh），是以讓我一點一點地來介紹，從一個在服務網格中起核心作用的原語開始。然後，我将繼續介紹服務網格及其在雲原生軟體架構中扮演的日益重要的角色。

(1)在服務的前端設計了許多模式，用來控制與該服務的互動方式。

(2)斷路器是用來防止服務過載（包括重試風暴所産生的流量）的基本模式。

(3)API網關早于雲原生架構出現，如今已經發展得可以很好地适應高度分布式化、不斷變化的軟體部署環境。

(4)應用于互動的用戶端和服務端的模式，都可以封裝并作為一個挎鬥代理被部署。

(5)服務網格為挎鬥代理添加了一個管理平面，該管理平面允許運維人員控制安全性，提供可觀察性，并允許配置組成雲原生軟體的服務/應用程式的集合。

11 故障排除：如同大海撈針

(1)必須主動将度量名額和日志從執行服務的運作時環境中取出，因為在服務遇到故障或者更新後，這些執行環境通常會變得不可用。服務的執行環境應被視為短暫的。

(2)聚合來自多個服務執行個體的日志對于可觀察性很重要。通常首選按時間順序來處理不同服務的日志。

(3)可觀察性資訊、日志、名額和跟蹤資料的收集可以放在挎鬥代理中實作，這使得應用程式可以專注于業務邏輯，并将運維需求集中到服務網格中。

(4)完善的分布式跟蹤技術及其實作，為深入了解分布式應用程式的運作狀況和性能提供了寶貴的洞察能力。

(5)本書前面介紹的許多模式都可以用來提供所需的可觀察性。應用程式配置、應用程式生命周期、服務發現、網關和服務網格都有各自的作用。

12 雲原生資料：打破資料單體

(1)當為微服務提供一個資料庫來存儲其所需的資料時，能顯著提高自治性。這會讓系統整體具有更好的彈性。

(2)盡管在許多情況下有緩存總比沒有好，但是使用緩存來填充本地資料庫充滿了挑戰。緩存不适合用于資料頻繁變更的場景。

(3)通過事件主動将資料變更推送到本地的資料存儲，是一種更好的方法。

(4)盡管我們生産和消費的實體是事件而不是消息，但是該技術的基礎仍然是我們熟悉的釋出/訂閱模式。

(5)将事件日志作為資料的唯一真實來源，所有服務的本地資料庫僅保留投射資料，這樣可以讓運作在高度分布式、不斷變化的環境中的雲原生軟體，實作資料上的一緻性。