ECI@創新科技 |微服務的回顧——從Netflix身上我們到底學到/沒學到了什么（下）
ECI @HiTech開欄語
【ECI @科技創新】是由ECI@HiTech科技創新專委會每周從全球精選熱門科技創新主題，幫助科技創新者和初創團隊取得成功！讓我們共同攜手，尋找改變現有游戲規則的科技創新，激發人類的智慧和挑戰，實現科技的創新和夢想。這就是科技創新的終極魅力！也是ECI”將創新帶入生活Bring Innovation to Life” 的使命所在！
通常來說，科技的發展都會交替經歷平臺期和爆發期。平臺期的科技創新更多聚焦于識別并解決客戶現在的痛點，而爆發期的科技創新更多聚焦于引領并創造客戶未來的需求，劃時代的偉大科技創新往往誕生于此。
缺了什么？（超時和重試）
我們大部分時候使用TCP/IP。TCP是面向連接的。當你第一次嘗試給某人打電話時，它會建立連接，然后發送請求。如果是安全連接，它會首先進行額外的握手。大多數情況下，在更高級別的系統中，我們只是想調用另一個服務，所以這在一定程度上在翻譯過程中遺漏了。考慮連接超時時一定要非常小心，因為這一過程只是一次跳轉，相對較短，而請求超時則是通過多個躍點進行端到端的傳輸。這些通常設置不正確，它們通常是全局默認值。很多時候系統會因為重試風暴而崩潰，僅僅是因為超時沒有設置正確。大多數人設置的超時時間過長，重試次數過多。我更喜歡減少這種情況的發生。最終結果是服務正在執行無法使用的操作，并引發重試風暴。
我們將嘗試用一些簡單但有效的圖表來闡明這一點。以下是一個正在運行的系統的示例。它發出一個請求，并得到了響應。如果中間的服務出現任何問題，由于有2次重試和2秒的超時設置，邊緣服務在6秒內將無法響應。而中間的服務需要處理9個外出請求，這就意味著有9個線程在同時運行，而不是僅有一個。這種情況會導致內存耗盡，線程數量不足。原本運行良好的中間服務，由于下游服務的故障，可能會突然失效，導致邊緣服務也出現問題。最終，你會遇到一個連鎖問題：系統中一個失敗的服務會導致整個系統的效率大幅下降，甚至完全崩潰。要實現這一點，你只需在所有位置設置相同的超時并增加重試次數。即使你只部分成功，首次失敗后再次響應，仍會導致中間服務進行額外的無效操作，因為它是通過重試來完成的，但邊緣服務已經放棄并再次調用。
要解決這個問題，您需要采用一個級聯的超時預算。這意味著在系統中設置一個較長的超時時間，并使用級聯超時。所有適合該超時時間的組件都應該被使用，就像望遠鏡的各個部分一樣，一直深入到系統的最深處。
如果您擁有一個相對簡單的體系結構，并且知道各個組件的執行順序，那么您可以靜態地設置超時時間。然而，在大多數情況下，您可能需要一個動態的預算或截止期限，以便在請求中傳遞。例如，您可以設定一個從邊緣服務開始的10秒超時時間，這意味著在未來10秒內必須完成操作。如果超過這個時間，系統就會放棄任務并清理資源。另一方面，為了避免在同一個連接中向實例詢問相同的問題，您可以在不同的連接中重試。
例如，如果邊緣服務的超時時間為3秒，而中間服務的超時時間為1秒，并且有一個重試機制，那么即使中間服務在第一次嘗試時失敗，它也會在2秒內響應并重試，從而避免了超過邊緣服務的超時時間。通過這種方式，您可以擁有一個快速失敗的系統，并且能夠更好地處理超時和重試問題。
為什么要嘗試同樣的服務呢？只是因為該服務可能正在執行垃圾回收或其他的操作，導致它在10秒或1分鐘內停止與所有人通信，或者類似的情況發生。此外，還有其他許多原因。我們想要做的就是調用一個不同的連接，連接到不同的服務，第一次請求可能會失敗，但我的第二次請求往往會成功。我們在Netflix實現了這一點。同樣，我不知道為什么每個人都沒有這樣做。這聽起來很明顯，而且這種彈性非常重要。我認為這是另一個沒有在某個地方被重視的教訓。我們仍然看到許多框架和環境都存在重試風暴的問題，但是我們在十年前在Netflix解決了這個問題。
微服務多種策略
我們嘗試了微服務，但并不奏效。有許多人抱怨說，也許我們應該停止使用微服務，因為它對我們不起作用。為什么它對你不起作用呢？微服務是相互加強的許多戰術之一，這些戰術形成了一個快速、有彈性、可擴展的系統。如果它不僅僅是微服務，那么它就是許多戰術，你可能在使用更多話、效率低下的協議，或者你的系統邊界不合適。如果所有事情都必須在毫秒內發生，你就構建一個大型服務來完成這個任務。這就是廣告服務器的工作方式，它們必須快速響應。一個整體，因為你要在毫秒內響應，你必須這樣做。或者，你正在進行高頻交易，當然，整體構建，并非常小心如何構建它。如果你正在為世界另一端的人構建一個網頁，你不需要把所有內容都放在一個實例中。你更感興趣的是快速開發實踐和更快創新的能力。
如果您缺乏彈性，那么可能還需要解決重試風暴的問題。例如，當某個服務出現故障時，重試可能會導致更多的故障，因此需要采取更復雜的策略來處理這種情況。此外，如果開發人員編寫的代碼不可靠，那么在面對突發情況時可能會更加困難。
混沌工程是一種用于提高系統彈性的技術，可以幫助開發人員更好地理解系統的行為并提高系統的穩定性。正確利用AZ可以提供更多的冗余和備份，從而提高系統的可用性和彈性。
可擴展性是另一個重要的因素，如果系統沒有去規范化數據模型，那么在處理大量數據時可能會變得非常緩慢。后端的一些SQL查詢可能會失敗，因此需要采取一些措施來確保這些查詢的成功執行。
垂直擴展可以將代碼調整為更高效地運行在實例上，從而提高整體效率并減少成本。深度自動縮放可以將所有實例的平均利用率提高到40%到50%之間，從而更好地利用資源并減少成本。
購買預訂和儲蓄計劃等措施可以幫助減少成本，但讓利用率翻倍才是最有效的減少成本的方法。使用無服務器功能可以更好地利用資源，并減少對硬件的依賴。綜上所述，提高系統的彈性、穩定性和可擴展性是減少成本和提高效率的關鍵。
Netflix及其他公司的系統思考
Netflix沒有招聘畢業生，也沒有實習生，仿佛正在組建一支奧林匹克團隊。它不會讓高中運動員加入這支團隊，除非他們絕對能達到奧林匹克水平。如果你想在頂級聯賽和頂級球隊中效力，你必須經過聯盟的考驗并變得更好，這就是Netflix的態度。
他們確實在明確地撇取頂尖人才，為每個人提供這些超級明星工程師和奧林匹克運動員。你在Google或Facebook或其他地方工作了5到10年，然后加入Netflix。這里，我們歡迎那些經驗豐富的工程師，他們在這里得到的益處遠超過以前的工作環境。
本·克里斯滕森，這位建造了Hystrix系統的工程師，他說過一句話：“我們只是推了他一把，他便振翅高飛。”這正是Netflix的精神所在。我們鼓勵創新，提供廣闊的空間讓工程師們自由發揮，從而釋放出他們的全部潛力。來到Netflix，你也會感受到這樣的鼓勵和支持，而不是被阻礙或牽制。
這涉及到一些深度的思考和復雜性。有目的的系統代表了系統對發展的看法。我們假設在所有三個維度上都有多元性：功能、結構和流程。他在這里真正想表達的是，有很多方法可以達到我們的目標。有很多種方式可以審視功能、多種結構以及多種流程。如果我們把所有的事物都限制在一個功能、一個結構、一個流程上，那么我們就沒有真正地代表一個適用于目的的有用的系統。
還有另一種看待這個問題的方法，那就是W.羅斯·阿什比的必要多樣性法則。這個法則表明，如果你正在嘗試管理某件事情，那么管理它的系統或方法必須具有至少與被管理的對象相同的復雜性。
然而，這里的問題是，人們往往傾向于簡化，他們追求效率，忽視了事物的復雜性。當你得到一個新的首席信息官，他們可能會試圖簡化所有的事情，這樣可能會扼殺一些重要的元素，導致系統無法再有效地運行。這是因為業務的復雜性需要由復雜的系統和流程來管理。
同時，演變的能力也意味著事物是模糊和不穩定，充滿了復雜性和變化。如果你能管理和駕馭這種復雜性，那么你的業務就能夠實現快速的發展。
另一段引人深思的引述出現在Netflix的文化資料中：“如果你想建造一艘船，不要召集人們收集木頭，分配工作和發布命令。相反，要教授他們向往無邊無際的大海。”這里的重點是我們想要為全世界建造電視。我們正在打造第一個全球電視臺。為此感到振奮，去探索如何實現這一目標，而不是按部就班地詳細規劃。
總結
我們忽略了首要指令，因為我們沒有在組織尚未準備好的情況下保護它們免受引入先進技術、知識和價值觀的風險。在Netflix，我們也曾提出一些想法并與人們分享，有些人將其帶回家并在其組織尚未準備好的情況下試圖實施。我們也曾遇到過類似情況，而一些非常成功的公司實際上采納了這些想法并將其推向新的高度，我們也在相互學習中不斷進步。
注：本文內容轉載于InfoQ文章：
Microservices Retrospective – What We Learned (and Didn’t Learn) from Netflix
（https://www.infoq.com/presentations/microservices-netflix-industry）
ECI Media官方媒體矩陣
聯系我們
轉載請在文章開頭和結尾顯眼處標注：作者、出處和鏈接。不按規范轉載侵權必究。
未經授權嚴禁轉載，授權事宜請聯系作者本人，侵權必究。
本文禁止轉載，侵權必究。
授權事宜請至數英微信公眾號(ID: digitaling) 后臺授權，侵權必究。
評論
評論
推薦評論
暫無評論哦，快來評論一下吧！
全部評論（0條）