編譯 | 言征

出品 | 51CTO技術棧（微信號：blog51cto）

創業工程團隊不僅必須考慮技術方面，還必須考慮微服務與整體服務的選擇如何與其業務目標相一致。毫無疑問，關于這兩種方法的評論和分析有很多，本文中，我們將探討真實的案例，以便諸位做出自己的決定。

在創業公司的現實中，工程團隊在為其軟件應用程序選擇基礎架構時往往處于十字路口。這個看似技術性的決定實際上遠遠超出了編碼領域，直接進入了可以決定創業公司早期階段的戰略規劃。

這個決定的核心取決于一個關鍵問題：團隊應該為去中心化的微服務架構奠定基礎，還是應該選擇單體設計，讓整個應用程序是統一且相互依賴的？

構建一個系統，其設計本質上是隨著創業公司的發展而不斷增長和適應，這樣看，微服務相當適配，其中的每個服務運行其獨特的進程并通過定義良好、輕量級的機制進行通信。這種方法提供了許多優勢，尤其是在團隊能夠更新和部署單個組件而不中斷整個系統的情況下。

然而過早地采用微服務，并不十分明智。尤其是在時間至關重要且創業公司需要迅速建立自己作為可靠和可行的業務的情況下。設計、部署和維護微服務網絡的復雜性是一項重大任務，經常被許多人低估。這種復雜性可能會帶來意外的延遲、增加停機風險，并要求初創公司可能仍然需要具備一定水平的運營成熟度。

相比之下，單體架構（通常被視為傳統或過時）可堪一用，尤其是對于處于初級階段的創業公司。單體應用程序中，所有組件都是相互連接和相互依賴的，為開發提供了一個簡單直接、統一的模型。這種方法可以大大簡化開發過程，縮短上市時間，并允許快速原型制作和迭代——這對于需要迅速證明其業務模式的可行性的創業公司來說是至關重要的因素。

路徑對比鮮明，創業公司的工程團隊必須仔細權衡他們的選擇，不僅要考慮技術方面，還要考慮他們的選擇如何與他們的業務目標、團隊能力和市場進入的緊迫性相一致。

一、單體架構的吸引力

單體架構的特點是應用程序只有一個統一的代碼庫，由于其簡單性和高效性，對于創業公司而言非常有吸引力。這種架構風格中，所有組件都是相互連接和相互依賴的，簡化了開發和部署過程。

1.案例研究：Stack Overflow

Stack Overflow選擇單體架構無疑說明了這種方法的強大之處。盡管它每秒處理超過6000個請求，每月頁面瀏覽量達到20億次，但Stack Overflow仍然通過一個運行在IIS上的單一應用程序進行操作，為200個網站提供服務，并表現出卓越的效率。這種設置由一個單一的SQL Server組成，該服務器由廣泛的緩存和精簡的技術堆棧支持，由一個只有50名工程師的團隊進行管理。他們能夠快速部署更新，每天多次部署，這展示了結構良好的單體系統可以提供的運營靈活性。

2.案例研究：Shopify

Shopify是科技行業的另一巨頭，它采用了模塊化單體的方法，所有代碼都放在一個代碼庫中，但進行了模塊化以更好地管理。這種方法允許清晰地劃分業務領域，如訂單、運輸和結算，每個領域都有自己的專用接口和數據所有權。維護一個單一的存儲庫和部署管道使得Shopify能夠獲得流線化維護和跨所有團隊的合作的好處。

3.補充：我在一家共享自行車和滑板車初創公司的個人經歷

根據我在一家共享單車和滑板車初創公司的個人經驗，采用單體架構的決定導致了驚人的快速推出，僅用了四個月的時間。這種單體方法促進了從簡單原型到完整應用程序的開發，包括信用卡支付、物聯網集成和必要的運營工具。其簡單性使我們能夠快速建立基礎設施，并保持對整個代碼庫的清晰理解。

這種簡化的架構使我們在發布時能夠部署5000多輛自行車上路。此外，事實證明，它非常有效地擴大了服務規模以滿足我們經歷的快速增長的用戶需求，在運營的前六個月內容納了超過100萬用戶。單體設計固有的靈活性和簡單性對于高效、迅速地管理這些大規模和變化至關重要。

現在你可能會想：Shopify、Stack Overflow等巨頭，甚至作者個人的成功經驗……如果單體架構那么好，還有必要繼續使用微服務嗎？當然。別擔心，我有其他例子來豐富各位的視野，我們繼續。 

二、向微服務架構的轉變

向微服務架構的轉變代表著許多初創公司的戰略性轉變，尤其是在它們擴大規模和發展的過程中。微服務的特點是分布式運行，每個服務獨立運行，這在可擴展性、靈活性和適應不斷變化的需求的能力方面具有顯著優勢。

1.案例研究：Nubank

一個典型的例子是Nubank，這家公司從2013年成立之初就開始采用微服務架構。這一決定違背了傳統的觀點，通常建議以單體架構開始，以提高速度和簡化初始開發過程。Nubank選擇從微服務開始是基于對其商業模式和市場的戰略評估。雖然這種方法最初減緩了他們的開發過程，但它允許他們投資于堅實的基礎架構，隨著他們開始擴大規模和擴展功能，這帶來了回報。

這個過程并非沒有挑戰。隨著對領域的深入了解，Nubank必須不斷調整和完善其服務邊界。這種持續的評價和調整過程比任何東西都更能說明微服務的動態性質，它允許持續改進和優化。

2.補充：健康科技初創公司

據本人在一家健康科技初創公司的經驗，采用了一種更有趣的方式：準微服務架構，這種架構需要在高安全性、可擴展性系統與小型團隊的實用性之間取得平衡。這種方法與傳統微服務不同，將應用程序劃分為可管理的層和部分，每個部分由一個專門的團隊負責，以促進問責制和專注性。

我們在一個單體數據訪問層上實施了這種架構，集中了健康科技領域至關重要的高標準隱私和安全要求。這種設置允許團隊獨立工作，而不需要單獨處理這些關鍵的合規方面。此外，我們使用單個單體存儲庫作為所有服務的存儲庫，并結合統一的部署管道。此外，為了應對典型的微服務挑戰，我們開發了一種標準化、用戶友好的跨服務通信機制。該系統有效地緩解了低開發生產力、數據一致性等問題。

因此，準微服務架構的靈活性對于快速適應不斷變化的需求和按需擴展特定系統組件至關重要。

三、結論：基于關鍵因素做出決策

當初創公司面臨選擇微服務還是單體架構的關鍵決策時，有幾個關鍵因素需要考慮。

首先，工程團隊的規模至關重要。較小的團隊可能更容易在單體架構中進行管理和開發，而較大的團隊可以利用微服務的分布式性質同時處理不同的組件。

項目復雜性也起著重要作用：具有清晰且穩定范圍的單體架構可能更適合簡單的項目，而復雜的、不斷發展的項目可能更適合微服務。

可擴展性需求是另一個關鍵因素。如果需要快速擴展，微服務提供了必要的靈活性和可擴展性來適應增長。然而，如果可擴展性不是立即需要考慮的問題，單體的簡單性可能更有優勢。

當前工具和技術趨勢的影響也不能忽視。支持微服務或單體架構的工具和框架的可用性可以顯著影響開發和維護的便利性。

所有這些示例和推理背后的主要思想是鼓勵初創公司仔細評估其獨特的情況，并做出與業務目標、團隊動態和競爭格局相一致的選擇。

也許準微服務架構是更適合的方案？或者可能更傾向于嘗試其他方法？再次強調，微服務和單體架構之間的選擇不僅僅是技術選擇，對所有因素的評估才是實現完美匹配的關鍵。