微服務 vs. 整體服務：如何選擇 | Linux 中國

任何一種架構都是有利有弊的，而能滿足你組織的獨特需要的決策才是正確的選擇。

對於許多初創公司來說，傳統的知識認為，從單一整體架構開始，而不是使用微服務。但是，我們還有別的選擇嗎？

這本新書 —— 《初創公司的微服務[1]》，從許多 CIO 們理解的微服務的角度，解釋了微服務的優點與缺點。

對於初創公司，雖然不同的 CTO 對此給出的建議是不同的，但是他們都一致認為環境和效能很重要。如果你正考慮你的業務到底是採用微服務還是單一整體架構更好，下麵討論的這些因素正好可以為你提供一些參考。

理解範圍

首先，我們先來準確定義我們所謂的 “整體服務” 和 “微服務” 是什麼。

微服務是一種方法，它開發一個單一的應用程式來作為構成整體服務的小服務，每個小服務都執行在它自己的行程中，並且使用一個輕量級的機制進行通訊，通常是一個 HTTP 資源的 API。這些服務都圍繞業務能力來構建，並且可依賴全自動部署機制來獨立部署。

一個整體應用程式是按單個的、統一的單元來構建，並且，通常情況下它是基於一個大量的程式碼來實現的。一般來說，一個整體服務是由三部分組成的：資料庫、客戶端使用者介面（由 HTML 頁面和/或執行在瀏覽器中的 JavaScript 組成）、以及伺服器端應用程式。

“系統架構處於一個範圍之中”，Zachary Crockett，Particle[2] 的 CTO，在一次訪談中，他說，“在討論微服務時，人們傾向於關註這個範圍的一端：許多極小的應用程式給其它應用程式傳遞了過多的資訊。在另一端，有一個巨大的整體服務做了太多的事情。在任何現實中的系統上，在這兩個極端之間有很多合適的面向服務的架構”。

根據你的情況不同，不論是使用整體服務還是微服務都有很多很好的理由。

“我們希望為每個服務使用最好的工具”，Julien Lemoine 說，他是 Algolia 的 CTO。

與很多人的想法正好相反，整體服務並不是過去遺留下來的過時的架構。在某些情況下，整體服務是非常理想的。我採訪了 Steven Czerwinski 之後，更好地理解了這一點，他是 Scaylr[3] 的工程主管，前谷歌員工。

“儘管我們在谷歌時有使用微服務的一些好的經驗，我們現在 [在 Scalyr] 卻使用的是整體服務的架構，因為一個整體服務架構意味著我們的工作量更少，我們只有兩位工程師。“ 他解釋說。（採訪他時，Scaylr 正處於早期階段）

但是，如果你的團隊使用微服務的經驗很豐富，並且你對你們的發展方向有明確的想法，微服務可能是一個很好的替代者。

Julien Lemoine，Algolia[4] 的 CTO，在這個問題上，他認為：“我們通常從使用微服務開始，主要目的是我們可以使用不同的技術來構建我們的服務，因為如下的兩個主要原因：

”

如果你的團隊已經準備好從一開始就使用微服務，這樣你的組織從一開始就可以適應微服務環境的開發節奏。

權衡利弊

在你決定那種方法更適合你的組織之前，考慮清楚每種方法的優缺點是非常重要的。

整體服務

優點：

缺點：

微服務

優點：

缺點：

決策時刻

當你瞭解了每種方法的利弊之後，如何在你的初創公司使用這些資訊？透過與這些 CTO 們的訪談，這裡有三個問題可以指導你的決策過程：

你是在熟悉的領域嗎？

如果你的團隊有以前的一些領域的經驗（比如，電子商務）和瞭解你的客戶需求，那麼分割成微服務是低風險的。如果你從未做過這些，從另一個角度說，整體服務或許是一個更安全的選擇。

你的團隊做好準備了嗎？

你的團隊有使用微服務的經驗嗎？如果明年，你的團隊擴充到現在的四倍，將為微服務提供更好的環境？評估團隊大小對專案的成功是非常重要的。

你的基礎設施怎麼樣？

實施微服務，你需要基於雲的基礎設施。

David Strauss，Pantheon[5] 的 CTO，他解釋說：”[以前]，你使用整體服務是因為，你希望部署在一個資料庫上。每個單個的微服務都需要配置資料庫伺服器，然後，擴充套件它將是一個很重大的任務。只有大的、技術力量雄厚的組織才能做到。現在，使用像谷歌雲和亞馬遜 AWS 這樣的雲服務，為部署一個小的東西而不需要為它們中的每個都提供持久儲存，對於這種需求你有很多的選擇。“

評估業務風險

技術力量雄厚的初創公司為追求較高的標的，可以考慮使用微服務。但是微服務可能會帶來業務風險。Strauss 解釋說，“許多團隊一開始就過度構建他們的專案。每個人都認為，他們的公司會成為下一個 ‘獨角獸’，因此，他們使用微服務構建任何一個東西，或者一些其它的高擴充套件性的基礎設施。但是這通常是一種錯誤的做法”。Strauss 說，在那種情況下，他們認為需要擴大規模的領域往往並不是一開始真正需要擴充套件的領域，最後的結果是浪費了時間和努力。

態勢感知

最終，環境是關鍵。以下是一些來自 CTO 們的提示：

什麼時候使用整體服務

什麼時候開始使用微服務

要決定整體服務還是微服務更適合你的組織，要坦誠並正確認識自己的環境和能力。這將有助於你找到業務成長的最佳路徑。

關於作者

jakelumetta – Jake 是 ButterCMS 的 CEO，它是一個 API-first CMS[7]。他喜歡攪動出黃油雙峰，以及構建讓開發者工作更舒適的工具，喜歡他的更多內容，請在 Twitter 上關註 @ButterCMS[8]，訂閱 他的部落格[9]。關於他的更多資訊[10]……

via: https://opensource.com/article/18/1/how-choose-between-monolith-microservices

作者：jakelumetta [10] 譯者：qhwdw 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出