【譯者的話】otto.de是德國的一家網(wǎng)上購物網(wǎng)站，本篇前半部分主要介紹了幾個系統(tǒng)架構(gòu)以及它們的優(yōu)缺點，后半部分主要講解otto.de的微服務(wù)架構(gòu)。

在我們開始開發(fā)otto.de網(wǎng)上商店時，我們選擇了分布式垂直架構(gòu)。之前的工作經(jīng)驗告訴我們，一體化架構(gòu)(monolithic architecture)不能夠滿足不斷增長的需求。爆發(fā)式增長的數(shù)據(jù)，持續(xù)提高的負載和對系統(tǒng)的擴展，所有的這些強迫我們?nèi)ブ匦滤伎季W(wǎng)站的架構(gòu)。

這篇文章將會描述我們的解決辦法，還有我們這么做的原因。

一體化(Monoliths)

在項目剛開始的時候，團隊通常會考慮使用什么編程語言和合適的架構(gòu)。當(dāng)談到服務(wù)端應(yīng)用時，Java和Spring框架，Ruby on rails或者類似的框架通常會成為團隊的選擇。

選擇了語言和框架后，經(jīng)過一段時間的開發(fā)，一個簡單的應(yīng)用誕生了。與此同時，一體式架構(gòu)(macro-architecture)毫無爭議的成為了團隊的選擇。但是，這種架構(gòu)的缺點也漸漸地浮出了水面：

• 它導(dǎo)致了重量級微架構(gòu)(a heavyweight Micro Architecture)
• 負載均衡限制了應(yīng)用的可擴展性
• 系統(tǒng)的可維護性受到影響，尤其是那些大型應(yīng)用
• 零停機部署(Zero downtime deployment)變得非常的困難，尤其是那些有狀態(tài)的應(yīng)用(stateful application)
• 多個團隊開發(fā)效率低，并且需要額外的協(xié)調(diào)

當(dāng)然，這并不是說一個新的應(yīng)用一開始就變得巨大而混亂。在最開始的時候，新應(yīng)用結(jié)構(gòu)清晰，簡單易懂，可擴展性也高，它能夠很輕松的解決需求問題。在接下來的一段時間中，越來越多的代碼被編寫。為了應(yīng)對日益增長的復(fù)雜度，系統(tǒng)被分層，抽象，模塊，服務(wù)和框架被引入到系統(tǒng)中，最終變成了我們看到的樣子。

即便是中型的應(yīng)用(比如說一個50000的Java應(yīng)用)，一體化架構(gòu)也會漸漸地變得令人討厭，更不用說那些對擴展性要求較高的應(yīng)用了。

最終，曾經(jīng)輕量簡潔的應(yīng)用將會變成下一代開發(fā)者的噩夢。

分而治之

問題的關(guān)鍵在于，如何避免這種類型的開發(fā)，并且將輕量應(yīng)用好的那部分保留下來。換句話說，我們?nèi)绾文軌颢@得一個可持續(xù)發(fā)展的架構(gòu)，這個架構(gòu)在多年之后依舊能夠讓開發(fā)者保持高效開發(fā)。

在軟件的開發(fā)過程中，有許多關(guān)于結(jié)構(gòu)化代碼的概念：函數(shù)，方法，類，庫，框架等等。這些概念并不是程序運行所必須的，發(fā)明他們的原因是為了幫助開發(fā)者更好的理解他們的應(yīng)用。

目前軟件開發(fā)者已經(jīng)理解了這些概念，一個問題接踵而來：為什么這些概念僅僅被應(yīng)用于一個軟件?是什么阻礙我們將應(yīng)用拆分成多個低耦合的部分?

有三件事情我們需要牢記在心：

康威定律：軟件開發(fā)最開始時僅有一個團隊，根據(jù)康威定律，因此會產(chǎn)生一個應(yīng)用。(譯者注：可以參考圖片理解)

初始消耗：部署應(yīng)用，并讓它運行起來似乎是一個非常簡單的任務(wù)。實際上，你需要建立并管理VCS代碼庫，編譯文件，構(gòu)建管道，用于部署的程序，硬件，虛擬機，日志文件，監(jiān)控軟件等等。所有的這些都需要花費一定的時間去處理。

操作的復(fù)雜性：大型分布式系統(tǒng)比一個小型的負載均衡集群更難操作。

如果我們放手不管，由多個小型模塊組成的系統(tǒng)并不會出現(xiàn)，一個巨大而混亂的系統(tǒng)將會取而代之。這時候，致命的問題已然出現(xiàn)，然而悔之晚矣。

正常情況下，一個系統(tǒng)是否需要被擴展，是否需要處理巨大的代碼庫在初期是非常清楚的。然后當(dāng)你遇到以上提到的障礙，你要么沒嘗試解決他們，要么只能沉淪在無盡的苦果中。

在OTTO，在最開始的時候就花費了大量時間去建立4個跨職能的團隊，根據(jù)前面提到的康威定律，一個項目屬于4個團隊，最終就能產(chǎn)生一個由4模塊組成的應(yīng)用，這樣就避免了一體化應(yīng)用的誕生。

因為我們之前操作過大型的一體化應(yīng)用，操作的復(fù)雜性對于我們似乎是一個可以被解決的問題---操作200個一體化應(yīng)用和操作200個更小型的系統(tǒng)沒有太大的區(qū)別。

初始消耗可以通過標準化和自動化來克服。因為我們沒有提到云服務(wù)，你還需要做相關(guān)的基礎(chǔ)操作來啟動自動化服務(wù)。雖然有些麻煩，但做過一次后，一切將自動化，你會獲得巨大的便利。

可擴展性

如何將一體化應(yīng)用轉(zhuǎn)變?yōu)橛啥鄠€小模塊組成的應(yīng)用?首先，讓我們仔細想想一個應(yīng)用能夠從哪些維度進行擴展。

縱向分解(Vertical Decomposition)

縱向分解是一個非常自然而通用的方法，以至于常常被開發(fā)者所忽略。相比于把所有的功能集中到單一的應(yīng)用中，我們將應(yīng)用分解成了多個小模塊，它們相互獨立，互不影響。

我們可以根據(jù)業(yè)務(wù)域來分解系統(tǒng)。舉個例子來說，在otto.de我們就講網(wǎng)上商城分解成了11個不同的垂直模塊：后勤辦公室，產(chǎn)品，訂單等等。

每一個垂直模塊屬于一個單一團隊，它們有獨立的前端，后端和數(shù)據(jù)存儲。在模塊之間共享代碼是嚴令禁止的。當(dāng)然，在特殊的情況下，如果我們需要分享代碼，我們會建立一個開源的項目來解決該問題。

因此，每個垂直模塊是一個獨立自主的系統(tǒng)，就像Stefan Tikov在Substainable Architecture中提到的那樣。

#p#

分布式計算

一個垂直模塊依舊可能成為一個相對大型的一體化應(yīng)用，因此我們需要繼續(xù)對垂直模塊進行拆分。一種方法是將一個垂直模塊分解成更多的垂直模塊，另外一種方法是通過分布式計算將系統(tǒng)分解成多個模塊，不同的是這些模塊運行在他們自己的進程中，并且通過REST來傳遞信息。

在這種情況下，應(yīng)用不僅僅被垂直分解，同時還會被水平分解。這種架構(gòu)中，請求到達應(yīng)用后，對請求的處理會被分布于多個模塊中，然后每一模塊產(chǎn)生的結(jié)果匯總成一個響應(yīng)，發(fā)送回請求者。

這些模塊并不會共享一個數(shù)據(jù)庫架構(gòu)，因為這樣做會導(dǎo)致模塊間的緊密耦合：數(shù)據(jù)結(jié)構(gòu)的改變會使得一個模塊不能夠被獨立的部署。

分片

當(dāng)系統(tǒng)需要處理大量的數(shù)據(jù)，或者當(dāng)一個分布式的應(yīng)用被操作時，分片是很恰當(dāng)?shù)倪x擇。比如說，分片非常適合向全球范圍提供服務(wù)的應(yīng)用。

因為我們暫時沒有利用到分片這個概念，在這篇文章就不再詳細描述了。

負載均衡

每當(dāng)服務(wù)器承受不了巨大的負載壓力時，負載均衡就會容重登場。通過對一個應(yīng)用拷貝多次，同時利用負載均衡器將負載分解來緩解壓力。

在負載均衡中，不同實例的應(yīng)用通常會分時使用同一個數(shù)據(jù)庫，數(shù)據(jù)庫因此成為了系統(tǒng)的瓶頸，但是我們可以通過制定良好的擴展策略來避免這個問題。相比于關(guān)系數(shù)據(jù)庫，NoSQL能夠很好的處理擴展性的問題，這也就是NoSQL能夠在軟件世界中占據(jù)一畝三分地的原因之一。

最大的可擴展性

所有以上提到的辦法能夠組合在一起，能夠達到任何級別的可擴展性。

當(dāng)你沒有相應(yīng)的需求時，組合的結(jié)果會變得有點太復(fù)雜。幸運地是，開發(fā)者并不需要在一開始的時候就制定龐大的計劃，相反，他們可以循序漸進，一步步朝著目標架構(gòu)前進。

舉個例子來說，在otto.de，架構(gòu)一開始是4個垂直模塊加上負載均衡，在過去的三年里，產(chǎn)生了更多的垂直模塊。在此期間，某些模塊變得非常的巨大笨重。因此，我們引入了微服務(wù)架構(gòu)，同時通過擴展垂直模塊來建立分布式計算。

#p#

微服務(wù)(Microservices)

微服務(wù)最近變得非常的流行。微服務(wù)是一種架構(gòu)風(fēng)格，它能夠根據(jù)業(yè)務(wù)域?qū)⑾到y(tǒng)分解成多個細粒度，獨立的模塊。

在這種情況下，微服務(wù)可以是一個小的垂直模塊，或者是分布式計算機構(gòu)中的一個服務(wù)。與傳統(tǒng)方法的不同之處在于應(yīng)用的大小：一個微服務(wù)僅僅實現(xiàn)了一個業(yè)務(wù)域中的幾個功能，它結(jié)構(gòu)清晰，一個開發(fā)者能夠很輕松的掌握它。

一個微服務(wù)非常的小，因此多個微服務(wù)能夠運行在單一的服務(wù)器上。我們對“Fat JARs”有豐富的經(jīng)驗，通常能通過執(zhí)行java –jar 來執(zhí)行它們。如果需要的話，也能開啟一個Jetty或者類似的服務(wù)器。

為了簡化不同微服務(wù)的部署和操作問題，每一個服務(wù)器運行在獨立的Docker容器中。

REST和微服務(wù)架構(gòu)是一個很好的組合，它適合于構(gòu)建大型的系統(tǒng)。一個微服務(wù)可以負責(zé)提供REST資源，超媒體(hypermedia)可以用來解決服務(wù)發(fā)現(xiàn)的問題，在涉及到接口的版本控制，服務(wù)部署獨立性的情況下，媒體類型(media type)有很大的幫助。

總而言之，微服務(wù)架構(gòu)有許多的好處，比如說：

• 在微服務(wù)架構(gòu)下進行開發(fā)是非常有趣的：每幾周或者幾個月，你就可能開始一個新的開發(fā)項目。
• 由于微服務(wù)非常小，微服務(wù)架構(gòu)不需要重量級框架和過多的模板代碼。
• 他們能夠被獨立的部署。因此持續(xù)交付或者持續(xù)部署變得非常的簡單。
• 微服務(wù)架構(gòu)能夠支持多個獨立的團體同時開發(fā)。
• 開發(fā)者能夠為每一個服務(wù)選擇最恰當(dāng)?shù)拈_發(fā)語言。不用擔(dān)心對項目產(chǎn)生影響，開發(fā)者可以嘗試新的語言或者框架。但是需要注意，這并不意味這你能夠隨意行使這項權(quán)利。
• 因為微服務(wù)足夠小，只需消耗較少的資源就能將他們替換成新的項目。
• 這種架構(gòu)的可擴展性相比于一體化架構(gòu)顯得非常的好，每一個服務(wù)都能被獨立的擴展。

微服務(wù)架構(gòu)遵守敏捷開發(fā)的原則。一個不能完全滿足用戶的新特性不僅可以被迅速的創(chuàng)建，而且還能夠被快速的銷毀。

宏架構(gòu)和微架構(gòu)(Macro- and Micro-Architecture)

在微服務(wù)架構(gòu)中，哪一部分將難以改變?內(nèi)部模塊的擴展已經(jīng)不再是關(guān)鍵問題，最難以改變的事情是有關(guān)微服務(wù)架構(gòu)的決定，比如說如何將微服務(wù)整合到系統(tǒng)的方法，或者模塊間傳輸信息協(xié)議的選擇。

因此，otto.de嚴格區(qū)分了微架構(gòu)(micro-architecture)和宏架構(gòu)(macro-architecture)。微架構(gòu)都是關(guān)于垂直架構(gòu)或者微服務(wù)架構(gòu)的內(nèi)部結(jié)構(gòu)，并且全部交由各自的團隊全權(quán)處理。

但是，明確宏架構(gòu)的大體方向是有價值的：

• 垂直分解：系統(tǒng)被分割成多個垂直模塊，每一個模塊完全屬于一個特定的團隊。模塊與模塊之間的信息傳遞禁止在用戶請求的過程中進行，而必須在后臺執(zhí)行。
• RESTful架構(gòu)：不同服務(wù)之間的信息傳遞和整合只通過REST來執(zhí)行。
• 零分享架構(gòu)：服務(wù)間不會通過共享可變狀態(tài)(mutable state)來進行信息交換或者分享信息。沒有HTTP sessions，沒有中央數(shù)據(jù)存儲中心，沒有共享代碼。但是多個服務(wù)的實例之間有可能共享一個數(shù)據(jù)庫。
• 數(shù)據(jù)管理：對于每一個數(shù)據(jù)節(jié)點，只有一個系統(tǒng)負責(zé)管理。其他的系統(tǒng)只能通過REST API讀取數(shù)據(jù)，然后將需要的數(shù)據(jù)拷貝回自己的數(shù)據(jù)庫。

我們的架構(gòu)已經(jīng)熬過了一輪軟件開發(fā)周期，與此同時，我們開始標準化微服務(wù)使用的方式。

集成

目前為止，我已經(jīng)詳細說明了許多有關(guān)系統(tǒng)分解的內(nèi)容。但是，用戶體驗是我們的系統(tǒng)的最終目標，我們希望我們的應(yīng)用保持一致性，感覺就像是一個整體。

因此，問題來了：我們?nèi)绾文軌蚣梢粋€分布式的系統(tǒng)，同時讓用戶意識不到我們架構(gòu)的分布特性。

超鏈接

對于前端集成，最簡單的辦法就是使用超鏈接。

每一個服務(wù)負責(zé)不同的頁面，頁面的導(dǎo)航通過鏈接來實現(xiàn)。

AJAX

使用AJAX的目的也很明顯，它能夠通過Javascript重新加載頁面的不同內(nèi)容，并且將他們整合在特定的頁面。

主要注意的是，服務(wù)之間涉及到的依賴非常的小，服務(wù)互相之間需要對使用的URL和媒體類型(media type)保持一致性。

資源服務(wù)器(Asset Server)

當(dāng)然，圖片在不同頁面的顯示也需要保持一致性。除此之外，分布式的服務(wù)需要對他們各自的Javascript庫和版本保持一致。

為了保持一致性，在我們的系統(tǒng)中，靜態(tài)資源，比如說CSS，JS和圖片都是通過一個中央資源服務(wù)器來進行傳輸。

在垂直架構(gòu)，共享資源的部署和版本控制是一個完全不同的話題，這需要一篇獨立的文章來詳細解釋。在這里我們不做過多解釋，我們只需要記住，共享資源的同時保持服務(wù)獨立是具有非常大的挑戰(zhàn)性。

Edge-Side Includes

有一種不太知名的方法，它能整合不同服務(wù)的資源到同一個站點。這種方法我們稱之為Server-Side Includes或者是Edge-Side Includes。大多數(shù)的Web服務(wù)器或者反向代理都只支持這個功能。

這項技術(shù)非常的簡單：一個服務(wù)插入插入一條帶有URL的包含語句(include statement)。然后這個URL會被web服務(wù)器或者反向代理解析，代理根據(jù)URL獲取到一個響應(yīng)，然后用這個響應(yīng)代替頁面中的包含語句。

在我們的商城中，每一個頁面都包含了來自搜索&導(dǎo)航服務(wù)(SAN)的導(dǎo)航信息：

...

...

反向代理(我們使用了Varnish)解析了頁面，然后將URL分解出來，SAN根據(jù)URL提供相應(yīng)的HTML片段。

然后Varnish代理用這個HTML片段取代包含語句，并將重新生成的頁面發(fā)送回用戶。

在這種方式下，用戶根本意識不到頁面是由多個來自不同服務(wù)的片段組成的。

數(shù)據(jù)拷貝(Data Replication)

以上提到的技術(shù)僅僅解決了前端集成問題，現(xiàn)在我們來談?wù)劮?wù)端集成。不同的服務(wù)之間需要共同的數(shù)據(jù)，但是他們又不能共享同一個數(shù)據(jù)庫，因此我們想了一些辦法來處理這個問題。

數(shù)據(jù)拷貝就是一個辦法。比如說，其他的服務(wù)需要關(guān)于產(chǎn)品的數(shù)據(jù)，它們就會定期的向負責(zé)產(chǎn)品數(shù)據(jù)的垂直模塊(Product)請求數(shù)據(jù)，這樣產(chǎn)品數(shù)據(jù)的更新能夠很迅速的被其他服務(wù)檢測到。

我們沒有使用任何的消息隊列來向客戶端推送(push)數(shù)據(jù)。相反的，每當(dāng)服務(wù)需要更新數(shù)據(jù)時，它們會輪詢(poll)Atom Feed。

值得一提的是，某些不好的事情必須犧牲服務(wù)的可用性來避免，我們在開發(fā)過程中不得不面對這個矛盾。

沒有遠程服務(wù)調(diào)用(NO Remote Service Calls)

理論上來說，在某些情況下，我們可以避免數(shù)據(jù)的拷貝，這樣服務(wù)就能夠同步使用其他的服務(wù)了。一個購物籃并不需要保存額外的產(chǎn)品信息，相反它可以直接向產(chǎn)品模塊請求數(shù)據(jù)。

我們并沒有這么做，為什么呢?

當(dāng)一個系統(tǒng)的主要功能依賴于其它系統(tǒng)時，系統(tǒng)的可測試性受到影響。

一個緩慢的服務(wù)會影響到其它系統(tǒng)的請求，當(dāng)請求越多，雪球越滾越大，最終影響到了整個系統(tǒng)的可用性。

系統(tǒng)的可擴展性受到了限制。

獨立的服務(wù)部署變得非常的困難。

我們長期和垂直架構(gòu)打交道，我們非常明確的知道，在早期的時候，嚴格的界限會使得微服務(wù)的開發(fā)，測試，遷移變得更加獨立，方便。

經(jīng)驗教訓(xùn)

按照以上羅列的辦法，經(jīng)過三年的工作后，我們變得經(jīng)驗豐富。

回顧往事，如果我早點做這些事情，我們的一體化系統(tǒng)會變得更加的精細。現(xiàn)在，otto.de的未來屬于微服務(wù)。

原文鏈接：