ECI@創新科技 |微服務的回顧——從Netflix身上我們到底學到/沒學到了什么（上）

轉載贊收藏評論

舉報 2023-08-08

掃描,分享朋友圈

ECI @HiTech開欄語

【ECI @科技創新】是由ECI@HiTech科技創新專委會每周從全球精選熱門科技創新主題，幫助科技創新者和初創團隊取得成功！讓我們共同攜手，尋找改變現有游戲規則的科技創新，激發人類的智慧和挑戰，實現科技的創新和夢想。這就是科技創新的終極魅力！也是ECI”將創新帶入生活Bring Innovation to Life” 的使命所在！

通常來說，科技的發展都會交替經歷平臺期和爆發期。平臺期的科技創新更多聚焦于識別并解決客戶現在的痛點，而爆發期的科技創新更多聚焦于引領并創造客戶未來的需求，劃時代的偉大科技創新往往誕生于此。

對于那些不了解微服務的人來說，微服務是一種架構風格，它將單個應用程序劃分為一組小型獨立的服務。每個服務都運行在自己的進程中，并使用輕量級通信協議進行通信，如HTTP或REST。在Netflix，我們采用了這種架構風格來構建我們的應用程序。我們發現，通過將應用程序分解為多個微服務，我們可以提高可伸縮性、可靠性和靈活性。然而，我們也遇到了一些挑戰和問題。

首先，微服務的實施需要一個強大的分布式系統架構。這包括服務發現、負載均衡、容錯和監控等方面。在Netflix的早期階段，我們沒有完全實現這些功能，因此遇到了一些問題。

其次，微服務的部署和管理也變得更加復雜。每個服務都需要獨立的部署、監控和維護。這需要一個強大的自動化平臺來支持這些操作。在Netflix的早期階段，我們還沒有這樣的平臺，因此這個過程變得更加困難。

盡管我們遇到了一些挑戰和問題，但是在Netflix的微服務之旅中，我們也學到了一些寶貴的經驗教訓。例如，我們發現使用無狀態服務更容易實現可伸縮性。我們還發現，使用一致性哈希算法可以實現更好的負載均衡。

最后，讓我們回到Netflix文化。Netflix文化的一個核心方面是自由和責任。公司相信員工能夠做出明智的決定，并且對他們的行為負責。這種文化為員工提供了很大的自主權和靈活性，從而提高了員工的滿意度和生產力。

總之，微服務是一個復雜的架構風格，需要強大的分布式系統架構和自動化平臺來支持。在Netflix的早期階段，我們遇到了一些挑戰和問題，但也學到了一些寶貴的經驗教訓。同時，Netflix的文化也為員工提供了很大的自由和責任，從而提高了員工的滿意度和生產力。

Netflix文化

Netflix文化具有以下七大要點：首先，文化在他們看來至關重要。他們高度重視價值觀，尤其是那些對他們來說真正重要的價值觀。其次，這是一個追求高績效的文化。他們不是在試圖建立一個家庭，而是在試圖建立一個能夠贏得奧運金牌或聯賽冠軍的團隊。如果你選擇了你最喜歡的運動，你會如何為這項運動建立有史以來最好的團隊呢？

Netflix的做法是去尋找全球最好的運動員，并將所有資源都集中在他們身上。這些運動員是全球最優秀的，因此他們會自由發揮，你只需按照他們說的去做。雖然會有一些教練指導，但從根本上來說，他們既有自由，同時也對成為世界上最好的人有責任。作為管理者，你的任務是提供適當的情境，而不是實施控制，以確保成功。團隊必須高度一致，有一個共同的目標，無論他們試圖做什么，都要贏得勝利。在一個市場推出產品或接管某些業務時，這些團隊是松散耦合的，各自獨立工作，但在需要接觸的地方有清晰的API。

如果你正在打造世界上最好的團隊，擁有全球最頂尖的人才，那么你必須提供業界最高的薪酬待遇。這就是Netflix的做法。作為灣區規模較小的公司之一，Netflix卻極具洞察力，因此幾乎成為灣區薪酬最高的工程公司。在Netflix，管理層無需過多擔心晉升的問題，這主要取決于你如何自我發展和提升。成年人的自由與責任的一部分就是明確如何實現自我發展。你必須高效地管理自己的鍛煉計劃。

由于薪酬范圍非常廣泛，職業人才水平也非常多樣化，他們稱之為等級水平，這就為你提供了許多晉升的機會。你有可能在財務上得到提升，盡管你只是一個高級工程師。我們已經擁有高級工程師、經理、主管和副總裁等職位，但我們沒有初級工程師，也沒有任何等級制度。不過，經理們無需擔心這個問題。這里有許多不同尋常的制度，但這正是Netflix能夠快速有效地運作的系統的一部分。

Netflix系統思維

Netflix是一個具有系統思維和敏捷性的組織，擁有許多有趣的反饋循環和微妙之處。他們不斷優化流程，以實現快速進化，成為眾多領域的先驅。Netflix是第一個使用NGINX的公司，而NGINX的創始人不得不成立一家公司，以便我們向他支付支持費用。同時，Netflix也是JFrog的Artifactory、AppDynamics以及AWS等公司的早期客戶，以及其他一些我可能已經忘記的公司的早期大型企業客戶。作為這些有趣初創公司的先驅客戶，我們可以充分利用它們的能力，獲得各種支持，并得到很好的折扣。這是一個有效的系統，但需要我們善于利用。

因為這是一個極其復雜的系統。有許多事情并不總是按照單一的方式進行。這個系統充滿了創造力，您需要具備自律精神，并將這些元素有機地結合在一起。更為有趣的是，靈活性往往比效率更為重要。如果您將事物壓縮至極致，使其變得極其高效，它可能會失去靈活性，變得無法適應新環境。您不希望浪費任何資源，也不希望過度追求效率而剝奪了創新的自由。

最后，您需要學會將困難轉化為機遇。我們曾經采取的一種有效方式是安排工程師和開發人員隨時待命。如果您編寫了代碼并在當天發布，那么如果晚上出現了問題，您將負責修復。這種方式使得開發人員更加小心謹慎地對待他們部署的代碼，同時也學到許多優秀的實踐方法。

云端的Netflix

在2010年11月，在舊金山的QCon大會上展示的內容是我們首次向世界展示Netflix。我們希望停止所有“繁重而無差別的工作”，然后我們介紹了我們正在進行的各項舉措。這些目標不僅適用于向云端的過渡，也適用于轉向其他新的架構。我們期望能夠更快、更具擴展性、更高可用性以及更高生產力。

舊數據中心vs新云架構

在舊的數據中心，我們依賴一個集中的SQL數據庫，所以它采用的是Oracle。然而，我們所希望的是遷移到一個分布式的鍵值存儲NoSQL，使我們的系統實現去規范化，讓每個人都有自己的后端。我們并未嘗試執行無法擴展的查詢和其他類似操作。在舊系統中，我們使用了一種粘性的內存會話方式。每次客戶連接上來，相關線程會獲取到該客戶的會話信息，并據此對后續請求進行路由。這種做法由于各種原因，其擴展性并不理想。因此，我們將所有的會話信息存儲在了實例之外的Memcached中，從而構建出一個無狀態的系統。這樣，每次用戶進入時，他們都可以與一個全新的前端進行通信。該前端會查找Memcached中的會話信息，并作出響應。此外，我們還建立了一套云端系統，其中所有機器都相距甚遠。這使得在東海岸的數據中心工作的我們與在西海岸的Netflix工程師之間的通信存在較長的延遲。然而，這卻促使我們構建出延遲的協議，因為在測試階段，我們需要處理100毫秒的延遲情況。

在過去，我們面臨的是非常復雜的服務接口，而現在，我們成功將其轉變為分層的結構。在數據中心，我們對代碼進行了精密的編程，但更重要的是，我們對服務模式也進行了編程。因此，當您構建一個新的服務時，只需簡單地編寫代碼、構建模板。一旦服務開始運行，所有必要的監控和相關事項都會立即就位。

過去，我們有過復雜的目標對象。現在，我們希望轉變為輕量級、可序列化的目標對象。通常，數據中心中的工程師或開發人員需要構建JAR文件，提交后，QA團隊會定期檢查所有最新的JAR文件，嘗試在整體架構中構建并測試看是否能夠正常運行。我們每兩周進行一次這樣的工作。

在新的體系結構中，您將JAR文件包裝成一個服務，并在前端提供一個API。然后將其包裝成機器鏡像并啟動。您可以部署大量的這種服務。您需要自己進行QA測試、開發、發布，并觀察它是否能夠正常運行，隨時隨地部署。

復雜的服務接口

眼前的這些交錯復雜的接口位于數據中心，伴隨著SQL查詢和業務邏輯，我們對這些模式的共享有著深深的依賴。我們通過調用對象來獲取其他東西，但是可能會出現各種問題。當你調用數據提供程序時，我們又有了橫向的依賴。如果你試圖調用就是一個庫，你可以用它來做一些事情，你將這個庫引入到你的代碼中，最終整個宇宙都可能被卷入其中。這種感覺就像你調用一個依賴項，你就給自己的存儲庫增加了一個依賴項，你會越過一個無法返回的“事件視界”。最終，整個存儲庫都可能出現在你的構建過程中。我們正在努力減少這種依賴性，以避免出現這樣的問題。

松弛的服務接口

我們建立了一個清晰的接口。有時我們會使用Spring運行時綁定，許多Netflix模式后來都被引入到了Spring Cloud中。服務接口就是服務的全部，但是人們對此并不完全理解。比如正在開發一個電影服務，公開電影服務的方式是，我構建一個電影服務器JAR文件，并將其放入Artifactory中。其他人如果想要使用電影服務，他們只需提取JAR，它有一個API，他們就可以調用這個API。他們實際上并不關心或者知道這背后發生的細節。該庫后面可能有兩個到三個實際的微服務在支撐。你真正需要知道的唯一一件事是，第一次部署它時，你必須弄清楚安全連接的問題，否則你就無法連接到服務。您必須修改安全組才能將您添加為這些服務的客戶。從代碼的角度來看，實現是隱藏的，您可以在本地、遠程進行處理。你可以進行迭代。您可以在獨立于API的基礎上發展底層調用，這些API是您提供給嘗試使用此東西的客戶的。有線協議不應該是微服務之間的接口，如果你曾經使用過AWS，大多數時候，你都會使用AWS SDK作為你正在使用的語言。

如果你把所有東西都放在一個大型庫中，就會引入很多內容。我們實際上想做的就是將其拆分。第一層通常是由開發底層服務的人員構建的，我們稱之為服務訪問庫。它就像一個設備驅動程序，負責序列化和錯誤處理。它盡量減少橫向依賴。從邏輯上講，它就像一個SCSI驅動程序與磁盤進行通信。你永遠不會直接與磁盤進行通信，而是使用SCSI驅動程序與磁盤或NVMe（無論最新的SSD接口是什么）進行通信。大多數時候，你使用文件系統是奇怪和復雜的，但它們都使用磁盤驅動程序，而磁盤驅動程序是由所有人使用的。

服務交互模式

這是一個非常規整的模式和一個相對復雜的類似流程。例如，一個應用程序調用了電影庫，表示：“我有一部電影，我想了解這部電影的某些信息，因為我要展示它。我想獲取它的海報、劇情簡介或一堆相關信息，我將把這些信息整合到網頁響應中，以便展示這部電影。”這個ESL查看本地緩存，但沒有找到。然后，它調用緩存驅動程序，驅動程序聯系緩存服務并告知沒有，我們沒有在緩存中得到它。然后它調用實際電影服務。此過程在此ESL中是透明的，它調用電影驅動程序，驅動程序聯系并調用電影服務，返回一些信息。然后保存這些信息以備下次使用，實際上將其放入緩存中，以便下次有人在緩存中查找時可以找到它。有一組當前流行的常用電影，電影網站正在嘗試展示它們。有一種方法可以維護這些常用電影。然后將其放入本地緩存并返回結果，應用程序通常會完成。這是展示不同層級的構建方式的一種方法。請注意，緩存訪問層被電影服務和展示服務使用，但它們在其之上具有不同的功能。您只獲得了所需的最小資源。

邊界接口

這使得我們的進展極大地順利在沒有任何外部依賴的情況下，當我們第一次嘗試轉向云架構時，還沒有身份系統。我們還沒有想到如何進行身份驗證，因此我們建立了一個虛假的驅動器，其中只有實際編寫代碼的開發人員，也就是當時大約20個人。我們建立了一個身份服務，只返回這20個人。這20個人就是首批登錄云并嘗試做任何事情的人員。然后我們才能夠在其上建立所有其他層次。通過基本建立這些服務的存根，稍后將其放入，您就可以解除阻塞和耦合。這使我們能夠在早期階段構建更為有趣的接口。

無所不能的服務對象

在數據中心中，我們有電影對象和客戶對象，它們具備全面的功能，您可以使用其中的一個或另一個或兩者來執行任何任務。然而，這些對象會變得異常復雜，令人望而生畏。在開發過程中，它們被編織得錯綜復雜，令人眼花繚亂。我們100人的開發團隊所面臨的大多數問題都與您對這兩個對象的任何操作有關，特別是在我們每兩周構建和整合一次數據的過程中，涉及到電影對象的處理，這確實造成了很大的困擾。

我們希望尋求一種不同的解決方案。我們的策略是簡化對象模型，只關注視頻和訪問者。因此，我們聲明，如果您的代碼需要與電影和客戶對象進行交互，那么它將無法在我們的環境中運行。在云環境中，我們需要一個完全不同的對象模型。

視頻不再是一個復雜的概念，它只是一個想法，一個概念，僅包含一個數字，一個巨大的整數。訪問者也是一個整數，代表了訪問的次數。如果您想將100部電影序列化并發送給某人，那么它只是一組100個整數。這就是視頻的類型，也就是一組100個視頻。

當您到達系統的另一端時，您會發現，好的，我有展示一段視頻，為了實現這個目標，您只需將該視頻作為一個PresentationVideo傳遞給系統。系統會負責填充所有必要的信息，包括演示層、boxshot和劇情梗概等等。

另一方面，MerchableVideo涉及一系列因素，這些因素與個性化算法有關，需要大量信息，而演示并不需要這些。因此，您最終會獲得多個不同角度的視頻。

當您在系統中傳遞視頻時，您只需使用這個整數。這種設計是完全類型安全的，并且是在Java中管理和構建的。我們在實現這一理念上投入了大量的工作。然而，我嗎認為這個想法在實施過程中似乎被遺忘了。而且我們不確定Netflix的代碼是否仍在使用這種設計。盡管這是一個非常有創意的想法，旨在使系統更加簡潔清晰，但在2010年的那次講座上，它并未得到充分的理解和認同，人們感到困惑和無法理解，大多數人認為我們瘋狂了。

注：本文內容轉載于InfoQ文章：