原文:https://my.oschina.net/u/3636867/blog/1803023
作者:爛豬皮
一、微服務架構四大特性
好的微服務架構是什么樣的呢？想要搭建好一個微服務架構，必須要具備一下四個特征：
服務的粒度需根據業務功能來划分，對於某些復雜的業務來說，可能粒度較大，對於相對簡單的業務而言，可能粒度較小。總之，服務的粒度可大可小，但往往我們更希望它盡可能的小，但又不希望服務之間有任何的依賴，因此粒度的划分是非常考驗架構師水平的事情。
我們需要確保每個微服務只做一件事情，也就是我們經常提到的“單一職責原則”，該原則對服務的划分提供了指導方針。
每個服務相互隔離，且互不影響。也就是說，每個服務需在自己的進程中運行。眾所周知，進程之間是隔離的，是安全的，而進程內部或線程之間資源是共享的。換句話說，一個服務出了問題，不會影響到其它服務受到任何影響。
隨着業務功能不斷增多，服務的數量也會逐漸增加，我們需要對服務提供自動化部署與監控預警的能力，才能更加高效地管理服務。
二、搭建一個微服務架構
記得好久之前看到一個大牛說過：如果單體架構都搞不好，就別搞微服務架構。乍一看，這句很有道理，后來發現這句話是不太對的，因為微服務架構的目的就是為了降低系統的復雜性，所以 微服務架構應該比單體架構更簡單、更好實踐才對。
這篇文章，我們就分享一下如何搭建一個 簡單模式的微服務架構。
何謂微服務架構的簡單模式？
相對於大型互聯網平台動輒幾萬並發的訪問量，或者每天多次的在線版本發布，絕大多數企業和項目並沒有這樣的需求。他們關注的是如何更好地提高開發效率，如何更快地實現新需求，如何更便利地運維，等等。
微服務架構的簡單模式就是可以滿足以上需求的軟件架構方案。
相對於“完美”的微服務架構方案，微服務架構簡單模式可以暫且不用關注保障數據一致性的分布式事務技術、方便程序包在環境間（開發、測試、生產）遷移的配置中心組件、監控 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 服務發現框架。這個方案的最大問題是：部署和運維比較麻煩。
當下，隨着 Netflix 的微服務方案和 Spring Cloud 的興起與成熟，第二個方案 成為我們的首選。我們推薦使用 Eureka 做服務注冊中心，Ribbon 做客戶端服務發現和負載均衡。
這個選擇的最大好處是 簡單 + 實用 + 可控，不用引入額外的 Zookeeper、Etcd 做注冊中心，部署和運維也都比較簡單。從代碼上來說，使用起來也非常簡單。
只是，需要注意的是，這種方案一般是用來做 局域網內 的負載均衡，如果要為開放到互聯網的服務做負載均衡，可以使用 Nginx Upstream 來做。
在此我向大家推薦一個架構學習交流群。交流學習群號：575745314 里面會分享一些資深架構師錄制的視頻錄像：有Spring，MyBatis，Netty源碼分析，高並發、高性能、分布式、微服務架構的原理，JVM性能優化、分布式架構等這些成為架構師必備的知識體系。還能領取免費的學習資源，目前受益良多
下面是 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 通過“模塊”功能接入新的微服務：
所以，到最后，一個簡單模式的基於微服務架構的系統就可以長成這樣：
至此，基本的微服務架構已經搭建起來。下面來聊聊怎么解決微服務運維的問題。
在此我向大家推薦一個架構學習交流群。交流學習群號：575745314 里面會分享一些資深架構師錄制的視頻錄像：有Spring，MyBatis，Netty源碼分析，高並發、高性能、分布式、微服務架構的原理，JVM性能優化、分布式架構等這些成為架構師必備的知識體系。還能領取免費的學習資源，目前受益良多
運維難
微服務架構的運維問題，主要是相對於單體架構來說的。因為實施微服務架構后，整個系統的模塊一下子比原來多了很多，模塊變多后，部署和維護的工作量都會變大。所以，解決運維難的問題，可以先從 自動化 的角度來解決。
更進一步，如果希望更好地發揮微服務架構的優勢，規避缺點，則建議准備一個可靠的基礎設施，包含自動構建、自動部署、日志中心、健康檢查、性能監控等功能。
否則，很有可能會因為微服務架構的缺點導致我們的團隊喪失對微服務架構的信心，從而回到單體架構的老路上去。工欲善其事，必先利其器，這一點真的很重要。
持續集成
單體應用被微服務化后，很有可能從原來的一個程序包分成了 10 個、20 個甚至更多的程序包。那么，我們首先遇到的麻煩就是部署工作直接擴大了 10 - 20 倍。這時，持續集成的方法和工具就成了實施微服務架構的前提條件。我們在實踐過程中，利用基於 Docker 的容器服務平台自動部署整個系統的微服務。其過程如下圖：
配置中心
監控告警
除了以上模塊，我們還開發了一個模塊，用來探測應用程序的健康情況和性能，在主機、程序健康情況、程序性能等各種指標出現異常時，發送警報給運維人員。
最后
在這篇文章結束的時候，我們可以回過頭來看看，我們只需要在開發層面理解了注冊中心、服務發現、負載均衡、服務網關和管理端集成框架，在運維層面准備好持續集成工具、配置中心和監控告警工具，就可以很容易地落地微服務架構。