2018-05-30 10:59:19 Linux中國

編譯自： https://opensource.com/article/18/1/how-choose-between-monolith-microservices
譯者： qhwdw

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

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

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

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

理解範圍

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

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

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

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

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

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

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

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

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

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

我們想為每個服務使用最好的工具。我們的搜索 API 是在底層做過高度優化的，而 C++ 是非常適合這項工作的。他說，在任何其它地方都使用 C++ 是一種生產力的浪費，尤其是在構建儀表板方面。
我們希望使用最好的人才，而只使用一種技術將極大地限制我們的選擇。這就是為什麼在公司中有不同語言的原因。

”

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

權衡利弊

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

整體服務

優點：

很少擔心橫向聯繫：大多數應用程序開發者都擔心橫向聯繫，比如，日誌、速度限制、以及像審計跟蹤和 DoS 防護這樣的安全特性。當所有的東西都運行在同一個應用程序中時，通過組件鉤子來處理這些關注點就非常容易了。
運營開銷很少：只需要為一個應用程序設置日誌、監視、以及測試。一般情況下，部署也相對要簡單。
性能：一個整體的架構可能會有更好的性能，因為共享內存的訪問速度要比進程間通訊（IPC）更快。

缺點：

緊耦合：整體服務的應用程序傾向於緊耦合，並且應用程序是整體進化的，分離特定用途的服務是非常困難的，比如，獨立擴展或者代碼維護。
理解起來很困難：當你想查看一個特定的服務或者控制器時，因為依賴、副作用、和其它的不可預見因素，整體架構理解起來更困難。

微服務

優點：

非常好組織：微服務架構一般很好組織它們，因為每個微服務都有一個特定的工作，並且還不用考慮其它組件的工作。
解耦合：解耦合的服務是能夠非常容易地進行重組織和重配置，以服務於不同的應用程序（比如，同時向 Web 客戶端和公共 API 提供服務）。它們在一個大的集成系統中，也允許快速、獨立分發單個部分。
性能：根據組織的情況，微服務可以提供更好的性能，因為你可以分離熱點服務，並根據其餘應用程序的情況來擴展它們。
更少的錯誤：微服務允許系統中的不同部分，在維護良好邊界的前提下進行並行開發。這樣將使連接不該被連接的部分變得更困難，比如，需要連接的那些緊耦合部分。

缺點：

跨每個服務的橫向聯繫點：由於你構建了一個新的微服務架構，你可能會發現在設計時沒有預料到的很多橫向聯繫的問題。這也將導致需要每個橫向聯繫點的獨立模塊（比如，測試）的開銷增加，或者在其它服務層面因封裝橫向聯繫點，所導致的所有流量都需要路由。最終，即便是整體服務架構也傾向於通過橫向聯繫點的外部服務層來路由流量，但是，如果使用整體架構，在項目更加成熟之前，也不過只是推遲了工作成本。
更高的運營開銷：微服務在它所屬的虛擬機或容器上部署非常頻繁，導致虛擬機爭用激增。這些任務都是使用容器管理工具進行頻繁的自動化部署的。

決策時刻

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

你是在熟悉的領域嗎？

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

你的團隊做好準備了嗎？

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

你的基礎設施怎麼樣？

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

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

評估業務風險

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

態勢感知

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

什麼時候使用整體服務

你的團隊還在創建階段：你的團隊很小 —— 也就是說，有 2 到 5 位成員 —— 還無法應對大範圍、高成本的微服務架構。
你正在構建的是一個未經證實的產品或者概念驗證：如果你將一個全新的產品推向市場，隨著時間的推移，它有可能會成功，而對於一個快速迭代的產品，整體架構是最合適的。這個提示也同樣適用於概念驗證，你的目標是儘可能快地學習，即便最終你可能會放棄它。
你沒有使用微服務的經驗：除非你有合理的理由證明早期學習階段的風險可控，否則，一個整體的架構更適用於一個沒有經驗的團隊。

什麼時候開始使用微服務

你需要快速、獨立的分發服務：微服務允許在一個大的集成系統中快速、獨立分發單個部分。請注意，根據你的團隊規模，獲取與整體服務的比較優勢，可能需要一些時間。
你的平臺中的某些部分需要更高效：如果你的業務要求集中處理 PB 級別的日誌卷，你可能需要使用一個像 C++ 這樣的更高效的語言來構建這個服務，儘管你的用戶儀表板或許還是用 Ruby on Rails 構建的。
計劃擴展你的團隊：使用微服務，將讓你的團隊從一開始就開發獨立的小服務，而服務邊界獨立的團隊更易於按需擴展。

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