今天我們要談論微服務以及如何使用Nginx構建一個快速的、安全的網路系統。最後，我們將向您展示一個使用Fabric模式如何非常快速和輕鬆地構建一個微服務的demo。
在我們探討Fabric模式之前，我想談一談微服務並且從Nginx的角度來看這意味著什麼。
0：56 – 大轉變
微服務已經引起了應用程式架構的重大轉變。
當我第一次開始構建應用程式時，他們都是差不多的。幻燈片中所展示的單體架構也象徵了應用程式的構造方式。
目前存在著某種型別的虛擬機器（VM），對我來說，就是通常的Java。在虛擬機器中應用的功能元件以物件的形式存在，這些物件是在記憶體中相互通訊的，它們將來來回回處理並進行方法呼叫。偶爾，你會採用諸如通知等機制來接觸到其他系統以便獲取資料或傳遞資訊。
有了微服務之後，應用程式如何構建的正規化是完全不同的了。你的功能元件會從在同一個主機的記憶體中通過虛擬機器相互通訊轉變到部署在容器中，並且使用Restful API呼叫通過HTTP來相互連線。
這是非常強大的，因為它賦予了你功能隔離。它為您提供了更細粒度的可伸縮性，並且你可以獲得更好地處理故障的彈性。很多情況下這是簡單的事實，你只需要使用HTTP進行跨網路呼叫。
現在，這種方法也有一些缺點。
一件軼事

我有一個暗黑的祕密，我是一個微軟的員工並且從事.Net開發已經很多年了。當我在那兒的時候，我搭建了一個他們的名為Showcase的視訊釋出平臺。
Showcase是一個用來將微軟內部發布的所有視訊釋出到網上的工具。人們可以觀看這些視訊並進行學習，比如Microsoft Word的使用提示和技巧。這是一個非常受歡迎的平臺，我們有很多人使用它，並且其中很多人都會在我們釋出的視訊上發表評論。
Showcase從一開始就是一個.Net單體應用，隨著它日益受歡迎，我們決定應該將它更換為SOA架構。轉換是相對容易的。Visual Studio提供了本質上的翻轉開關的能力，也就是將你的DLL呼叫轉變為Restful API呼叫。隨著一些小的重構，我們能夠讓我們的程式碼執行得相當好。我們也為這些評論和應用內的社群功能使用智慧社群服務。
緊密的迴路問題

看起來我們是SOA可行的，在我們的首次測試中，一切都工作正常，直到我們將系統切換到我們的Staging環境並開始使用生產環境資料時，我們就會看到一些嚴重的問題。這些問題在在頁面上有很多評論。
這是一個非常受歡迎的平臺，其中的一些頁面已經有多達2000條評論了。當我們深入這些問題時，我們意識到這些頁面需要花費一分鐘進行渲染的原因是因為智慧社群服務首先需要填充使用者名稱，然後對每一個使用者名稱都需要發起一個對於使用者資料庫的網路呼叫來獲得使用者詳細資訊並且填充在渲染頁面上。這是非常低效的，需要一到兩分鐘來渲染頁面，而在記憶體中進行通常只需要5到6秒鐘。
緩解

當我們經歷了發現和解決問題的過程後，我們最終通過一些措施來調整優化系統，比如對所有的請求進行分組。我們快取了一些資料，最終我們優化了網路來真正的提高效能。
所以，這與微服務有什麼關係呢？對的，藉助於微服務，你基本上是採用SOA架構的，並且會將其放入超光速引擎中。在SOA架構中所有的物件都是包含在單個虛擬機器中並且在其內部管理，在記憶體中相互通訊，而現在微服務中是使用HTTP進行資料交換的。
當這樣做沒有問題時，你會獲得很好的效能和線性可伸縮性。
Nginx能夠很好地與微服務工作

Nginx是一個你可以用來過渡到微服務的最佳工具之一。
關於Nginx和微服務的一些歷史。我們從一開始就參與了微服務運動，還是第一個從Docker Hub下載應用的，我們的客戶以及那些擁有一些世界上最大的微服務安裝量的終端使用者廣泛地在他們的基礎設施使用Nginx。
原因是Nginx很小、很快並且很可靠。
Nginx微服務參考架構

我們還致力於在Nginx內部使用微服務工作已經有一段時間了。這是一個我們已經搭建的程式化的Nginx微服務參考架構，目前正在AWS上執行。
我們擁有6個核心的微服務，它們都執行在Docker容器裡。我們決定建立一個多語種的應用，所以每個容器都可以執行不同的語言，我們目前使用了Ruby、Python、PHP、Java和Node.js。
我們搭建了這個使用十二要素應用的系統，稍加修改，就會使其更好地為微服務工作從而可以替代Roku平臺。稍後，我們將向您展示一個實際上執行在demo裡的應用。
MRA的價值

為什麼我們要建立這樣一個參考的微服務架構呢？
我們建立這個參考架構是因為我們需要給我們的客戶提供構建微服務的藍圖，我們也想在微服務上下文中測試Nginx和Nginx Plus的功能，弄清楚如何才能更好地利用它的優勢。最後，我們要確保我們對於微服務生態系統以及其可以給我們提供什麼有一個深入的理解。
網路問題

讓我們回到我們討論的大轉變。
從將執行在記憶體裡並且被虛擬機器管理的你的應用的所有功能元件遷移到通過網路進行工作並且相互通訊的方式，你會本質上引入一系列為了應用有效工作需要你解決的問題。
第一你需要服務發現，第二，你需要在架構中為所有不同的例項進行負載均衡，然後還有第三個，你需要操心效能和安全。
無論是好是壞，這些問題密不可分，你必須做權衡，有希望的是我們有一個可以解決所有這些問題的解決方案。
讓我們更深入地看待每一個問題。
服務發現
讓我們來談談服務發現。在單體應用中，APP引擎會管理所有的物件關係，你永遠不必擔心一個物件與另一個物件的相對位置，你只需要簡單的呼叫一個方法，虛擬機器會連線到物件例項，然後在呼叫完畢後銷燬。
然後有了微服務，你需要考慮那些服務的位置。不幸的是，這不是一個普遍的標準流程。您正在使用的各種服務註冊中心，無論是Zookeeper、Consul、etcd或者其它的，都會以不同的方式進行工作。在這個過程中，你需要註冊你的服務，還需要能夠讀取這些服務在哪裡並且可以被連線。
負載均衡

第二個問題是關於負載均衡的。當您擁有多個服務例項時，您希望能夠輕鬆地連線到它們，將您的請求在它們中高效地分發，並以最快的方式執行，所以不同例項之間的負載均衡是非常重要的問題。
不幸的是，最簡單形式的負載均衡是非常低效的。當你開始使用不同的更加複雜的方案做負載均衡時，它也變得更加複雜並且不易於管理。理想情況下，您希望您的開發人員能夠基於他們的應用程式的需求決定何種負載均衡方案。例如，如果你連線到一個有狀態的應用程式，你需要擁有持久化，這樣可以確保你的Session資訊會被保留。
安全和快速通訊

也許微服務最令人生畏的領域是效能和安全。
當在記憶體中執行時，一切都很快。現在，執行在網路上就會慢了一個數量級。
被安全地包含在一個系統中的資訊，通常是二進位制格式的，現在會被用文字格式在網路上傳輸。現在是比較容易在網路上佈置嗅探器並能夠監聽你的應用正在被移動的所有資料。
如果要在傳輸層加密資料，那麼會在連線速率和CPU使用率方面引入顯著的開銷。SSL/TLS在其全面實施階段需要九個步驟來初始化一個請求。當你的系統每天需要處理成千上萬、幾萬、數十萬或數百萬的請求時，這就成為效能的一個重要障礙了。
一個解決方案

我們已經在Nginx開發的一些解決方案，我們認為，會解決所有的這些問題，它賦予你健壯的服務發現、非常棒的使用者可配置負載均衡以及安全和快速加密。
網路架構

讓我們來談談你可以安裝和配置你的網路架構的各種方法。
我們提出了三種網路模型，它們本身並不相互排斥，但我們認為它們屬於多種格式的。這三種模式是Proxy模式、Router Mesh模式和Fabric模式——這是最複雜的，並在許多方面在其頭部進行負載均衡。
Proxy模式

Proxy模式完全聚焦於你的微服務應用的入站流量，並且事實上忽略內部通訊。
你會獲得Nginx提供的所有的HTTP流量管理方面的福利。你可以有SSL/TLS終止、流量整形和安全，並且藉助於最新版本的Nginx Plus和ModSecurity，你可以獲得WAF能力。
你也可以快取，你可以將Nginx提供給你的單體應用的所有東西新增到你的微服務系統裡，並且藉助於Nginx Plus，你可以實現服務發現。當你的API例項上下浮動時，Nginx Plus可以在負載均衡工具裡動態地新增和減去它們。
Router Mesh模式

Router Mesh模式類似於Proxy模式，在其中我們有一個前端代理服務來管理接入流量，但它也在服務之間新增了集中式的負載均衡。
每個服務連線到集中式的Router Mesh，它管理不同服務之間的連線分發。Router Mesh模式還允許你在熔斷器模式中搭建，以便可以對你的應用新增彈性並允許你採取措施來監控和拉回你的失效的服務例項。
不幸的是，因為該模式增加了一個額外的環節，如果你不得不進行SSL/TLS加密，它事實上加劇了效能問題。這就是引入Fabric模式的原因。
Fabric模式

Fabric模式是將其頭部的所有東西翻轉的模式。
就像之前的另外兩個模式一樣，在前面會有一個代理伺服器來管理流入流量，但與Router Mesh模式不同的地方就是你用執行在每個容器裡的Nginx Plus來替代了集中式的Router。
這個Nginx Plus例項對於所有的HTTP流量作為反向和正向代理，使用這個系統，你可以獲得服務發現、健壯的負載均衡和最重要的高效能加密網路。
我們將探討這是如何發生的，以及我們如何處理這項工作。讓我們先來看看一個服務如何連線和分發他們的請求結構的正常流程。
正常的流程

在這個圖中，你可以看到投資管理器需要跟使用者管理器通訊來獲取資訊。投資管理器建立了一個HTTP客戶端，該客戶端針對服務註冊中心發起了一個DNS請求並獲得返回的一個IP地址，接著初始化了一個到使用者管理器的SSL/TLS連線，該連線需要通過九階段的協商或者是”握手”過程。一旦資料傳輸完畢，虛擬機器會關閉連線並進行HTTP客戶端的垃圾回收。
整個過程就是這樣。這是相當簡單和易於理解的。當你把它分解成這些步驟時，您可以看到該模式是如何真正完成請求和響應過程的。
在Fabric模式中，我們已經改變了這一點。
Fabric模式的細節

你會注意到的第一件事是Nginx Plus是執行在每一個服務裡的，並且應用程式程式碼是在本地與Nginx Plus通訊的。因為這些是本地連線，你不需要擔心加密問題。它們可以是從Java或者PHP程式碼到Nginx Plus例項的HTTP請求，並且都是在容器內的本地HTTP請求。
你也注意到Nginx Plus會管理到服務註冊中心的連線，我們有一個解析器，通過非同步查詢註冊中心的DNS例項來獲取所有的使用者管理器例項，並且預先建立連線，這樣當Java服務需要從使用者管理器請求一些資料的時候，可以使用預先建立的連線。
持久的SSL/TLS連線

微服務之間的有狀態的、持久化的並且可以加密的連線是真正的益處。
記得在第一個圖中服務例項是如何通過一些流程的吧，比如建立HTTP客戶端、協商SSL/TLS連線、發起請求並關閉的嗎？在這裡，Nginx預先建立了微服務之間的連線，並使用Keepalive特性，保持呼叫之間的持續連線，這樣你就不必為每一個請求處理SSL/TLS協商了。
本質上，我們建立了一個迷你的從服務到服務的VPN連線。在我們最初的測試中，我們發現連線速度增加了77%。
熔斷器Plus

在Fabric模式以及Router Mesh模式中，你也可以從建立和使用熔斷器模式中獲得好處。
本質上，您定義了一個在服務內部的活躍的健康檢查，並設定快取，以便在服務不可用的情況下保留資料，從而獲得完整的熔斷器功能。
所以，現在我可以確定你認為Fabirc模式聽起來很酷，並且想在實際環境中躍躍欲試。
Zokets Demo
我們已經和Zokets的合作伙伴一起工作了，他們幫助我們搭建了一個系統可以輕鬆地視覺化、控制並且自動化那些構建基於微服務的Fabric模式應用的流程。
我想介紹Zokets的CTO Sehyo Chang，他將幫助我們在他們的平臺上展示Fabric模式。
結論
對於那些有興趣學習更多關於如何構建這些型別的網路架構的小夥伴，我強烈推薦我們的部落格系列文章，上面討論了微服務參考架構，涵蓋了每一個模式：Proxu模式、Router Mesh模式和Fabric模式。
推薦一個交流學習群：650385180裡面會分享一些資深架構師錄製的視訊錄影：有Spring，MyBatis，Netty原始碼分析，高併發、高效能、分散式、微服務架構的原理，JVM效能優化這些成為架構師必備的知識體系。還能領取免費的學習資源，目前受益良多：