Re：从0开始的微服务架构--(二)快速快速体验微服务架构？--转
原文地址：https://mp.weixin.qq.com/s/QO1QDQWnjHZp8EvGDrxZvw
這是專題的第二篇文章，看看如何搭建一個簡單模式的微服務架構。
記得好久之前看到一個大牛說過：如果單體架構都搞不好，就別搞微服務架構。乍一看，這句很有道理，后來發現這句話是不太對的，因為微服務架構的目的就是為了降低系統的復雜性，所以 微服務架構應該比單體架構更簡單、更好實踐才對。
這篇文章，我們就分享一下如何搭建一個 簡單模式 的微服務架構。
什么是微服務架構的簡單模式？
相對于大型互聯網平臺動輒幾萬并發的訪問量，或者每天多次的在線版本發布，絕大多數企業和項目并沒有這樣的需求。他們關注的是如何更好地提高開發效率，如何更快地實現新需求，如何更便利地運維，等等。
微服務架構的簡單模式就是可以滿足以上需求的軟件架構方案。
相對于“完美”的微服務架構方案，微服務架構簡單模式可以暫且不用關注保障數據一致性的分布式事務技術、方便程序包在環境間（開發、測試、生產）遷移的配置中心組件、監控 API 調用情況的調用鏈組件、避免系統超載的斷路器組件、方便 API 管理和測試的 API 文檔框架、Zookeeper、Redis，以及各種 MQ。只需要關注常常談到的 注冊中心、服務發現、負載均衡 和 服務網關 即可。
如何將微服務架構的簡單模式落地？
落地微服務架構，重點就是發揚優點，克服缺點。如前篇文章《Re: 從 0 開始的微服務架構：（一）重識微服務架構》的對比所示，相對于單體架構，微服務架構最大的缺點是 上手難 和 運維難。
下面我們就來看看如何從這兩個方面入手，將微服務架構的簡單模式落地。
上手難
相對于傳統的單體架構，微服務架構一下子引入了太多的概念，讓新手有點無可適從。所以，我們更要去蕪存菁，理清楚哪些是自身需要的，哪些只是江湖上的傳說。下面就來看看哪些組件是開發一個微服務架構的系統所必需的。
首先說一下，使用微服務簡單模式進行開發的四個步驟：
第一步：沿用組織中現有的技術體系開發單一職責的微服務。
第二步：服務提供方將地址信息注冊到注冊中心，調用方將服務地址從注冊中心拉下來。
第三步：通過門戶后端（服務網關）將微服務 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 的容器服務平臺自動部署整個系統的微服務。其過程如下圖:
?
如果沒有微服務支撐平臺，也可以通過 Shell 腳本的形式來調用 Jenkins API 和 Docker API。
主要過程是:
調用 Jenkins 命令從代碼倉庫拉取代碼，并打包代碼。
調用 Docker /build 和 /images/push 命令構建鏡像，并將鏡像推送到私有鏡像倉庫中。
調用 Docker /containers/create 和 /containers/start 命令創建并啟動容器。
?配置中心
在開發 / 測試環境上，程序包已經被打包成 Docker 鏡像，如果能將通過測試的鏡像直接推到生產環境，可以直接省去為生產環境而重復進行的打包部署工作，豈不是很美？
如果需要達到這個效果，就需要將程序包打包成具有環境無關性，也就是說，在程序包里是不可以有環境相關的配置信息的，這也就引入了 配置中心 組件。
這個組件非常簡單，只是根據項目代號、環境代號和微服務代號來獲取微服務所需要的鍵值對。例如：
ProjectA_PRODUCTION_MicroService1_jdbc.connection.url。
使用配置中心還有一個很重要的附加價值，那就是可以做到不同環境的配置信息可以由不同的人來管理，加強了生產環境的配置信息的安全性，例如數據庫帳號和密碼。
這個模塊也有一些開源的項目可以參考，例如百度 disconf，Spring Cloud Config。而我們自己發楊了重復造輪子的精神，開發了一個配置中心微服務，以方便地與上面提到的 UPMS 進行整合。
注意：這一組件并不是微服務架構簡單模式的必需組件，只是建議使用。
?監控告警
單體應用被微服務化后，一個單體應用被拆成了很多個微服務，系統的健康巡檢、性能監控、業務指標健康、文件備份監控、數據庫備份監控、定時任務執行情況監控都變得困難。
所以，為了讓運維的同學能生活得踏實點，最好也能把監控平臺給建了。如果希望快速搭建監控平臺，可以考慮 Nagios，Zabbix。如果希望擴展性、可定制性更好，可以考慮使用以下組件搭建：
?
Collectd 是一款主機、數據庫、網絡、存儲指標采集器。GitHub 上 1653 個 Star。
Metrics 是一款牛逼的 JVM 指標采集器，提供了很多模塊可以為第三方庫或者應用提供輔助統計信息， 比如 Jetty， Logback，Log4j，Apache HttpClient，Ehcache，JDBI，Jersey，它還可以將度量數據發送給 Ganglia 和 Graphite 以提供圖形化的監控。GitHub 上 5000+ 個 Star。
CAdvisor 是一款 Docker 容器指標采集器，Google 出品。GitHub 上 6000 個 Star。
Grafana 是一款非常精美的開源儀表盤工具，支持 Graphite，InfluxDB ，MySQL 和 OpenTSDB 等多種數據源。GitHub 上 17000 個 Star。
InfluxDB 是一款優秀的開源分布式時序數據庫，目前在時序數據中排名第一，它的特性中，RETENTION POLICY 可以自動地清除不需要的歷史數據，很實用。GitHub 上 11175 個 Star。
除了以上模塊，我們還開發了一個模塊，用來探測應用程序的健康情況和性能，在主機、程序健康情況、程序性能等各種指標出現異常時，發送警報給運維人員。
總 * 結
在這篇文章結束的時候，我們可以回過頭來看看，我們只需要在開發層面理解了注冊中心、服務發現、負載均衡、服務網關和管理端集成框架，在運維層面準備好持續集成工具、配置中心和監控告警工具，就可以很容易地落地微服務架構，享受微服務架構帶來的精彩。祝大家玩得愉快。
轉載于:https://www.cnblogs.com/davidwang456/p/7517331.html
總結
以上是生活随笔為你收集整理的Re：从0开始的微服务架构--(二)快速快速体验微服务架构？--转的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 爬虫推荐的工具
- 下一篇： Re：从 0 开始的微服务架构--(四)