19月XNUMX日在莫斯科 第一次主題會議HUG（Highload++ User Group），致力於微服務。 有一個演講“運營微服務：規模很重要，即使你有 Kubernetes”，其中我們分享了 Flant 在使用微服務架構運營專案方面的豐富經驗。 首先，它對於所有正在考慮在當前或未來的專案中使用這種方法的開發人員來說都是有用的。
介紹 （50 分鐘，比文章豐富得多），以及文本形式的主要摘錄。
注意：本文末尾也提供了影片和簡報。
介紹
通常一個好的故事都有開頭、主要情節和結局。 這份報告更像是一個序幕，而且是個悲劇。 還要注意的是，它提供了局外人對微服務的看法。 手術.
我將從這張圖開始，其作者（2015 年） 馬丁·福勒：
它顯示了在單體應用程式達到一定值的情況下，生產力如何開始下降。 微服務的不同之處在於，它們的初始生產力較低，但隨著複雜性的增加，效率的下降對它們來說並不那麼明顯。
對於使用 Kubernetes 的情況，我將添加到此圖表中：
為什麼帶有微服務的應用程式更好？ 因為這樣的架構對架構提出了嚴格的要求，而這些要求又被Kubernetes的能力完美涵蓋。 另一方面，其中一些功能對於整體應用程式很有用，特別是因為當今典型的整體應用程式並不完全是一個整體應用程式（詳細資訊將在報告的後面部分介紹）。
正如您所看到的，最終的圖表（當單體應用程式和微服務應用程式都位於具有 Kubernetes 的基礎設施中）與原始圖表沒有太大不同。 接下來我們將討論使用 Kubernetes 運行的應用程式。
有用且有害的微服務
這是主要思想：
它是什麼 諾爾馬利尼亞亞 微服務架構？ 它應該會為您帶來真正的好處，並提高您的工作效率。 如果我們回到圖表，它是：
如果你打電話給她 有用，那麼在圖的另一邊將會有 有害 微服務（幹擾工作）：
回到「主要思想」：我應該相信我的經驗嗎？ 從今年年初開始我就一直在看 85 個項目。 並非所有這些都是微服務（大約三分之一到一半具有這樣的架構），但這仍然是一個很大的數字。 我們（Flant 公司）作為外包商設法看到小型公司（擁有 5 名開發人員）和大型公司（約 500 名開發人員）開發的各種應用程式。 另一個好處是我們看到這些應用程式多年來一直存在並不斷發展。
為什麼選擇微服務？
關於微服務的好處的問題是 來自已經提到的馬丁·福勒：
- 模組化的清晰界線；
- 獨立部署；
- 選擇技術的自由。
我與軟體架構師和開發人員進行了很多交談，並詢問他們為什麼需要微服務。 我列出了他們的期望。 事情是這樣的：
如果我們描述「感覺」中的一些點，那麼：
- 模組邊界清晰：這裡有一個可怕的龐然大物，現在一切都將整齊地排列在Git存儲庫中，其中一切都“上架”，溫暖和柔軟不混合；
- 部署獨立性：我們將能夠獨立推出服務，以便開發更快（並行發布新功能）；
- 開發獨立性：我們可以將此微服務提供給一個團隊/開發人員，然後將其提供給另一個團隊/開發人員，這樣我們就可以更快地開發；
- бо更高的可靠性：如果發生部分降級（20 個微服務中就有一個崩潰），那麼只有一個按鈕將停止工作，整個系統將繼續運作。
典型的（有害的）微服務架構
為了解釋為什麼現實不是我們所期望的，我將提出 集體 基於許多不同專案的經驗的微服務架構的圖像。
一個例子是一個抽象的線上商店，它將與亞馬遜或至少 OZON 競爭。 其微服務架構如下圖所示：
由於多種原因，這些微服務是在不同的平台上編寫的：
由於每個微服務必須具有自治權，因此許多微服務需要自己的資料庫和快取。 最終架構如下：
其後果是什麼？
福勒也有這個 ——關於使用微服務的「付費」：
我們將看看我們的期望是否得到滿足。
清晰的模組邊界...
但 我們實際上需要修復多少微服務？推出變革？ 我們甚至可以弄清楚在沒有分散式追蹤器的情況下一切是如何運作的（畢竟，任何請求都由一半的微服務處理）？
有一個模式“”，這裡原來是一團分散的泥土。 為了證實這一點，以下是請求如何進行的大致說明：
部署獨立性...
從技術上來說，已經實現了：我們可以單獨推出每個微服務。 但在實踐中你需要考慮到它總是會推出 許多微服務，我們需要考慮到 推出的順序。 以一種好的方式，我們通常需要在單獨的電路中測試我們是否以正確的順序推出版本。
自由選擇技術...
她是。 請記住，自由往往與無法無天接壤。 這裡非常重要的是不要僅僅為了「玩」而選擇技術。
獨立發展...
如何為整個應用程式（具有如此多的元件）建立一個測試循環？ 但您仍然需要保持最新狀態。 這一切都導致了這樣一個事實： 實際測試電路數，我們原則上可以包含， 事實證明是最小的.
在本地部署所有這些怎麼樣？事實證明，開發人員通常獨立但「隨機」地進行工作，因為他被迫等到電路可以自由進行測試。
單獨縮放...
可以，但僅限於所使用的 DBMS 領域。 在給定的架構範例中，Cassandra 不會出現問題，但 MySQL 和 PostgreSQL 會出現問題。
Бо更高的可靠性...
現實中，一個微服務的故障往往不僅會破壞整個系統的正常運行，還會帶來一個新問題： 讓每個微服務都能容錯是非常困難的。 因為微服務使用不同的技術（memcache、Redis 等），所以對於每種技術，你都需要考慮周全並實現它，這當然是可能的，但需要龐大的資源。
負載可測量性...
這真是太好了。
微服務的「輕」...
我們不僅擁有龐大的 網路開銷 （對 DNS 的請求倍增等），但也是由於我們啟動了許多子查詢 複製數據 （儲存快取），這導致了大量的儲存空間。
這是滿足我們期望的結果：
但這還不是全部！
因為：
- 我們很可能需要訊息總線。
- 如何在正確的時間及時進行一致的備份？ 唯一的 真實的 選項是為此關閉流量。 但在生產中如何做到這一點呢？
- 如果我們談論的是支持多個地區，那麼在每個地區組織永續發展是一項非常耗費人力的任務。
- 出現了集中變更的問題。 例如，如果我們需要更新 PHP 版本，我們將需要提交到每個儲存庫（有數十個）。
- 操作複雜性的成長是指數級的。
這一切該怎麼辦？
從單體應用程式開始。 福勒的經歷 幾乎所有成功的微服務應用程式都是從一個整體開始的，後來變得太大，然後就被破壞了。 同時，幾乎所有從一開始就建構為微服務的系統遲早都會遇到嚴重的問題。
另一個有價值的想法是，一個微服務架構的專案要成功，你必須非常了解 和主題領域，以及如何製作微服務。 學習一個學科領域的最好方法就是打造一個整體。
但如果我們已經處於這種情況怎麼辦？
解決任何問題的第一步是同意它並理解它是一個問題，我們不想再受苦了。
如果，在一個過度成長的整體的情況下（當我們沒有機會為其購買額外資源時），我們削減它，那麼在這種情況下，結果會是相反的情況：當過多的微服務不再有幫助，而是阻礙時 - 剪掉多餘的部分並放大!
例如，對於上面討論的集體形象......
擺脫最有問題的微服務：
組合負責前端產生的所有微服務：
……到一個微服務中，用一種（現代的和正常的，正如你自己認為的）語言/框架編寫：
它將有一個 ORM（一個 DBMS）和幾個應用程式：
……但一般來說，您可以在那裡傳輸更多內容，得到以下結果：
此外，在 Kubernetes 中，我們在單獨的實例中運行所有這些，這意味著我們仍然可以單獨測量負載並擴展它們。
總結
看看更大的圖景。 很多時候，所有這些微服務問題的出現都是因為有人接手了他們的任務，但想要「玩微服務」。
在「微服務」這個字中，「微」部分是多餘的。。 它們之所以是“微型”，只是因為它們比一塊巨大的巨石還要小。 但不要把它們視為小事。
最後，讓我們回到原始圖表：
上面寫著一張便條 （右上） 歸結為這樣一個事實 完成專案的團隊的技能始終是首要的 — 它們將在您在微服務和單體應用之間進行選擇時發揮關鍵作用。 如果團隊沒有足夠的技能，卻開始做微服務，那故事肯定是致命的。
影片和幻燈片
演講影片（約50分鐘；遺憾的是，它並沒有傳達出參觀者的眾多情感，這在很大程度上決定了報告的情緒，但事實就是如此）：
報告介紹：
聚苯乙烯
我們部落格上的其他報導：
- «» （德米特里·斯托利亞羅夫；28 年 2018 月 XNUMX 日在 RootConf）;
- «» （Dmitry Stolyarov；7 年 2017 月 XNUMX 日，HighLoad++）;
- «» （德米特里·斯托利亞羅夫；6 年 2017 月 XNUMX 日，RootConf）;
- «» （Dmitry Stolyarov；8 年 2016 月 XNUMX 日，HighLoad++）;
- «» （德米特里·斯托利亞羅夫；31 年 2016 月 XNUMX 日在 RootConf）.
您可能也對以下出版物感興趣：
- «“;
- «“;
- «“。
來源： www.habr.com