編譯 | 言征

出品 | 51CTO技術(shù)棧（微信號(hào)：blog51cto）

創(chuàng)業(yè)工程團(tuán)隊(duì)不僅必須考慮技術(shù)方面，還必須考慮微服務(wù)與整體服務(wù)的選擇如何與其業(yè)務(wù)目標(biāo)相一致。毫無疑問，關(guān)于這兩種方法的評(píng)論和分析有很多，本文中，我們將探討真實(shí)的案例，以便諸位做出自己的決定。

在創(chuàng)業(yè)公司的現(xiàn)實(shí)中，工程團(tuán)隊(duì)在為其軟件應(yīng)用程序選擇基礎(chǔ)架構(gòu)時(shí)往往處于十字路口。這個(gè)看似技術(shù)性的決定實(shí)際上遠(yuǎn)遠(yuǎn)超出了編碼領(lǐng)域，直接進(jìn)入了可以決定創(chuàng)業(yè)公司早期階段的戰(zhàn)略規(guī)劃。

這個(gè)決定的核心取決于一個(gè)關(guān)鍵問題：團(tuán)隊(duì)?wèi)?yīng)該為去中心化的微服務(wù)架構(gòu)奠定基礎(chǔ)，還是應(yīng)該選擇單體設(shè)計(jì)，讓整個(gè)應(yīng)用程序是統(tǒng)一且相互依賴的？

構(gòu)建一個(gè)系統(tǒng)，其設(shè)計(jì)本質(zhì)上是隨著創(chuàng)業(yè)公司的發(fā)展而不斷增長和適應(yīng)，這樣看，微服務(wù)相當(dāng)適配，其中的每個(gè)服務(wù)運(yùn)行其獨(dú)特的進(jìn)程并通過定義良好、輕量級(jí)的機(jī)制進(jìn)行通信。這種方法提供了許多優(yōu)勢(shì)，尤其是在團(tuán)隊(duì)能夠更新和部署單個(gè)組件而不中斷整個(gè)系統(tǒng)的情況下。

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

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

路徑對(duì)比鮮明，創(chuàng)業(yè)公司的工程團(tuán)隊(duì)必須仔細(xì)權(quán)衡他們的選擇，不僅要考慮技術(shù)方面，還要考慮他們的選擇如何與他們的業(yè)務(wù)目標(biāo)、團(tuán)隊(duì)能力和市場(chǎng)進(jìn)入的緊迫性相一致。

一、單體架構(gòu)的吸引力

單體架構(gòu)的特點(diǎn)是應(yīng)用程序只有一個(gè)統(tǒng)一的代碼庫，由于其簡(jiǎn)單性和高效性，對(duì)于創(chuàng)業(yè)公司而言非常有吸引力。這種架構(gòu)風(fēng)格中，所有組件都是相互連接和相互依賴的，簡(jiǎn)化了開發(fā)和部署過程。

1.案例研究：Stack Overflow

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

2.案例研究：Shopify

Shopify是科技行業(yè)的另一巨頭，它采用了模塊化單體的方法，所有代碼都放在一個(gè)代碼庫中，但進(jìn)行了模塊化以更好地管理。這種方法允許清晰地劃分業(yè)務(wù)領(lǐng)域，如訂單、運(yùn)輸和結(jié)算，每個(gè)領(lǐng)域都有自己的專用接口和數(shù)據(jù)所有權(quán)。維護(hù)一個(gè)單一的存儲(chǔ)庫和部署管道使得Shopify能夠獲得流線化維護(hù)和跨所有團(tuán)隊(duì)的合作的好處。

3.補(bǔ)充：我在一家共享自行車和滑板車初創(chuàng)公司的個(gè)人經(jīng)歷

根據(jù)我在一家共享單車和滑板車初創(chuàng)公司的個(gè)人經(jīng)驗(yàn)，采用單體架構(gòu)的決定導(dǎo)致了驚人的快速推出，僅用了四個(gè)月的時(shí)間。這種單體方法促進(jìn)了從簡(jiǎn)單原型到完整應(yīng)用程序的開發(fā)，包括信用卡支付、物聯(lián)網(wǎng)集成和必要的運(yùn)營工具。其簡(jiǎn)單性使我們能夠快速建立基礎(chǔ)設(shè)施，并保持對(duì)整個(gè)代碼庫的清晰理解。

這種簡(jiǎn)化的架構(gòu)使我們?cè)诎l(fā)布時(shí)能夠部署5000多輛自行車上路。此外，事實(shí)證明，它非常有效地?cái)U(kuò)大了服務(wù)規(guī)模以滿足我們經(jīng)歷的快速增長的用戶需求，在運(yùn)營的前六個(gè)月內(nèi)容納了超過100萬用戶。單體設(shè)計(jì)固有的靈活性和簡(jiǎn)單性對(duì)于高效、迅速地管理這些大規(guī)模和變化至關(guān)重要。

現(xiàn)在你可能會(huì)想：Shopify、Stack Overflow等巨頭，甚至作者個(gè)人的成功經(jīng)驗(yàn)……如果單體架構(gòu)那么好，還有必要繼續(xù)使用微服務(wù)嗎？當(dāng)然。別擔(dān)心，我有其他例子來豐富各位的視野，我們繼續(xù)。 

二、向微服務(wù)架構(gòu)的轉(zhuǎn)變

向微服務(wù)架構(gòu)的轉(zhuǎn)變代表著許多初創(chuàng)公司的戰(zhàn)略性轉(zhuǎn)變，尤其是在它們擴(kuò)大規(guī)模和發(fā)展的過程中。微服務(wù)的特點(diǎn)是分布式運(yùn)行，每個(gè)服務(wù)獨(dú)立運(yùn)行，這在可擴(kuò)展性、靈活性和適應(yīng)不斷變化的需求的能力方面具有顯著優(yōu)勢(shì)。

1.案例研究：Nubank

一個(gè)典型的例子是Nubank，這家公司從2013年成立之初就開始采用微服務(wù)架構(gòu)。這一決定違背了傳統(tǒng)的觀點(diǎn)，通常建議以單體架構(gòu)開始，以提高速度和簡(jiǎn)化初始開發(fā)過程。Nubank選擇從微服務(wù)開始是基于對(duì)其商業(yè)模式和市場(chǎng)的戰(zhàn)略評(píng)估。雖然這種方法最初減緩了他們的開發(fā)過程，但它允許他們投資于堅(jiān)實(shí)的基礎(chǔ)架構(gòu)，隨著他們開始擴(kuò)大規(guī)模和擴(kuò)展功能，這帶來了回報(bào)。

這個(gè)過程并非沒有挑戰(zhàn)。隨著對(duì)領(lǐng)域的深入了解，Nubank必須不斷調(diào)整和完善其服務(wù)邊界。這種持續(xù)的評(píng)價(jià)和調(diào)整過程比任何東西都更能說明微服務(wù)的動(dòng)態(tài)性質(zhì)，它允許持續(xù)改進(jìn)和優(yōu)化。

2.補(bǔ)充：健康科技初創(chuàng)公司

據(jù)本人在一家健康科技初創(chuàng)公司的經(jīng)驗(yàn)，采用了一種更有趣的方式：準(zhǔn)微服務(wù)架構(gòu)，這種架構(gòu)需要在高安全性、可擴(kuò)展性系統(tǒng)與小型團(tuán)隊(duì)的實(shí)用性之間取得平衡。這種方法與傳統(tǒng)微服務(wù)不同，將應(yīng)用程序劃分為可管理的層和部分，每個(gè)部分由一個(gè)專門的團(tuán)隊(duì)負(fù)責(zé)，以促進(jìn)問責(zé)制和專注性。

我們?cè)谝粋€(gè)單體數(shù)據(jù)訪問層上實(shí)施了這種架構(gòu)，集中了健康科技領(lǐng)域至關(guān)重要的高標(biāo)準(zhǔn)隱私和安全要求。這種設(shè)置允許團(tuán)隊(duì)獨(dú)立工作，而不需要單獨(dú)處理這些關(guān)鍵的合規(guī)方面。此外，我們使用單個(gè)單體存儲(chǔ)庫作為所有服務(wù)的存儲(chǔ)庫，并結(jié)合統(tǒng)一的部署管道。此外，為了應(yīng)對(duì)典型的微服務(wù)挑戰(zhàn)，我們開發(fā)了一種標(biāo)準(zhǔn)化、用戶友好的跨服務(wù)通信機(jī)制。該系統(tǒng)有效地緩解了低開發(fā)生產(chǎn)力、數(shù)據(jù)一致性等問題。

因此，準(zhǔn)微服務(wù)架構(gòu)的靈活性對(duì)于快速適應(yīng)不斷變化的需求和按需擴(kuò)展特定系統(tǒng)組件至關(guān)重要。

三、結(jié)論：基于關(guān)鍵因素做出決策

當(dāng)初創(chuàng)公司面臨選擇微服務(wù)還是單體架構(gòu)的關(guān)鍵決策時(shí)，有幾個(gè)關(guān)鍵因素需要考慮。

首先，工程團(tuán)隊(duì)的規(guī)模至關(guān)重要。較小的團(tuán)隊(duì)可能更容易在單體架構(gòu)中進(jìn)行管理和開發(fā)，而較大的團(tuán)隊(duì)可以利用微服務(wù)的分布式性質(zhì)同時(shí)處理不同的組件。

項(xiàng)目復(fù)雜性也起著重要作用：具有清晰且穩(wěn)定范圍的單體架構(gòu)可能更適合簡(jiǎn)單的項(xiàng)目，而復(fù)雜的、不斷發(fā)展的項(xiàng)目可能更適合微服務(wù)。

可擴(kuò)展性需求是另一個(gè)關(guān)鍵因素。如果需要快速擴(kuò)展，微服務(wù)提供了必要的靈活性和可擴(kuò)展性來適應(yīng)增長。然而，如果可擴(kuò)展性不是立即需要考慮的問題，單體的簡(jiǎn)單性可能更有優(yōu)勢(shì)。

當(dāng)前工具和技術(shù)趨勢(shì)的影響也不能忽視。支持微服務(wù)或單體架構(gòu)的工具和框架的可用性可以顯著影響開發(fā)和維護(hù)的便利性。

所有這些示例和推理背后的主要思想是鼓勵(lì)初創(chuàng)公司仔細(xì)評(píng)估其獨(dú)特的情況，并做出與業(yè)務(wù)目標(biāo)、團(tuán)隊(duì)動(dòng)態(tài)和競(jìng)爭(zhēng)格局相一致的選擇。

也許準(zhǔn)微服務(wù)架構(gòu)是更適合的方案？或者可能更傾向于嘗試其他方法？再次強(qiáng)調(diào)，微服務(wù)和單體架構(gòu)之間的選擇不僅僅是技術(shù)選擇，對(duì)所有因素的評(píng)估才是實(shí)現(xiàn)完美匹配的關(guān)鍵。