一體化架構和微服務架構
【譯者的話】otto.de是德國的一家網上購物網站，本篇前半部分主要介紹了幾個系統架構以及它們的優缺點，后半部分主要講解otto.de的微服務架構。
在我們開始開發otto.de網上商店時，我們選擇了分布式垂直架構。之前的工作經驗告訴我們，一體化架構（monolithic architecture）不能夠滿足不斷增長的需求。爆發式增長的數據，持續提高的負載和對系統的擴展，所有的這些強迫我們去重新思考網站的架構。
這篇文章將會描述我們的解決辦法，還有我們這么做的原因。
一體化（Monoliths）
在項目剛開始的時候，團隊通常會考慮使用什么編程語言和合適的架構。當談到服務端應用時，Java和Spring框架，Ruby on rails或者類似的框架通常會成為團隊的選擇。
選擇了語言和框架后，經過一段時間的開發，一個簡單的應用誕生了。與此同時，一體式架構（macro-architecture）毫無爭議的成為了團隊的選擇。但是，這種架構的缺點也漸漸地浮出了水面：
- 它導致了重量級微架構（a heavyweight Micro Architecture）
- 負載均衡限制了應用的可擴展性
- 系統的可維護性受到影響，尤其是那些大型應用
- 零停機部署（Zero downtime deployment）變得非常的困難，尤其是那些有狀態的應用（stateful application）
- 多個團隊開發效率低，并且需要額外的協調
當然，這并不是說一個新的應用一開始就變得巨大而混亂。在最開始的時候，新應用結構清晰，簡單易懂，可擴展性也高，它能夠很輕松的解決需求問題。 在接下來的一段時間中，越來越多的代碼被編寫。為了應對日益增長的復雜度，系統被分層，抽象，模塊，服務和框架被引入到系統中，最終變成了我們看到的樣 子。
即便是中型的應用（比如說一個50000的Java應用），一體化架構也會漸漸地變得令人討厭，更不用說那些對擴展性要求較高的應用了。
最終，曾經輕量簡潔的應用將會變成下一代開發者的噩夢。
分而治之
問題的關鍵在于，如何避免這種類型的開發，并且將輕量應用好的那部分保留下來。換句話說，我們如何能夠獲得一個可持續發展的架構，這個架構在多年之后依舊能夠讓開發者保持高效開發。
在軟件的開發過程中，有許多關于結構化代碼的概念：函數，方法，類，庫，框架等等。這些概念并不是程序運行所必須的，發明他們的原因是為了幫助開發者更好的理解他們的應用。
目前軟件開發者已經理解了這些概念，一個問題接踵而來：為什么這些概念僅僅被應用于一個軟件？是什么阻礙我們將應用拆分成多個低耦合的部分？
有三件事情我們需要牢記在心：
- 康威定律：軟件開發最開始時僅有一個團隊，根據康威定律，因此會產生一個應用。（譯者注：可以參考 圖片 理解）
- 初始消耗：部署應用，并讓它運行起來似乎是一個非常簡單的任務。實際上，你需要建立并管理VCS代碼庫，編譯文件，構建管道，用于部署的程序，硬件，虛擬機，日志文件，監控軟件等等。所有的這些都需要花費一定的時間去處理。
- 操作的復雜性：大型分布式系統比一個小型的負載均衡集群更難操作。
如果我們放手不管，由多個小型模塊組成的系統并不會出現，一個巨大而混亂的系統將會取而代之。這時候，致命的問題已然出現，然而悔之晚矣。
正常情況下，一個系統是否需要被擴展，是否需要處理巨大的代碼庫在初期是非常清楚的。然后當你遇到以上提到的障礙，你要么沒嘗試解決他們，要么只能沉淪在無盡的苦果中。
在OTTO，在最開始的時候就花費了大量時間去建立4個跨職能的團隊，根據前面提到的康威定律，一個項目屬于4個團隊，最終就能產生一個由4模塊組成的應用，這樣就避免了一體化應用的誕生。
因為我們之前操作過大型的一體化應用，操作的復雜性對于我們似乎是一個可以被解決的問題---操作200個一體化應用和操作200個更小型的系統沒有太大的區別。
初始消耗可以通過標準化和自動化來克服。因為我們沒有提到云服務，你還需要做相關的基礎操作來啟動自動化服務。雖然有些麻煩，但做過一次后，一切將自動化，你會獲得巨大的便利。
可擴展性
如何將一體化應用轉變為由多個小模塊組成的應用？首先，讓我們仔細想想一個應用能夠從哪些維度進行擴展。
縱向分解（Vertical Decomposition）
縱向分解是一個非常自然而通用的方法，以至于常常被開發者所忽略。相比于把所有的功能集中到單一的應用中，我們將應用分解成了多個小模塊，它們相互獨立，互不影響。
我們可以根據業務域來分解系統。舉個例子來說，在otto.de我們就講網上商城分解成了11個不同的垂直模塊：后勤辦公室，產品，訂單等等。
每一個垂直模塊屬于一個單一團隊，它們有獨立的前端，后端和數據存儲。在模塊之間共享代碼是嚴令禁止的。當然，在特殊的情況下，如果我們需要分享代碼，我們會建立一個開源的項目來解決該問題。
因此，每個垂直模塊是一個獨立自主的系統，就像Stefan Tikov在Substainable Architecture中提到的那樣。
分布式計算
一個垂直模塊依舊可能成為一個相對大型的一體化應用，因此我們需要繼續對垂直模塊進行拆分。一種方法是將一個垂直模塊分解成更多的垂直模塊，另外一種方法是通過分布式計算將系統分解成多個模塊，不同的是這些模塊運行在他們自己的進程中，并且通過REST來傳遞信息。
在這種情況下，應用不僅僅被垂直分解，同時還會被水平分解。這種架構中，請求到達應用后，對請求的處理會被分布于多個模塊中，然后每一模塊產生的結果匯總成一個響應，發送回請求者。
這些模塊并不會共享一個數據庫架構，因為這樣做會導致模塊間的緊密耦合：數據結構的改變會使得一個模塊不能夠被獨立的部署。
分片
當系統需要處理大量的數據，或者當一個分布式的應用被操作時，分片是很恰當的選擇。比如說，分片非常適合向全球范圍提供服務的應用。
因為我們暫時沒有利用到分片這個概念，在這篇文章就不再詳細描述了。
負載均衡
每當服務器承受不了巨大的負載壓力時，負載均衡就會容重登場。通過對一個應用拷貝多次，同時利用負載均衡器將負載分解來緩解壓力。
在負載均衡中，不同實例的應用通常會分時使用同一個數據庫，數據庫因此成為了系統的瓶頸，但是我們可以通過制定良好的擴展策略來避免這個問題。相比于關系數據庫，NoSQL能夠很好的處理擴展性的問題，這也就是NoSQL能夠在軟件世界中占據一畝三分地的原因之一。
最大的可擴展性
所有以上提到的辦法能夠組合在一起，能夠達到任何級別的可擴展性。
當你沒有相應的需求時，組合的結果會變得有點太復雜。幸運地是，開發者并不需要在一開始的時候就制定龐大的計劃，相反，他們可以循序漸進，一步步朝著目標架構前進。
舉個例子來說，在otto.de，架構一開始是4個垂直模塊加上負載均衡，在過去的三年里，產生了更多的垂直模塊。在此期間，某些模塊變得非常的巨大笨重。因此，我們引入了微服務架構，同時通過擴展垂直模塊來建立分布式計算。
微服務（Microservices）
微服務最近變得非常的流行。微服務是一種架構風格，它能夠根據業務域將系統分解成多個細粒度，獨立的模塊。
在這種情況下，微服務可以是一個小的垂直模塊，或者是分布式計算機構中的一個服務。與傳統方法的不同之處在于應用的大小：一個微服務僅僅實現了一個業務域中的幾個功能，它結構清晰，一個開發者能夠很輕松的掌握它。
一個微服務非常的小，因此多個微服務能夠運行在單一的服務器上。我們對“Fat JARs”有豐富的經驗，通常能通過執行java –jar <file>來執行它們。如果需要的話，也能開啟一個Jetty或者類似的服務器。
為了簡化不同微服務的部署和操作問題，每一個服務器運行在獨立的Docker容器中。
REST和微服務架構是一個很好的組合，它適合于構建大型的系統。一個微服務可以負責提供REST資源，超媒體（hypermedia）可以用來解決服務發現的問題，在涉及到接口的版本控制，服務部署獨立性的情況下，媒體類型（media type）有很大的幫助。
總而言之，微服務架構有許多的好處，比如說：
- 在微服務架構下進行開發是非常有趣的：每幾周或者幾個月，你就可能開始一個新的開發項目。
- 由于微服務非常小，微服務架構不需要重量級框架和過多的模板代碼。
- 他們能夠被獨立的部署。因此持續交付或者持續部署變得非常的簡單。
- 微服務架構能夠支持多個獨立的團體同時開發。
- 開發者能夠為每一個服務選擇最恰當的開發語言。不用擔心對項目產生影響，開發者可以嘗試新的語言或者框架。但是需要注意，這并不意味這你能夠隨意行使這項權利。
- 因為微服務足夠小，只需消耗較少的資源就能將他們替換成新的項目。
- 這種架構的可擴展性相比于一體化架構顯得非常的好，每一個服務都能被獨立的擴展。
微服務架構遵守敏捷開發的原則。一個不能完全滿足用戶的新特性不僅可以被迅速的創建，而且還能夠被快速的銷毀。
宏架構和微架構（Macro- and Micro-Architecture）
在微服務架構中，哪一部分將難以改變？內部模塊的擴展已經不再是關鍵問題，最難以改變的事情是有關微服務架構的決定，比如說如何將微服務整合到系統的方法，或者模塊間傳輸信息協議的選擇。
因此，otto.de嚴格區分了微架構（micro-architecture）和宏架構（macro-architecture）。微架構都是關于垂直架構或者微服務架構的內部結構，并且全部交由各自的團隊全權處理。
但是，明確宏架構的大體方向是有價值的：
- 垂直分解：系統被分割成多個垂直模塊，每一個模塊完全屬于一個特定的團隊。模塊與模塊之間的信息傳遞禁止在用戶請求的過程中進行，而必須在后臺執行。
- RESTful架構：不同服務之間的信息傳遞和整合只通過REST來執行。
- 零分享架構：服務間不會通過共享可變狀態（mutable state）來進行信息交換或者分享信息。沒有HTTP sessions，沒有中央數據存儲中心，沒有共享代碼。但是多個服務的實例之間有可能共享一個數據庫。
- 數據管理：對于每一個數據節點，只有一個系統負責管理。其他的系統只能通過REST API讀取數據，然后將需要的數據拷貝回自己的數據庫。
我們的架構已經熬過了一輪軟件開發周期，與此同時，我們開始標準化微服務使用的方式。
集成
目前為止，我已經詳細說明了許多有關系統分解的內容。但是，用戶體驗是我們的系統的最終目標，我們希望我們的應用保持一致性，感覺就像是一個整體。
因此，問題來了：我們如何能夠集成一個分布式的系統，同時讓用戶意識不到我們架構的分布特性。
超鏈接
對于前端集成，最簡單的辦法就是使用超鏈接。
每一個服務負責不同的頁面，頁面的導航通過鏈接來實現。
AJAX
使用AJAX的目的也很明顯，它能夠通過Javascript重新加載頁面的不同內容，并且將他們整合在特定的頁面。
主要注意的是，服務之間涉及到的依賴非常的小，服務互相之間需要對使用的URL和媒體類型（media type）保持一致性。
資源服務器（Asset Server）
當然，圖片在不同頁面的顯示也需要保持一致性。除此之外，分布式的服務需要對他們各自的Javascript庫和版本保持一致。
為了保持一致性，在我們的系統中，靜態資源，比如說CSS，JS和圖片都是通過一個中央資源服務器來進行傳輸。
在垂直架構，共享資源的部署和版本控制是一個完全不同的話題，這需要一篇獨立的文章來詳細解釋。在這里我們不做過多解釋，我們只需要記住，共享資源的同時保持服務獨立是具有非常大的挑戰性。
Edge-Side Includes
有一種不太知名的方法，它能整合不同服務的資源到同一個站點。這種方法我們稱之為Server-Side Includes或者是Edge-Side Includes。大多數的Web服務器或者反向代理都只支持這個功能。
這項技術非常的簡單：一個服務插入插入一條帶有URL的包含語句（include statement）。然后這個URL會被web服務器或者反向代理解析，代理根據URL獲取到一個響應，然后用這個響應代替頁面中的包含語句。
在我們的商城中，每一個頁面都包含了來自搜索&導航服務（SAN）的導航信息：
<html> ... <esi:include src=“/san/...“ /> ... </html>
反向代理（我們使用了Varnish）解析了頁面，然后將URL分解出來，SAN根據URL提供相應的HTML片段。
然后Varnish代理用這個HTML片段取代包含語句，并將重新生成的頁面發送回用戶。
在這種方式下，用戶根本意識不到頁面是由多個來自不同服務的片段組成的。
數據拷貝（Data Replication）
以上提到的技術僅僅解決了前端集成問題，現在我們來談談服務端集成。不同的服務之間需要共同的數據，但是他們又不能共享同一個數據庫，因此我們想了一些辦法來處理這個問題。
數據拷貝就是一個辦法。比如說，其他的服務需要關于產品的數據，它們就會定期的向負責產品數據的垂直模塊（Product）請求數據，這樣產品數據的更新能夠很迅速的被其他服務檢測到。
我們沒有使用任何的消息隊列來向客戶端推送（push）數據。相反的，每當服務需要更新數據時，它們會輪詢（poll）Atom Feed。
值得一提的是，某些不好的事情必須犧牲服務的可用性來避免，我們在開發過程中不得不面對這個矛盾。
沒有遠程服務調用（NO Remote Service Calls）
理論上來說，在某些情況下，我們可以避免數據的拷貝，這樣服務就能夠同步使用其他的服務了。一個購物籃并不需要保存額外的產品信息，相反它可以直接向產品模塊請求數據。
我們并沒有這么做，為什么呢？
- 當一個系統的主要功能依賴于其它系統時，系統的可測試性受到影響。
- 一個緩慢的服務會影響到其它系統的請求，當請求越多，雪球越滾越大，最終影響到了整個系統的可用性。
- 系統的可擴展性受到了限制。
- 獨立的服務部署變得非常的困難。
我們長期和垂直架構打交道，我們非常明確的知道，在早期的時候，嚴格的界限會使得微服務的開發，測試，遷移變得更加獨立，方便。
經驗教訓
按照以上羅列的辦法，經過三年的工作后，我們變得經驗豐富。
回顧往事，如果我早點做這些事情，我們的一體化系統會變得更加的精細。現在，otto.de的未來屬于微服務。
原文鏈接： On Monoliths and Microservices （翻譯：楊潤青）
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
譯者介紹
楊潤青，90后博士僧，研究方向是網絡和信息安全。