智能擴展：成功使用雲原生技術擴展基礎架構的4個關鍵技巧

時間 2019-11-10

原文原文鏈接

做者：Reda Benzairlinux

今天的帖子來自CNCF大使兼Streamroot工程副總裁Reda Benzair。文章最初在Streamroot技術開發者的博客上發佈。web

在這篇文章中，我想與工程經理和後端團隊分享一些高級別的要點，以幫助他們成功擴展業務，同時避免一些最多見的陷阱和短視決策。後端

本文伴隨Streamroot首席後端工程師Jordan Pittier發佈的第一篇文章，以及咱們去年11月在HighLoad Moscow的歷程演講。這些分享了咱們在從基於VM的架構遷移到基於容器的架構，以及將咱們的基礎架構遷移到運行在Google Cloud上的Kubernetes的整個過程當中所面臨的經驗和挑戰。安全

介紹和背景

首先，我將向你介紹Streamroot的一些背景知識，以及爲何咱們花時間調整咱們的Kubernetes Engine架構，不只要擴展規模，還要使咱們的架構更具容錯性。網絡

Streamroot是一家爲主要內容全部者提供服務的技術供應商 - 媒體集團、電視網絡和視頻平臺。咱們的點對點視頻傳輸解決方案爲廣播者提供了更高的質量和更低的成本，並與現有的CDN基礎設施協同工做。架構

去年咱們（以及咱們客戶）面臨的最大挑戰之一是擴大到FIFA世界盃的破紀錄的觀衆。事實證實，2018年世界盃是有史以來規模最大的直播賽事，Akamai在峯值時的記錄的速度爲22 Tbps，超過了以前超級碗記錄的兩倍。Akamai測量的峯值量超過22 Tbps。這是他們在2014年看到的峯值的3倍。ide

Streamroot爲法國最大的私人廣播公司TF1，以及南美洲的國家電視網絡提供了世界盃。爲了可以以這種規模爲咱們的客戶服務，咱們須要擴展咱們本身的Kubernetes引擎並可以更快地擴展。咱們須要：工具

處理大量流量，每分鐘有數十萬個請求到咱們的後端
在每屆世界盃比賽開始時，在幾分鐘內達到巨大的峯值
確保100％防故障、徹底容錯、堅固的後端可以承受任何故障。做爲一名體育愛好者，我知道在現場直播期間甚至有兩分鐘的停機時間是徹底不可接受的...

最後但並不是最不重要的是，咱們必須經過只有少數後端工程師的創業規模團隊完成全部這些工做...學習

若是你對咱們過去幾個月的擴展歷程感興趣，並但願深刻了解技術細節，你能夠在Jordan Pittier和Nikolay Rodionov在莫斯科舉行的HighLoad++會議演講，以及咱們的幻燈片中查看。測試

技巧＃1：新事物並不老是好事：使用雲原生技術輕裝上陣。

自加入雲原生計算基金會（CNCF）以來，Kubernetes已呈指數級增加，對這一複雜解決方案的興趣日益濃厚，這是一種開源雲原生技術的組合。去年12月，CNCF的KubeCon + CloudNativeCon在西雅圖集合了來自世界各地的8000多名與會者。

Kubernetes是雲原生技術組件之一。還存在許多其餘組件，有一些在CNCF託管（https://landscape.cncf.io/），有一些在CNCF以外，如Istio。

雲原生技術還很年輕，每個月在不一樣領域涌現出各類新組件：存儲、安全性、服務發現、軟件包管理等。

咱們的建議：謹慎使用這些新組件，並保持簡單（、傻瓜）。這些技術是新的，有時仍然比較粗糙，並以使人難以置信的速度發展。嘗試使用全部最新的閃亮技術是沒有意義的，特別是在生產中，除非這些技術是出於真正的須要。即便你擁有龐大的優秀工程師團隊，你也須要考慮維護、運營和調試這些有時缺少穩定性的新技術的成本（資源和時間）。

做爲經理和CNCF大使，我建議遵循CNCF分類（https://www.cncf.io/projects/）來選擇具備足夠成熟度級別的原生組件。CNCF定義的標準包括採用率、壽命以及是否能夠依賴開源項目來構建生產工具。今天，Streamroot只利用了3個項目（Kubernetes、Prometheus和Envoy），這些項目處於成熟水平，並根據CNCF基金會已經「畢業」。那裏的大量組件仍處於孵化階段或沙箱階段。你仍然可使用這些，但請記住，你將面臨一些風險：穩定性、錯誤、有限的社區、學習曲線等。

最重要的是，要明白，即便可能廣泛相信孵化或沙箱階段的全部原生項目均可以填補空白併成熟生產，但這也須要考慮不會增長架構複雜性的問題。在從CNCF或CNCF外部添加任何新組件以前，請務必先問本身如下事項：

我真的須要這個組件嗎？
我在解決一個真正的基礎設施問題嗎？
個人工程師如今和從長遠來看可以應付它嗎？

圖：CNCF分類

技巧＃2：控制你的成本

當啓動一個重要的項目，好比將服務從基於VM的服務，轉移到Kubernetes支持的基於容器的體系結構時，你的主要關注點可能不是成本，而是成功遷移。雖然你的後端成本可能不是一個即時或中期的問題，但從第一天開始就要考慮到這一點。我強烈建議你儘早跟蹤Kubernetes Engine擴展成本，緣由以下：

清楚地瞭解你的資源使用狀況和軟件效率。後端團隊的主要關注點是交付，從管理角度來看，一般很難傳達高效軟件和資源使用的重要性。
在你的架構中發現改進的空間。對來自監控和成本進展的信息進行三角測量，有助於咱們肯定架構的改進。經過簡單地使咱們的實例適應咱們的使用，並更好地瞭解資源的使用和消耗方式，咱們可以將成本下降22％。
利用基於數量的成本節約。大多數雲供應商（包括Google Cloud和Amazon AWS）都會爲提交的實例提供有趣的折扣。不要猶豫，爲你的利益使用基礎設施成本覈算（和減小）。一旦達到必定的支出，即便下降10％的成本，也能夠在預算中增長几千甚至幾十萬美圓，這能夠用來派遣你的團隊參加會議，甚至能夠僱用一個新資源來構建你的產品更快！

爲了說明個人第三點，GCP提供持續使用折扣選項，爲長期承諾的實例提供顯着折扣。例如，若是你承諾一全年的資源，你能夠得到30％的折扣（就只一次，實際上很高興在月底看到帳單！）。這些折扣最高可達57％（！），爲期3年。固然，我建議在承諾任何內容以前至少等待6個月，以便肯定你最少使用的平均CPU和RAM資源。

別怕！你無需成爲公司財務或計費方面的專家便可有效跟蹤你的成本。例如，若是你但願跟蹤每個月使用狀況，則能夠默認爲每一個項目啓用費用提醒，而後使用CSV導出功能輸入你喜歡的電子表格工具。或者，在GCP上，你能夠啓用Bigquery Billing Export選項，以便每日導出資源消耗的全部詳細信息。而後，花幾分鐘時間構建一個帶有SQL導出或Excel的簡單儀表板（不要忘記讓工程師正確設置資源標籤以識別不一樣的行）。

技巧＃3：隔離並保持你的生產安全

許多博客和文章建議你僅使用一個K8羣集，但爲不一樣的環境使用不一樣的命名空間（例如，Dev、Staging和Production）。命名空間是一個很是強大的功能，能夠幫助你組織Kubernetes資源並提升團隊的速度。可是這種設置並不容易：你須要確保有一個完善的CI/CD環境，以免你的staging和prod環境之間的任何干擾，以及像部署錯誤組件在錯誤的命名空間中的「愚蠢」錯誤。讀到這篇文章時，你可能會想：「固然，但咱們有一個超級聰明的團隊，因此咱們可以處理它。」在那裏停一停：每一個人都犯愚蠢的錯誤，錯誤越愚蠢，它會發生的機會越多...因此，除非你想要在生產中救火過最緊張的日子，只由於你在那裏推進了一個Staging版本，若是使用命名空間的選項，你必須花幾周的時間創建一個頂級的CI/CD工做流程。

在咱們這邊，咱們選擇了另外一個選項來保持咱們的環境分離：咱們決定爲咱們的登臺（Staging）和生產環境建立徹底自治的集羣。這消除了人爲錯誤和安全性故障傳播的全部風險，由於兩個集羣都是徹底隔離的。這種方法的缺點是它會增長你的固定成本：你須要更多的計算機來保持兩個集羣的正常運行。但它帶來的安全和安心對咱們來講是很是值得的。

此外，你能夠經過使用GCP的短暫實例來下降成本開銷，這比普通實例便宜80％。固然，這有一個問題：若是Google Cloud須要其餘客戶，那麼這些實例可能會隨時關閉。可是當咱們僅將它們用於咱們的臨時環境時，丟失一臺機器並不會真正影響咱們，咱們甚至學會了利用它來發揮咱們的優點。對咱們來講，完美的測試是看看咱們的架構如何對咱們的一個組件的隨機故障做出反應：一種徹底不可預測的紅隊試圖摧毀系統，由Google Cloud免費提供給你

技巧＃4：從一開始就統一併自動化你的工做流程

當你開始一個新項目時，你考慮的最後一件事是如何與其餘開發者共享代碼，或者在須要執行緊急回滾時如何在生產和Staging之間推送構建。這是正常並且很是明智：在你真正構建了能夠向世界展現的任何東西以前，沒有必要進行過分優化。但另外一方面，讓這些問題潛伏在永恆中是一個常見的錯誤。由於你沒有時間，須要發佈下一個功能，使你的產品最終跨越鴻溝並神奇地帶來數百萬用戶。我對此的建議是花時間儘早建立一個簡單有效的工做流程。

首先，一旦你開始與其餘人合做，你應該退後一步，建立一個統一且易於轉移的開發環境。10年前，這不是一件容易的事：你須要在每一個人的計算機上配置特殊虛擬機，或者在Mac和Windows用戶之間進行修改。這是一場真正的噩夢，並引起了許多沒必要要的和調試不了的問題。今天，多得了像Docker這樣的容器化工具，它能夠在不到幾天的時間內完成，那麼爲何不從一開始就實現呢？這將大大簡化全部開發者的生活，並使新員工的入職變得簡單直接。對於你將節省的全部調試和設置週數來講，這是一筆很是小的投資。

其次，一旦你有生產流量，就應該考慮建立一個簡單但有效的QA/CI/CD工做流程。不須要過早設計過分，但咱們很是幸運地生活在自動化和CI工具的黃金時代，這使你能夠毫無困難地實現自動化的一流CI和CD。符合kubernetes API的CI工具列表很長，例如10.1版GitLab引入了與Kubernetes或Jenkins X的集成。大多數公司爲小規模項目提供低成本計劃，併爲開源項目提供免費計劃，因此你真的沒有任何藉口不使用它們！這不是火箭科學，它將爲你節省時間、精力和無數頭痛，讓你的開發者的生活更輕鬆！