国产91青青成人a在线/在线视频成人/aaa成人永久在线观看视频/深夜草莓视频app

本書是一本關于現代化軟件架構的書。書中介紹了如何構建和更新你的關鍵應用程序來滿足日益苛刻的數字化客戶的需求。書中還介紹了如何實現高可用性，如何使用現代化的開發和運維技術來架構應用程序，如何組織開發團隊幫助應用程序和業務獲得成功，如何將系統擴展到**規模，以及如何利用云計算的可用資源來迎接上述挑戰。本書的目標讀者包括構建和管理大規模應用程序和系統的軟件工程師、架構師、技術經理及總監。如果你管理著軟件開發人員、系統可靠性工程師、DevOps 工程師，或者經營著一個擁有大規模應用程序和系統的機構，本書中所提供的建議和指導都能夠幫助你，讓你的系統運行得更加平穩和可靠。

每一天，企業都面對著如何讓關健應用程序可伸縮的問題。當流量和數據需求不斷增加時，這些應用程序會變得更加復雜和脆弱，暴露出大量的風險并降低了可用性。隨著“軟件即服務”概念的流行，可伸縮性變得十分重要。本書更新了重要的現代化架構范式，例如，微服務和云計算，通過實際案例的指導，讓你了解如何在不降低客戶期望的條件下，構建可以處理海量請求、數據和需求的系統。工程和運維領域的架構師、經理和總監將學習到如何構建可以更加平穩和可靠地伸縮應用程序的知識，從而滿足客戶的不同需求。
●你會了解可伸縮性如何影響服務的可用性，為什么它很重要，以及如何改進它。
●你會深入了 解如何保證-個現代化的基于服務的應用程序架構的高可用性，以及降低服務故障的影響。
●你會了解什么是“由獨立團隊負責的服務架構”，它是一種可以讓你的開發團隊隨應用程序一起伸縮的模型。
●你會學習到如何理解、 測量和降低系統的風險。.你會學習到如何使用云計算來構建高可伸縮的應用程序。

譯者序
互聯網從一窮二白發展到今天，“可伸縮性”“水平伸縮”這些以前只有大型互聯網公司才面臨的技術挑戰，現在幾乎是任何一家互聯網公司都需要想辦法去解決的難題。在我看來，寫好一段代碼不難，寫好一個單機軟件也不難，但是寫好一個伸縮性良好的大規模分布式系統卻很難。這其中最難的地方首先在于思想觀念的轉變。程序員一開始接觸
到的就是確定的概念和世界，當程序邏輯一定時，什么樣的輸入就應該有什么樣的輸出。
但是在面對大規模系統時，我們首先要承認的是不確定性，即有很多我們想不到、料不到的事情會發生，一個邊角的小錯誤都可能導致整個系統全面“雪崩”。因此，我們不能再把系統當作一個穩定的、確定的程序看待，而需要在設計時充分考慮到那些可能不確定的情況。其次，就是要改變管理整個系統的有效手段。隨著系統規模的不斷增長，之前的人工操作方式已經明顯無法跟上機器的增長速度，規模增長所帶來的可靠性、可用性問題時刻都在挑戰著整個團隊的極限。因此，如何有效地評估、預測、管理、監控一個大規模的系統，這件事本身已經變成一個復雜的系統性工程，需要有效的方法論、原則、工具以及最佳實踐經驗的相應支撐。
當一個系統的規模開始擴張時，可用性往往是系統首先要面臨的問題。在激增的流量面前，每一次系統處理緩慢、崩潰都會給公司的業務帶來損失，因此理解什么是高可用性對系統保障來說至關重要。為了維持或提高系統的可用性，我們需要一套標準和手段來測量系統的可用性，從而在第一時間發現系統可用性是否發生了變化，并制定相應的解決方案。
隨著系統規模不斷擴大，各種不確定的因素會被放大，這些不確定性會給系統帶來更多的不確定性。在構建大規模可伸縮系統的時候，需要先梳理清楚系統中存在哪些不確定性，把它們定義成風險因素并建立相應的風險模型，定期回顧并確保更新風險因素。在這之后，我們要針對每個風險因素制定相應的應對方案和措施，并持續對風險管理計劃、緩和計劃和容災計劃進行測試和評估，這樣才能避免在風險發生時手忙腳亂。
當系統規模發展到一定程度時，系統本身的架構瓶頸就會突顯出來，之前的單體系統已經難以再開發和維護。這時候，不管從技術角度出發，還是從團隊人員角度出發，服務化都是一個必然的趨勢。我們需要將原有的系統功能和邏輯，拆分成多個獨立的服務來進行管理。但是，隨著服務越來越多，如何管理各個服務、服務間如何通信，以及團隊如何劃分都是新的問題。隨著業界在這方面的經驗越來越多，經過 Netflix、Amazon 等公司的實踐和推廣，微服務的概念出現，完善的解決方案和工具也開始出現。
在解決這些問題之后，我們會發現，系統規模再繼續發展就會遇到 IDC 的限制，單個數據中心甚至沒有空間來存放服務器，也支持不了所需的網絡帶寬。幸運的是，云計算和服務的出現為我們創造了無限的可能。我們無須再考慮硬件和場地的問題，無須再處理煩瑣的運維事項，可以按照使用量來付費，甚至很多服務也無須自己搭建，可以直接使用云服務廠商提供的各種高性能、高可用服務。云計算給我們帶來的是一種顛覆性的變化，不僅影響到我們的開發、運維、技術棧，更深遠地影響到我們對技術和架構的思考方式，進而為創造更多商業價值提供可能。
本書作者 Lee Atchison 是 New Relic 的首席云架構師和布道師，負責領導公司基礎設施產品的搭建，并且幫助公司設計了一個穩定的、基于服務的系統架構。他曾在 Amazon擔任了 7 年高級技術經理，深刻了解如何設計基于云的、可伸縮的系統，也主導創建了AWS Elastic Beanstalk 等產品。在本書中，Lee 根據自身多年的經驗，為我們分享了在大規模可伸縮系統的設計和實現中應該注意的幾個方面，這其中的方法和技巧都是經過時間考驗的無價經驗。相信各位讀者看完此書后，不會再懼怕那些未知的困難，能夠在保持系統規模增長的同時，保證系統的高可用性和可伸縮性。
愿以后的每個系統都是高可用、可伸縮的系統。
序
第 2 版序言
本書是一本內容全面的技術圖書，面向那些已經認識到，所有公司都已經從簡單地稱自己為“數字型企業”，轉變為如果不真的這么做就會面臨破產的企業管理人員。銀行、保險和其他曾經擁有巨大“護城河”的行業，正在被一些新貴企業所沖擊。這些企業能夠提供令人驚嘆的用戶體驗，是因為它們的運營方式真的像一家數字型企業一樣，而不僅僅是紙上談兵。
本書對于那些希望在實踐中擁有一個高可靠性的可操作路線圖、實現現代化運維理念（例如，DevOps、網站可靠性工程等），以及想應用最新技術概念和服務（例如，微服務、云計算、邊緣計算）的主管、經理和架構師們來說，絕對是一本全面指南。
我很高興能夠在 New Relic 公司與 Lee 共事，New Relic 是一家能夠讓企業在全球范圍內監控它們數字業務的公司。在 New Relic 的時候，Lee 周游了世界，幫助許多公司實現了數字化轉型，加速了創新的實現，并且交付了百分之百可用的服務。
在許多 30 分鐘的會議上，我一次又一次地看到 Lee 推動了許多公司的轉型。請各位盡情享受這本書！它將對你的公司和職業生涯產生深遠的影響！
——Ken Gavranovic，New Relic 的 EVP 兼 GM，Interland 公司（現在是 web.com）的 CEO 兼創始人
第 1 版序言
我們生活在一個有趣的時代，可以稱它為軟件的“寒武紀大爆炸”時代。在這個過程中，構建新系統的成本呈數量級下降，同時系統之間的關聯程度呈同等數量級增長。借助于Amazon 的 AWS、微軟的 Azure 和 Google 的 GCP 等資源，我們可以將系統在物理上擴展到一個幾年前還只能想象的規模。
這些資源及其似乎無限的能力，正在以各種前所未見的方式，將新的思想、產品和市場極其快速地傳播出去。但是，只有當我們構建的系統可以保持擴展的同時，所有這些探索才能成為可能。與以前相比，雖然構建小型系統變得容易很多，但是構建一個可以快速、可靠擴展的系統，并不像增加更多的硬件和存儲空間那么容易，實踐證明，這要難得多。
每個軟件系統都會經歷一個可預見的生命周期，從一個人能夠完全理解的、小型的、設計精妙的解決方案，迅速增長為一個積累了大量技術債務的龐大系統，隨后又逐漸分裂成由一些不完善的服務隨機組成的組合，并最終演化成在廣度（更多用戶）和深度（更多功能）方面均可穩定伸縮的、設計良好的分布式系統。對于這樣的系統來說，我們很容易從外部了解要做哪些事情（讓它變得更加可靠！），但又很難了解它的內部細節。幸運的是，本書是一本關于這方面不可或缺的指南，從可用性到服務層，從比賽日到風險模型，Lee 一步步介紹了影響大規模系統的各個關鍵因素和實踐方式。
Lee 加入我們的時候，是 New Relic 第一次從僅擁有一個產品正在向多個產品轉型的時期，當時我們正沉浸在用戶極速增長和公司成功的喜悅中。Lee 的到來，為我們帶來了他在 Amazon 的豐富經驗，不管是零售業務還是 AWS 業務都曾經歷過巨大的增長。Lee曾是這些團隊的領頭人，曾經積極參與過與可伸縮性有關的所有事情，也遇到過很多失敗。對我們來說，幸運的是，他已經經歷過這些挫折與困苦，其中的教訓可以讓我們避免再犯同樣的錯誤。
在 Lee 加入 New Relic 之前，多年以來，我們一直處于系統服務不可用的尷尬處境。我們原有的龐大系統也逐漸無法支持業務的發展，不管是可用性、可靠性還是性能都不是很好。但是，通過充分運用 Lee 在本書中所寫的各項技巧，我們逐漸克服了這些困難，并構建了如今穩定可靠的企業級服務。其中我們使用的一個工具，建立了可用性工程的四個級別 ：青銅、白銀、黃金和白金。要達到青銅級，團隊必須擁有風險模型以及預定義的 SLA 標準。要達到白銀級，團隊必須能夠監控風險模型中標識出來的問題，并使用比賽日的方式來解決。黃金級意味著風險已經被緩解。白金級如同 CMM 5 級一樣，不僅系統可以自愈，而且我們關注于持續性的改進。我們首先集中精力對第一級的服務進行改進，然后上升到第二級的服務，逐步推進，最終使得所有團隊都至少達到白銀級，并且大多數團隊通過了黃金級，甚至有幾個團隊達到了白金級。
后來我加入了 InVision App 這個更年輕的公司。我又一次經歷了從早期成功轉向高速增長的過程，一直推薦大家去使用 Lee 之前帶給我的技術和工具。在這個新系統、新產品、新公司的爆炸年代，我強烈建議大家跟我做一樣的事：向 Lee 學習如何構建可伸縮的系統。
— Bjorn Freeman-Benson 博士
前言
本書是一本關于現代化軟件架構的書。書中介紹了如何構建和更新你的關鍵應用程序，來滿足日益苛刻的數字化客戶的需求。書中還介紹了如何實現高可用性，如何使用現代的開發和運維技術來架構應用程序，如何組織開發團隊幫助應用程序和業務獲得成功，如何將系統擴展到最大規模，以及如何利用云計算的可用資源來迎接上述挑戰。
設計可伸縮架構的整個過程，遠不只是知道如何處理大流量。
本書的讀者對象
本書的目標讀者包括構建和管理大規模應用程序和系統的軟件工程師、架構師、技術經理及總監。如果你管理著軟件開發人員、系統可靠性工程師、DevOps 工程師，或者經營著一個擁有大規模應用程序和系統的機構，本書中所提供的建議和指導都能夠幫助你，讓你的系統運行得更加平穩和可靠。
如果你的應用程序已經從很小的規模變得很大（并且正在經歷著增長所帶來的各種問題），那么你可能正在為系統的低可靠性和低可用性煩惱。如果你正在頭疼如何管理技術債務以及相關的系統故障，本書恰好提供了這些方面的指導，能夠幫助你通過降低技術債務，讓應用程序更輕松地擴展到更大規模。
編寫本書的原因
在 Amazon 零售和 AWS 業務團隊從事了 7 年的構建高可伸縮應用程序的工作之后，我加入了 New Relic 這個正在迅速成長的公司。當時，New Relic 已經感受到了因為缺少管理高可伸縮應用程序的系統、流程所帶來的痛苦，但是尚未完整形成能夠擴大其應用程序規模的流程和規范。
在 New Relic，我目睹了一個公司在規模擴張過程中所經歷的痛苦與掙扎，同時也意識到，還有很多其他公司每天都在經歷著同樣的痛苦。
現在我在世界各地旅行，與許多客戶和像你一樣的人談論云計算、可伸縮性、可用性，以及如何構建現代化應用程序的關鍵過程。我會舉辦一些演講、小組討論、課程以及研討會。我會與工程部門的領導和管理人員進行面對面的交流，幫助他們實現目標，并從他們身上學習什么是可行的，什么是不可行的。我會撰寫一些文章，接受一些采訪，并參加一些播客節目。
編寫本書的初衷，是幫助那些正在面對其應用程序高速增長的人們，使其了解到一些有用的流程和最佳實踐，避免他們掉入規模擴張過程的各種陷阱之中。
無論你的應用程序每年增長十倍還是百分之十，也無論增長的是用戶數量、交易數量、數據存儲量還是代碼復雜性，本書都可以在構建和維護應用程序方面提供幫助，以幫助你在保持高可用性的前提下實現增長。
如今我們所說的規模
隨著應用程序的增長，它們開始變得非常復雜，并且要處理非常巨大的流量。
復雜性的增加意味著脆弱性也在增加。更多的流量意味著管理流量的機制要更加新穎和復雜。
應用程序開發人員很少從一開始構建的就是一個可伸縮的應用程序。我們經常認為自己已經實現了可伸縮性，并且相信已經能夠讓應用程序擴展到我們可以想象的最高級別。
但是更常見的情況是，我們在邏輯上和應用程序中發現了許多錯誤。這些錯誤只有在我們開始面臨擴展的問題時才會出現，從而使得應用程序更加難以擴展到可支持更大的流量和更大的數據集。
這就導致了更高的復雜性和更強的脆弱性。
最終，這種規模 - 脆弱性 - 規模 - 復雜性的循環會成為應用程序的死亡螺旋，因為它會遇到斷電、宕機和其他各種服務質量和可用性的問題。
但是這些其實都是你的問題，你的客戶并不關心這些問題。他們只是想用你的應用程序來完成他們所期望的工作。如果你的應用程序持續宕機、運行緩慢或者不穩定，客戶就會放棄你，轉而尋找能夠處理他們業務的競爭對手。
如何能提高應用程序的可伸縮性，即使是才開始意識到這些因為規模增長導致的限制也能提高呢？顯然，我們在應用程序的生命周期中越早考慮可伸縮性，擴展就越容易。但是，我們不希望過度地設計應用程序來獲得超出需要的可伸縮性。在生命周期中的任何時刻，你都可以使用各種技術來提高應用程序的可伸縮性。
但是在考慮如何使用擴展應用程序的技術之前，必須先確定什么是應用程序的可用性。
在邁出這一步之前，沒有什么比這更重要了。如果你現在不考慮這一點，那么隨著應用程序的不斷擴展，遲早你會搞不清楚它的工作方式，并且開始出現隨機的、意想不到的問題。這些問題會導致宕機和數據丟失，并將極大地影響你構建和改進應用程序的能力。
此外，隨著流量和數據的增加，這些問題只會變得更加糟糕。在做任何其他事情之前，請你先梳理清楚系統的可用性和風險管理。
第 2 版中的新內容
雖然這本書中討論的許多概念大多與時間無關，但是許多（例如，無服務器計算）技術必須保持與時俱進，以便能夠反映過去四年的行業變化。
另外，在過去的幾年里，我一直在世界各地討論這些話題。從與客戶和其他專家的各種交流中，我學到了很多東西，并且會將我學到的很多東西融入這個版本。
本書還對如何使用云計算服務進行了大量的更新。
最后，我重寫了第 1 版中的大量內容，對章節進行了重新組織，使得讀者更容易獲取相關信息。
使用云計算服務
基于云計算的服務正在以極高的速度增長和占領市場。軟件即服務（SaaS）正在成為應用程序開發的規范，這主要緣于對這些基于云計算的服務需求。SaaS 應用程序由于其多租戶的特點，尤其關注可伸縮性的問題。
隨著世界的變化，我們越來越關注 SaaS 服務、基于云計算的服務和海量數據應用程序，可伸縮性變得越來越重要。
對于我們的云應用程序的規模和復雜性，似乎還沒有看到增長結束的跡象。
如今管理可伸縮性的最先進的技術，在未來都將只是基本的功能，而將來的可伸縮性問題的解決方案會讓今天的解決方案看起來過于簡單和初級。我們的行業將需要越來越復雜的系統和架構來處理未來要面對的規模。
自然地，隨著時間的推移，這本書中的一些資料會逐漸過時。我的目的是提供盡可能多的內容，讓它們能夠經得起時間的考驗。
服務和微服務
對于服務和微服務這兩個術語的使用，業界存在很多爭議。我個人不喜歡“微服務”這個術語，因為它意味著服務的特定規模，這未必是一個健康的假設。許多服務都是小型的，有些確實是“微型的”，但也有許多服務是大得多的。大小是否合適是取決于上下文環境的，并且受到許多條件和標準的影響 注 1 ，在我看來，術語“微服務”的使用會影響這種討論。然而，我也意識到，“微服務”這個術語在業界非常流行。
還有一些人將“服務”這個術語定義為 SOA 的一部分，并進一步將這些術語與十多年前流行的某種架構聯系起來。我認為這些比較是不準確和令人困惑的。
我個人傾向使用“服務”這個術語，但我知道很多人更愿意使用“微服務”這個術語。因此，在與其他公司討論時，這兩個術語我都會使用，具體選擇哪個取決于上下文環境。在我看來，這兩個術語的意思完全相同。
不過，“服務”這個詞還有一個值得討論的用法，例如，當我們指稱某個外部服務的時候，比如“Amazon 提供了 Amazon S3 服務”，“服務”這個詞的用法看起來是截然不同的，似乎在采用這個詞的另一種用法，但實際上兩者是一回事。“服務”是一個軟件模塊，它提供了特定的功能和支持該功能的數據。無論服務由你的開發人員編寫還是由 Amazon的工程師編寫，是無關緊要的。然而，我確實意識到，有時區分這兩種類型的“服務”是很重要的。
這就是我在書中使用這些術語的方式。根據上下文環境，這兩個術語可以互換使用。在這本書中，你一定會看到我對“服務”這個詞的偏愛。你應該假設這兩個術語的意思是完全相同的。當我指稱另一家公司提供的特定類型的服務，比如某個云服務時，也會這樣表示。因此，在本書中你將會看到“AWS 服務”“云服務”“SaaS 服務”等術語。
現代化的數字客戶體驗
在現代數字世界中，軟件應用程序已經成為我們的品牌和公司的標志。客戶與我們互動是通過我們的軟件來實現的。我們的應用程序不僅僅是客戶體驗的一部分，在許多情況下，它們就是整個客戶體驗。軟件對我們的成功來說至關重要，現代化的客戶希望我們的應用程序也要現代化，他們如何看待我們的品牌和公司，在很大程度上取決于他們如何看待我們的軟件。
一個不夠現代化的應用程序
考慮一下這個例子 ：在我兒子的智能手機上有一個應用程序，我的兒子必須使用這個程序來獲得一些醫療福利。它是一個政府提供的應用程序，由美國政府開發和負責運行。
這個應用程序不是一直都能工作。當你在一天中某個“不合適”的時間啟動應用程序時，你將收到一條錯誤消息。錯誤消息的意思是 ：“該應用程序僅在東部時間星期一到星期五的上午 9 點到下午 5 點之間可以使用。”
沒錯，實際情況就是這樣。這就是我兒子智能手機上的一個移動軟件應用程序，除了在東海岸的營業時間之內，軟件是被禁止使用的。
你的企業可以使用這樣的應用程序嗎？它在使用時也有這樣的限制嗎？商業化的企業如果像這樣對客戶設定限制，還能夠繼續經營下去嗎？
不，我敢打賭，沒有一個商業化的企業能夠以這種方式生存并且對待它的客戶。我們必須為客戶提供令人難忘的用戶體驗。應用程序必須在客戶希望使用它們的任何時候都能工作，必須是 100% 的時間里都可以工作，一天 24 小時，一周 7 天。如果不是這樣，我們就會讓客戶感到失望，失望的客戶就會離開。
本書導讀
管理可伸縮性并不只是管理流量，還包括管理風險和可用性。通常來說，所有這些都是描述相同問題的不同方式，并且它們息息相關。因此，為了能夠合理地討論可伸縮性問題，我們還必須考慮到可用性、風險管理、團隊及組織流程，以及像微服務和云計算這樣的現代架構模型。
因此，本書被組織成 5 個主要部分，每個部分都代表了面向可伸縮架構的主要原則。讓我們分別來看一下。
原則 1.　可用性 ：維護現代化應用程序的可用性
現代化軟件必須保持高可用性。客戶不會容忍服務中斷。如果你的應用程序在客戶需要時不能工作，那么他們將不會成為你的長期客戶。
第Ⅰ部分討論了應用程序可用性對客戶的重要性，以及它如何受到應用程序伸縮的影響。
理解、測量和提高可用性是這些章節的重點。
這部分的章節包括 ：
第 1 章，理解、測量和提高可用性
第 2 章，兩次失誤的高度 — 預留從錯誤中恢復的空間
原則 2.　現代化應用程序架構 ：使用服務
現代化的軟件需要使用現代化的應用程序架構。現代化的應用程序架構要求遠離單體應用程序，而采用基于服務的架構。
無論是從伸縮流量的角度，還是從伸縮組織處理應用程序能力的角度來看，單體應用程序都很難進行伸縮。單體程度越大，更改應用程序的速度就越慢，能夠處理和有效管理它的人員就越少，流量變化和流量增長對可用性產生負面影響的可能性就越大。
面向服務的架構通過在流量伸縮方面提供更大的靈活性來解決這些問題。此外，它們還提供了一個可伸縮的框架，允許大型開發團隊能夠處理應用程序，使得應用程序本身可以變得更大、更復雜。
第Ⅱ部分的章節包括 ：
第 3 章，使用服務
第 4 章，服務和數據
第 5 章，處理服務故障
原則 3.　組織 ：為現代化應用程序建立可伸縮性的組織
除非你的開發團隊使用現代化的過程管理手段，否則你無法構建現代化的軟件。這包括服務所有權責任和開發流程。
應用程序如何伸縮并不重要，但如果你的開發團隊的組織架構不支持可伸縮性，或者你的組織沒有正確的文化來驅動更高的可用性和更大的可伸縮性，那么你就無法伸縮你的應用程序。
組織好你的團隊，使其可以更好地支持你的可伸縮性需求，這會創造出一種文化，從而支持應用程序的可伸縮需求。
第Ⅲ部分的章節包括 ：
第 6 章，服務所有權 — STOSA
第 7 章，服務分級
第 8 章，服務等級協議
原則 4.　風險 ：現代化應用程序的風險管理
你不能消除一個系統中的所有風險，這是不可能的。所有復雜的系統都有其固有存在的風險。我們必須學會如何管理風險，并將風險作為評估技術債務和對應用程序改進做出決策的一個工具。
理解風險、測量風險和根據測量的風險結果來確定行為的優先級，是構建一個具有高伸縮性、高可用性的應用程序的重要工具。
第Ⅳ部分包括 ：
第 9 章，如何在設計可伸縮架構時使用風險管理
第 10 章，比賽日
第 11 章，構建低風險系統
原則 5.　云計算 ：利用云計算
現代化應用程序中的高可用性要求能夠靈活伸縮。我們再也負擔不起為了滿足應用程序的峰值需求，而采購過剩的基礎設施。我們必須根據當前的需要，按需動態地分配和消費基礎設施資源。
動態的基礎設施，以及能夠支持和優化動態基礎設施的應用程序，是構建高伸縮性、高可用性的應用程序的一個關鍵架構組件。
動態的基礎設施是公有云的基礎優勢。利用好公有云對于保證應用程序的高可用性至關重要。
第Ⅴ部分的章節包括 ：
第 12 章，使用云計算來設計可伸縮架構
第 13 章，云計算改變的 5 個行業趨勢
第 14 章，SaaS 和租賃類型
第 15 章，在 AWS 云上分發你的應用程序
第 16 章，托管的基礎設施
第 17 章，云資源分配
第 18 章，無服務器計算和函數即服務
第 19 章，邊緣計算
第 20 章，地理位置對云計算的影響
這些是構建滿足客戶現代化需求的應用程序的 5 個關鍵原則。這些原則構成了設計可伸縮架構的基礎。

Lee Atchison 是New Relic 云架構的高級總監。在過去的8 年時間里，他幫助設計和建立了一個堅實的基于服務的產品架構，幫助公司從一個初創公司發展到高流量的大型公司。Lee 擁有33 年的行業經驗，他曾經在Amazon 擔任過7 年高級經理。在Amazon，他帶領團隊創建了公司的第一個軟件下載商店，創建了AWS Elastic Beanstalk 產品，并負責將Amazon 零售平臺從一個單體架構遷移到基于服務的架構。Lee 曾為一些知名公司提供咨詢，主要關于如何實現現代化的應用程序架構和進行大規模的組織轉型，包括如何優化云計算平臺和基于服務的架構、實踐DevOps 和高可用性設計。Lee 是一位行業專家，經常會發表文章，并且被諸如InfoWorld、ComputerWorld、Diginomica、IT Brief、ProgrammableWeb、The New Stack、CIOReview、DevOps Digest和DZone 等媒體引用。無論從倫敦到悉尼，從東京到巴黎，還是在整個北美，他都是全球活動的重要演講者。
張若飛，曾任多家互聯網金融公司CTO，在宜人貸、雅虎北研、金山云等知名公司擔任架構師。十余年互聯網研發及技術管理經驗，對搭建海量數據、大型分布式系統有豐富經驗。著有十余本技術譯著，包括《給大忙人看的JavaSE 8》《代碼不朽：編寫可維護軟件的十大原則》《面向可伸縮架構》（第1版）《云原生Java》《Java持續交付》等書，總計500余萬字。

序.................................................................................. xvii

前言................................................................................ xx

第Ⅰ部分　原則 1. 可用性 ：維護現代化應用程序的可用性

第 1 章　理解、測量和提高可用性............................................... 2

可用性與可靠性 ............................................................................................................3

什么導致了低可用性 ....................................................................................................4

測量可用性 ...................................................................................................................5

N 個 9 ....................................................................................................................6

計劃中的故障也依然是故障 .................................................................................6

通過數字來體現可用性 .........................................................................................7

提高下降的可用性 ........................................................................................................7

測試并跟蹤當前的可用性 .....................................................................................8

將手動流程自動化 ................................................................................................9

改進你的系統 ...................................................................................................... 12

時刻關注不斷變化和發展中的應用程序的可用性 .............................................. 12

提高應用程序可用性的 5 個要點 ................................................................................ 12

要點 1 ：時刻考慮應對故障 ................................................................................ 13

要點 2 ：時刻考慮如何伸縮 ................................................................................ 14

要點 3 ：緩和風險 ............................................................................................... 15

要點 4 ：監控可用性............................................................................................ 17

要點 5 ：以可預期及明確的方式來處理可用性問題 ........................................... 18

做好準備 ..................................................................................................................... 19

第 2 章　兩次失誤的高度——預留從錯誤中恢復的空間. .................... 20

兩次失誤的高度 .......................................................................................................... 21

場景 1 ：丟失一個節點 ........................................................................................ 21

場景 2 ：升級過程中出現的問題 ......................................................................... 24

場景 3 ：數據中心恢復 ........................................................................................ 25

場景 4 ：隱蔽的共享故障類型 ............................................................................. 27

場景 5 ：故障循環 ............................................................................................... 28

管理你的應用程序 ...................................................................................................... 28

航天飛機 ..................................................................................................................... 29

第Ⅱ部分　原則 2. 現代化應用程序架構 ：使用服務

第 3 章　使用服務. ............................................................... 32

單體應用程序與面向服務的應用程序 ........................................................................ 32

所有權收益.......................................................................................................... 34

規模收益 ............................................................................................................. 36

拆分服務 ..................................................................................................................... 37

如何定義服務 ...................................................................................................... 37

深入了解服務 ............................................................................................................. 38

指導原則 1 ：特定的業務需求 ............................................................................. 38

指導原則 2 ：清晰和獨立的團隊所有權 .............................................................. 39

指導原則 3 ：天然隔離的數據 .................