如何快速搭建一個微服務架構？
微服務火了很久，但網上很少有文章能做到成熟地將技術傳播出來，同時完美地照顧“初入微服務領域人員”，從 0 開始，採用通俗易懂的語言去講解微服務架構的系列。所以，我們策劃了這篇文章。本文轉載自 InfoQ 垂直號「聊聊架構」，ID：archtime
記得好久之前看到一個大牛說過：如果單體架構都搞不好，就別搞微服務架構。乍一看，這句很有道理，後來發現這句話是不太對的，因為微服務架構的目的就是為了降低系統的複雜性，所以 微服務架構應該比單體架構更簡單、更好實踐才對。
這篇文章，我們就分享一下如何搭建一個 簡單模式的微服務架構。
何謂微服務架構的簡單模式？
相對於大型網際網路平臺動輒幾萬併發的訪問量，或者每天多次的線上版本釋出，絕大多數企業和專案並沒有這樣的需求。他們關注的是如何更好地提高開發效率，如何更快地實現新需求，如何更便利地運維，等等。
微服務架構的簡單模式就是可以滿足以上需求的軟體架構方案。
相對於“完美”的微服務架構方案，微服務架構簡單模式可以暫且不用關注保障資料一致性的分散式事務技術、方便程式包在環境間（開發、測試、生產）遷移的配置中心元件、監控 API 呼叫情況的呼叫鏈元件、避免系統超載的斷路器元件、方便 API 管理和測試的 API 文件框架、Zookeeper、Redis，以及各種 MQ。只需要關注常常談到的 註冊中心、服務發現、負載均衡和 服務閘道器即可。
如何落地？
落地微服務架構，重點就是發揚優點，克服缺點。相對於單體架構，微服務架構最大的缺點是 上手難 和 運維難。下面我們就來看看如何從這兩個方面入手，將微服務架構的簡單模式落地。
上手難
相對於傳統的單體架構，微服務架構一下子引入了太多的概念，讓新手有點無可適從。所以，我們更要去蕪存菁，理清楚哪些是自身需要的，哪些只是江湖上的傳說。下面就來看看哪些元件是開發一個微服務架構的系統所必需的。
首先說一下，使用微服務簡單模式進行開發的四個步驟：
第一步：沿用組織中現有的技術體系開發單一職責的微服務。
第二步：服務提供方將地址資訊註冊到註冊中心，呼叫方將服務地址從註冊中心拉下來。
第三步：通過門戶後端（服務閘道器）將微服務 API 暴露給門戶和移動 APP。
第四步：將管理端模組整合到統一的操作介面上。
為了實現以上 4 點，相對應的就是下面必需掌握的基礎技術（必需的元件）。
-
註冊中心、服務發現、負載均衡：對應上邊第一步與第二步
-
服務閘道器：對應上邊第三步
-
管理端整合框架：對應上邊第四步
註冊中心、服務發現、負載均衡
和單體架構不同，微服務架構是由一系列職責單一的細粒度服務構成的 分散式網狀結構，服務之間通過輕量機制進行通訊，這時候必然引入一個 服務註冊發現 問題，也就是說服務提供方要將自己的服務地址註冊到某個地方（服務註冊中心， Service Registry Center），服務的呼叫方可以從服務註冊中心找到需要呼叫的服務的地址（服務發現，Service Discovery）。同時，服務提供方一般以叢集方式提供服務，也就引入了 負載均衡 的需求。
根據負載均衡（Load Balancer，簡稱 LB）所在位置的不同，目前主要的服務註冊、發現和負載均衡方案有三種：
集中式 LB 方案
第一種是集中式 LB 方案，在服務消費者和服務提供者之間有一個獨立的 LB，LB 通常是專門的硬體裝置如 F5，或者基於軟體如 LVS，HAproxy 等實現。
服務呼叫者呼叫服務時，向 LB 發起請求，LB 再根據一定的策略（比如輪詢、隨機、最小響應時間、最小併發數等等）將請求路由到指定的服務。這個方案的最大問題是：呼叫者和提供者之間增加了一跳，LB 也最有可能成為整個系統的瓶頸。
程序內 LB 方案
第二種是程序內 LB 方案，針對集中式 LB 的不足，程序內 LB 方案將 LB 的功能以庫的形式整合到服務消費方程序裡頭，該方案也被稱為軟負載 (Soft Load Balancing) 或者客戶端負載方案。
其原理是：服務提供者將自身的地址傳送到服務註冊中心，同時定時傳送心跳給註冊中心，註冊中心按心跳情況判斷是否將此節點從登錄檔中摘除。服務呼叫者呼叫服務時，先從註冊中心拉取服務註冊資訊，然後根據一定的策略去呼叫服務節點。
這種情況下，即使註冊中心宕機，呼叫方也可以根據記憶體中已經拉到的服務地址將請求路由到正確的服務上去。這個方案的最大問題是：服務呼叫者可能需要整合註冊中心的客戶端，即將來註冊中心服務端升級，可能會需要升級註冊中心客戶端。
主機獨立 LB 程序方案
第三種是主機獨立 LB 程序方案，該方案是針對第二種方案的不足而提出的一種折中方案，原理和第二種方案基本類似，不同之處是，他將 LB 和服務發現功能從程序內移出來，變成主機上的一個獨立程序，主機上的一個或者多個服務要訪問目標服務時，他們都通過同一主機上的獨立 LB 程序做服務發現和負載均衡。該方案的典型案例是 Airbnb 的 SmartStack 服務發現框架。這個方案的最大問題是：部署和運維比較麻煩。
以上三點摘自楊波先生的《實施微服務，我們需要哪些基礎框架？》
http://www.infoq.com/cn/articles/basis-frameworkto-implement-micro-service#anch130564 ，
並作了部分補充，如果希望檢視這三個方案的更詳細說明，推薦讀一讀楊波先生的文章。
當下，隨著 Netflix 的微服務方案和 Spring Cloud 的興起與成熟，第二個方案 成為我們的首選。我們推薦使用 Eureka 做服務註冊中心，Ribbon 做客戶端服務發現和負載均衡。
這個選擇的最大好處是 簡單 + 實用 + 可控，不用引入額外的 Zookeeper、Etcd 做註冊中心，部署和運維也都比較簡單。從程式碼上來說，使用起來也非常簡單。
只是，需要注意的是，這種方案一般是用來做 區域網內 的負載均衡，如果要為開放到網際網路的服務做負載均衡，可以使用 Nginx Upstream 來做。
下面是 Eureka 最重要的幾個引數配置，從這些引數也可以大概看看 Eureka 是如何工作的。
由於 Eureka 的註冊及過期機制，服務從啟動到完全可用需要近 2 分鐘的時間，所以，為了提高開發及測試環境中的發版速度，我們改了以下幾個引數。生產時，一定要改回去。
Eureka 註冊中心的介面如下：
詳細資訊可參考
https://github.com/Netflix/eureka
和
https://github.com/Netflix/ribbon。
服務閘道器
通常，一個大系統裡會有很多職責單一的微服務，如果門戶系統或移動 APP 來呼叫這些微服務的 API 時，至少要做好兩件事：
-
由統一的入口來呼叫微服務的 API
-
API 鑑權
這就需要一個 服務閘道器。2015 年，我們使用 Rest Template + Ribbon 做了一個簡單的 API 閘道器。原理就是當 API 閘道器接到請求 /service1/api1.do 時，將請求轉發到 service1 對應的微服務的 api1 介面。
後來，發現我們實現的功能，Spring Cloud Zuul 都有比較好的實現，也就切換到 Zuul 上面去了。Zuul 是 Netflix 基於 Java 開發的服務端 API 閘道器和負載均衡器。
除此之外，Zuul 還可以對過濾器進行動態的載入、編譯、執行。最令人吃驚的是，Zuul 的轉發效能據說和 Nginx 差不多。詳細資訊可參考 https://github.com/Netflix/zuul。
總的來說，一般情況下，API 閘道器（可以稱為門戶後端）用來進行反向代理、許可權認證、資料剪裁、資料聚合等。
管理端整合框架
掌握註冊中心、服務發現、負載均衡和服務閘道器技術後，微服務已經可以為門戶系統和移動 APP 提供可靠服務。但是，給後臺運營人員使用的管理端是怎麼實現的呢？
由於後端運營系統的壓力不大，我們可以通過 CAS 和 UPMS（UPMS 是我們團隊研發的契合微服務架構的使用者及許可權管理系統，我們將分享到青柳雲官網，歡迎關注）將單獨開發的微服務整合起來。
三步整合一個微服務的基本過程就是：
-
在微服務中引入基於 Spring Boot 的 security starter，starter 裡包含了系統的頂端 Banner 和左側選單。
-
將微服務的訪問地址註冊到 UPMS 中，這個地址作為此微服務的入口選單（一級選單）。
-
在 UPMS 中配置微服務的功能選單及角色許可權資訊。
使用者從瀏覽器開啟一個微服務的時候，security starter 會呼叫 UPMS 的 API 拉取所有的微服務清單（一級選單）和當前微服務的功能清單（二級選單），並將當前微服務的頁面在內容區展現給使用者。
應用架構圖：
UPMS 截圖，橙色部分由 UPMS 框架提供，紅色框為微服務的頁面：
UPMS 通過“模組”功能接入新的微服務：
所以，到最後，一個簡單模式的基於微服務架構的系統就可以長成這樣：
至此，基本的微服務架構已經搭建起來。下面來聊聊怎麼解決微服務運維的問題。
運維難
微服務架構的運維問題，主要是相對於單體架構來說的。因為實施微服務架構後，整個系統的模組一下子比原來多了很多，模組變多後，部署和維護的工作量都會變大。所以，解決運維難的問題，可以先從 自動化 的角度來解決。
更進一步，如果希望更好地發揮微服務架構的優勢，規避缺點，則建議準備一個可靠的基礎設施，包含自動構建、自動部署、日誌中心、健康檢查、效能監控等功能。
否則，很有可能會因為微服務架構的缺點導致我們的團隊喪失對微服務架構的信心，從而回到單體架構的老路上去。工欲善其事，必先利其器，這一點真的很重要。
持續整合
單體應用被微服務化後，很有可能從原來的一個程式包分成了 10 個、20 個甚至更多的程式包。那麼，我們首先遇到的麻煩就是部署工作直接擴大了 10 - 20 倍。這時，持續整合的方法和工具就成了實施微服務架構的前提條件。我們在實踐過程中，利用基於 Docker 的容器服務平臺自動部署整個系統的微服務。其過程如下圖：
配置中心
ProjectA_PRODUCTION_MicroService1_jdbc.connection.url。
監控告警
除了以上模組，我們還開發了一個模組，用來探測應用程式的健康情況和效能，在主機、程式健康情況、程式效能等各種指標出現異常時，傳送警報給運維人員。
寫在最後
在這篇文章結束的時候，我們可以回過頭來看看，我們只需要在開發層面理解了註冊中心、服務發現、負載均衡、服務閘道器和管理端整合框架，在運維層面準備好持續整合工具、配置中心和監控告警工具，就可以很容易地落地微服務架構。