10位技術領袖告訴你趟過的微服務那些坑和最佳實踐

小數導讀：
切換到微服務架構彷佛很容易，但技術領導者每每低估了項目的複雜性，並犯下災難性的錯誤。此文對來自以色列和美國等5個國家的技術領袖進行了13次採訪。這篇文章很長，內容包括以下一些方面：

• 微服務是什麼
• 微服務架構優劣勢分析
• 微服務面臨的挑戰和應對解決方案
• 微服務落地要避開的坑
• 來自技術領導型企業的微服務架構最佳實踐
• 如何選擇微服務當中的技術棧？
• 實用的技術建議
爲何轉向微服務？
企業容易犯的最大錯誤是在沒有明確目標的狀況下，轉向微服務架構。須要瞭解並有真正的理由代表爲何要這樣作。

「人們盲目進入不少領域：Docker很酷，微服務很偉大！但它可能不適合你的體系構建，你須要瞭解爲何要這麼作。」 - 來自Steven McCord， ICX Media（一家企業營銷視頻製做衆包平臺 ）創始人兼CTO。

若是你的系統工做正常，那有什麼動力去改變它？

若是隻是由於微服務被炒做，這並不意味着你須要跳入潮流。它不必定是企業軟件的最佳技術選擇。

「肯定緣由相當重要。」這是David Dawson，Steven McCord和Avi Cavale 所強調的。

「當客戶要求我實施微服務時，我會問的第一個問題是，爲何？我正在尋找的答案是，「但願更快地改變系統」和「但願利用雲技術」。微服務其實比創建單一的系統更昂貴和困難。微服務在數據模型中引入網絡，能夠隨時進行任意分割，但也可能伴隨數據丟失，讓企業暴露在分佈式計算的恐懼之中。「 - 系統架構師 David Dawson說道。
明肯定義一個微服務

「我不必定選擇微服務。我傾向中型服務，因此不是從單體架構轉到上百種的微服務，而是與工程團隊和業務保持一致的更大的服務。」 - 來自 Daniel Ben-Zvi , SimilarWeb（網站和應用追蹤分析公司） 研發副總裁。

如何作？一個圍觀案例研究
「咱們經過查看哪些代碼（若是更改的話）最終肯定了指數測試案例，從而肯定了一個微服務。咱們的目標是減小對每次改變的測試次數。若是這是你的目標，那麼微服務的定義就和」計費就是一個微服務」沒有什麼不一樣。」Shippable 聯合創始人兼CEO Avi Cavale 說道。
微服務架構優劣勢分析

微服務顯著優點
可擴展性：分析小塊的應用，看每塊的要求，每部分能夠分別伸縮應用程序的不一樣部分。
「另一個好處是，能夠在任何虛擬機以外擴展容器。容器能夠放置在任何形式的配置中，應用程序具備徹底的可移植性。「 - ICX Media 創始人兼CTO Steven McCord說道。

更簡單的可維護性：不一樣的團隊以不一樣方式獨立處理不一樣的組件。

獨立部署和配置：部署和配置每一個服務時，不會影響其餘服務。多個團隊能夠將多個結果投放到生產中，不會彼此干擾。

問題隔離：更容易隔離和監測問題。

易於招聘：尋找開發人員或第三方供應商時，只需培訓他們系統的一部分。

清晰的責任：一個團隊負責特定的微服務。

深厚的知識：團隊從內到外瞭解相關知識。

多種編程語言：可使用不一樣的編程語言，這取決於微服務的目的。

更易於監督和理解：將龐大的代碼分割成更小的項目，利於團隊更好地理解。

更容易開放組件：當邊界和接口被明肯定義時，向新的業務單元開放組件或現有功能更容易。

微服務劣勢
部署和互操做性：這是首要問題。

編程語言太多：會限制代碼的可重用性以及可維護性，而且維護更加複雜。

組件一塊兒工做：要確保服務是以一種協同工做的方式組成。只考慮改變單一的端點，會打破舊版本的其餘依賴服務。

與單體系統相比，更難以對整個系統進行集成測試。

架構必須從一開始就深思熟慮：若是服務之間的凝聚力過大，也會失去大部分優點。

加大通訊力度：在服務之間的通訊方面，須要進行投入。服務的通訊之間容易發生故障。

難以監控整個系統：大量組件對監控來講，是噩夢。

花時間學習：使用微服務須要學習，這須要時間。

複雜性：愈來愈多的微服務使整個系統更加複雜，難以監控。

「全部這些東西都散在周圍。若是沒有很好的工程流程，企業最終得到一大堆東西，然而根本不會使用。」 - Shippable聯合創始人兼CEO Avi Cavale說道。

「在基於微服務的平臺上調試生產問題是徹底不一樣的操做。若是沒有相應的監測，記錄和跟蹤設施，系統的複雜性會顯著增長。這就像迷宮同樣。工程實踐和標準化相當重要。」 - SimilarWeb研發副總裁 Daniel Ben-Zvi 說道。

「記錄到一個地方有挑戰性。Loggly，Splunk或Heroku等第三方日誌聚合服務是很是好的解決方案，但價格很是高。根據個人經驗，遙測特別集中的日誌是最大的難題。必須考慮每一個服務的詳細程度。不然，企業可能要花費50-60％的成本進行記錄。」-來自微軟公司SRE工程師 Sonu Kumar。
微服務面臨的挑戰和解決方案

當轉向微服務時，以下這些是技術領導者和開發團隊面臨的最大挑戰。
• 挑戰1：一次切換全部系統
• 挑戰2：拆分系統
• 挑戰3：組織認同
• 挑戰4：團隊

挑戰1：一次切換全部系統
「從單體架構切換到微服務架構不是一次就能夠完成的。若是企業有單體服務器，那麼其周圍可能被存儲庫，部署任務，監控和其餘許多事情包圍。一塊兒更改並不容易。」 - AdRoll軟件工程師Brujo Benavides說道。

「若是一個公司從未有任何微服務經驗，即便是新建，也會比想象的更難。」 - LogMeIn DevOps工程師 Viktor Tusa 說道。

white_check_mark：可能的解決方案

「那時候咱們作的是保留單體服務器，可是任何新的服務都是經過微服務來開發的。」（Brujo Benavides）

挑戰2：拆分系統
「若是組件和服務彙集在一塊兒，隔離起來至關具備挑戰性。（Robert Aistleitner）。須要定義各個部分之間的交互和流程。若是沒有很好的定義，系統會產生更多問題。」- StyleSage高級開發人員 Jose Alvarez 表示。

「將系統拆分紅微服務有許多不一樣的規則，沒有特定的模式，沒人會告訴你，如何在應用程序中使用它。並且，沒有兩個相同的微服務」。 - Recart 首席架構師大衛·帕普說道。

white_check_mark：可能的解決方案

「把單體系統分解成微服務的惟一方法，是首先檢查單體系統，看看它最「痛」在哪裏。將這些部分拿出來並轉化成微服務「。 - Emarsys工程副總裁Andras Fincza表示。

監控全部部分是如何工做的以及他們在作什麼。監控過程當中，能夠很容易地發現和解決問題。(Jose Alvarez)

模塊by模塊漸進地分離單片系統是最好的方法。想一次作全部事情，必定會失敗的。

監控工具提示：
• New Relic
• Datadog
• Influxdb
• Grafana
挑戰3：組織的支持
「得到組織認同多是最難的部分。」 - 來自 Steven McCord ，ICX Media創始人兼CTO。

這不是一個技術決定。須要清楚說明微服務架構的好處，從而說服企業從新分配資源。在企業接受變革以前，這是一個漫長而乏味的過程，組織規模越大，決策的時間越長。

white_check_mark：可能的解決方案

說服組織改用微服務的最佳方式，是將非核心部分轉換爲微服務。經過這種方式，來展現微服務的優點。

挑戰4：團隊
「團隊自己面臨着最大的挑戰，它須要不一樣的思考。」 「開發人員必須花費更多時間來了解什麼是端到端場景。他們須要熟悉這些技術，須要轉換思惟方式。」

「對於一個在端到端測試的世界中工做的人來講，忽然把它分解成小塊，是不舒服的，這更可能是文化上的變化。」-Shippable 聯合創始人兼CEO Avi Cavale說道。

white_check_mark：可能的解決方案

從很是小的能夠真正受益的方面開始，並選擇應用程序的非關鍵部分。得到一個小團隊的支持，並將這部分轉換爲微服務。一方面來證實微服務的優點，另外一方面逐步向企業擴展（Avi Cavale）。

微服務落地要避開的坑

「避免同時將整個系統切換到微服務。」 - Emarsys工程副總裁 Andras Fincza 說道。

「你能犯的最大的錯誤就是，沒有建立一個微服務架構變化可能帶來的影響概覽。在實際開始實施新方法以前，必須包括大量移動組件。「 - Usersnap工程副總裁Robert Aistleitner說道。

「單體架構很容易改變內部接口。只需重構代碼，而後運行測試。使用微服務，API必須可靠，你不必定知道你全部的客戶。若是沒有API的話，會給將來帶來許多麻煩。此外，確保有分佈式跟蹤系統。」-來自 Daniel Ben-Zvi ，Similar Web研發副總裁。

「不要在沒有搞清楚平臺和依賴關係的狀況下，嘗試切換到微服務。此外，也要避免認爲微服務都不錯，由於每個微服務能夠用不一樣的語言來編寫是一個很差的作法。」 - 來自 Viktor Tusa ，LogMeIn DevOps工程師 。

「處理數據相當重要。搞砸數據很是容易，可是很難恢復。數據遷移須要更多步驟。」 - Emarsys工程副總裁Andras Fincza表示。

「在微服務之間共享數據是一個很大的禁忌。若是兩個服務操縱相同的數據，將遇到一致性問題，並消除全部權。「 - Daniel Ben-Zvi＆Varun Villait兩者共同認爲。

「把應用程序分解成太多過小的東西，或者強迫把系統轉變成微服務，這不該該是微服務 - 僅僅是炒做」。- 來自 Doctusoft首席開發Csaba Kassai 的觀點。
來自技術領導型企業的微服務架構最佳實踐

建立微服務之間的隔離，能夠根據須要快速更改它們。這一般須要在幾個層面進行隔離：

運行時流程：這是最明顯的，也是廣泛採用的過程。之前只有一個流程，而如今有不少。這裏的主要成本是採用某種形式的分佈式計算，這很難作到。會致使採用容器化，事件架構，各類http管理方法，服務網格和斷路器。

團隊/文化：分離團隊，給予自主權，意味着劃分人與人之間的溝通。這每每會致使知識孤島和工做重疊（解決選擇性與資源效率的選擇）。

數據：採用像微服務這樣的分佈式計算最大的影響是它影響企業的數據。以某種形式對數據進行劃分，須要在系統級別從新整合，以給出「一個系統」的印象。這在伸縮方面有潛在好處，但也須要相比簡單的單一數據架構方法的更多想法。（來自David Dawson）
如何選擇微服務當中的技術棧？

這是不一樣意見開始碰撞的地方...

一方面，人們認爲使用什麼技術和編程語言並不重要。

「幾乎全部的問題均可以用任何技術解決。人們花費太多時間尋找正確的技術，若是以迭代的方式來作，你就有時間思考，並看到它的實際應用。錯誤的決策也能夠獲得緩解。」 - Andras Fincza ，Emarsys 工程副總裁表示。

「大多數現代語言（Python，Java，C＃，Node / JavaScript）一樣快速且可擴展。從這個角度來看，語言可有可無。每種語言都有其優勢和缺點。大部分時間，語言選擇是根據我的的喜愛，而不是技術參數。」 -Andras Fincza ， LogMeIn DevOps 工程師說道。

花費大量的時間來選擇最好的技術是不值得的，由於差別很小。

「選擇技術的重要性被高估了。若是運行成本很重要，那麼就能夠接受，對咱們來講沒那麼重要。」 - Andras Fincza ， Emarsys 工程副總裁。

「若是是新建項目，選擇程序員最瞭解的語言。若是不是，選擇客戶端上最佳覆蓋業務系統的語言。」 -Viktor Tusa ， LogMeIn DevOps 工程師 。

「微服務的好處在於它被封裝在一個微服務中，只須要給外部的接口來談論這件事。只要有一個界面就夠了。「 -Steven McCord ， ICX Media創始人兼CTO 。

選擇合適的技術不只僅是技術問題，也是一個決策。若是選擇一種具備10種不一樣編程語言的微服務架構，要確保團隊可以處理該問題。

「我不推薦混合太多的編程語言，由於招聘會變得更加困難。並且，程序員的上下文切換會減慢開發速度。「 - Robert Aistleitner ， Usersnap工程副總裁。

「必須有意識地選擇想要創建的開發團隊類型。若是想使用許多不一樣的編程語言，須要創建一個可以使用和學習不一樣編程語言的動態團隊。「 - Steven McCord ， ICX Media創始人兼CTO 。
實用的技術建議
「我強烈建議在Google雲端平臺中使用管理服務，如App Engine。這將肩負很大的負擔。此外，選擇語言/技術時/框架時，選擇合適的針對特定微服務的使用狀況是重要的，不要由於熟悉它，而強迫選它。」 - Csaba Kassai ，Doctusoft 首席開發。

如下來自Brujo Benavides：
一些技術領導者樂於推薦一些技術，這些技術能夠很好地適用於服務特定角色的微服務。在選擇微服務技術時，建議考慮：
• 可維護性
• 容錯
• 可擴展性
• 架構成本
• 易於部署
Brujo團隊的一些微服務框架/技術示例：
• Scrapy for web crawling
• Celery + RabbitMQ用於微服務通訊
• NLTK + Tensorflow（以及其餘一些）用於機器學習部分
• AWS服務
如何選擇合適的技術/語言？

在爲微服務選擇編程語言/技術時，須要考慮不少事情。

其中最重要的就是看你的開發人員具有哪些能力，以及語言/技術背後有多大的支持（工具，社區......）。根據個人經驗，公司傾向於根據其開發人員的能力選擇一種編程語言。「 - Csaba Kassai ， Doctusoft首席開發人員。

「使用技術背後有不少支持（資源和活躍的社區）。我推薦Ruby和JavaScript，能夠獲得不少支持，若是出問題，不少人均可以提供幫助。只要肯定有不少人使用它，選擇語言不該該是問題。若是團隊不具有這些知識，能夠依靠外部資源。「 - Varun Villait，Industry CEO。

「另外一個因素多是圖書館能夠用來加速項目的語言。你理想的語言的某些東西可能圖書館沒有，不得不本身發明，這是另外的時間流失。容錯和可擴展性也是重要因素。若是從如今開始的幾個月內，你不得不從新編寫一些東西，由於最初的選擇沒法擴展，那不如放棄。這一切都歸結到一個特定的團隊狀況，他們願意進行投入。」 – Greg Neiheisel , Astronomer聯合創始人兼 CTO 。

Emarsys就是這樣看待這個過程的：

在Emarsys，若是他們想應用一種新的編程語言，開發人員須要提供真實的，合乎邏輯的理由，並諮詢主要開發人員。團隊彙集在一塊兒討論技術的優缺點。

他們老是用不一樣的技術創造一個尖峯解決方案。這可讓他們試驗一個給定技術的邊界，看看它是否能夠應用於給定的微服務。這對於發現技術的侷限性是完美的。

「建議使用您的團隊已經熟悉的語言。這樣，他們能夠工做更溫馨，進展較快。」 –來自 Andras Fincza， Emarsys 公司工程副總裁 。

這是他們在SimilarWeb上所作的：
做爲一家大數據和分析公司，咱們面臨着很是大的挑戰，這增長了選擇錯誤技術的風險和影響。單線程框架（如NodeJS）雖然適用於網絡綁定服務，但在處理實時密集型數據處理時不會擴展。

工程師經過平衡戰術和戰略需求，同時考慮技術和組織的約束條件，來肯定使用哪一種技術。企業正處於快速成長階段嗎？服務是否須要處理大量數據？是否但願將新技術添加到堆棧中，是由於相信它的生態系統，仍是使用咱們已經掌握的現有技術？想要試驗嗎？能找到對此充滿激情的工程師嗎？是否願意長期致力於這項技術？技術的生態系統是一個主要因素。咱們但願與開源社區合做，使用和貢獻現有的框架，而不是從新發明。

定義明確的指導方針甚至是清單能夠幫助促進健康的決策過程，縮小可能的技術選擇範圍，從而選擇最適合的團隊和產品方案。

David Dawson提出的選擇建議：
1.從數據架構的角度來看，須要一些能夠輕鬆地將數據同步到服務之間的網絡，並保持一致的可用狀態。有不少種方法，這正是微服務部署中所須要的。能夠觀察實現這些模式的各類框架和技術。

2.一旦肯定了模式和方法，就可使用可用的資源來分析。若是已經決定採用大量反應式編程的數據流方法，而且擁有Java開發人員，那麼選擇Spring，Spring Cloud Data Flow和Kafka而且部署到某種形式的Cloud Foundry上（若是能夠獲得它！）。

若是須要大量更重的數據轉換，請帶上Spark或Kafka Streams 來解決這個問題。若是有JavaScript 開發人員，那麼這個問題是沒有道理的。相反，你會但願在JS運行時（clojurescript等）採用一些功能語言，再次使用一些相似的反應式集成技術（好比Kafka），並從那裏採起。

關鍵要點：
• 不要強調完美的技術，採起迭代的實驗方法。
• 每一個微服務架構都是獨一無二的; 所選擇的技術要與系統需求保持一致。
• 太多不一樣的技術使招聘更加複雜。
結論：
切換到微服務架構時，有不少挑戰。在將系統轉換爲微服務以前，請肯定要實現這一目的的真實緣由。優勢和缺點的分析會是一個很大的幫助。首先考慮系統的特性，而並不是僅僅改變那些傷害最大的系統部分。不建議從頭開始使用微服務架構，由於從一開始就明確界定微服務的邊界是困難的。

若是決定切換到微服務，請採起漸進式方法，並從系統中取出非關鍵的一小部分，來了解它是如何工做的。這也是得到更多微服務的好辦法。

對微服務來講，沒有最好的方式能夠選擇完美的技術。每一個與技術有關的決定都受到團隊當前知識的影響，也受到公司將來招聘計劃的影響。在某些狀況下，選擇微服務技術更多的是一個招聘決定，這取決於未來要創建一個什麼樣的開發團隊。

爲了縮窄可能的技術範圍，來自Emarsys 的Andras Fincza，SimilarWeb的 Daniel BenZvi和David Dawson提供的經驗值得借鑑。

文章來源：
https://www.tuicool.com/artic...