Re:從0開始的微服務架構--(二)快速快速體驗微服務架構?--轉

原文地址:https://mp.weixin.qq.com/s/QO1QDQWnjHZp8EvGDrxZvwios

這是專題的第二篇文章,看看如何搭建一個簡單模式的微服務架構git

記得很久以前看到一個大牛說過:若是單體架構都搞很差,就別搞微服務架構。乍一看,這句頗有道理,後來發現這句話是不太對的,由於微服務架構的目的就是爲了下降系統的複雜性,因此 微服務架構應該比單體架構更簡單、更好實踐纔對github

這篇文章,咱們就分享一下如何搭建一個 簡單模式 的微服務架構。數據庫

什麼是微服務架構的簡單模式?後端

相對於大型互聯網平臺動輒幾萬併發的訪問量,或者天天屢次的在線版本發佈,絕大多數企業和項目並無這樣的需求。他們關注的是如何更好地提升開發效率,如何更快地實現新需求,如何更便利地運維,等等。api

微服務架構的簡單模式就是能夠知足以上需求的軟件架構方案。瀏覽器

相對於「完美」的微服務架構方案,微服務架構簡單模式能夠暫且不用關注保障數據一致性的分佈式事務技術、方便程序包在環境間(開發、測試、生產)遷移的配置中心組件、監控 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 是咱們團隊研發的契合微服務架構的用戶及權限管理系統,咱們將分享到青柳雲官網,歡迎關注)將單獨開發的微服務整合起來。

三步集成一個微服務的基本過程就是:

  1. 在微服務中引入基於 Spring Boot 的 security starter,starter 裏包含了系統的頂端 Banner 和左側菜單。

  2. 將微服務的訪問地址註冊到 UPMS 中,這個地址做爲此微服務的入口菜單(一級菜單)。

  3. 在 UPMS 中配置微服務的功能菜單及角色權限信息。

用戶從瀏覽器打開一個微服務的時候,security starter 會調用 UPMS 的 API 拉取全部的微服務清單(一級菜單)和當前微服務的功能清單(二級菜單),並將當前微服務的頁面在內容區展示給用戶。

應用架構圖:

 

UPMS 截圖,橙色部分由 UPMS 框架提供,紅色框爲微服務的頁面:

 

UPMS 經過「模塊」功能接入新的微服務:

 

因此,到最後,一個簡單模式的基於微服務架構的系統就能夠長成這樣:

 

至此,基本的微服務架構已經搭建起來。下面來聊聊怎麼解決微服務運維的問題。

運維難

微服務架構的運維問題,主要是相對於單體架構來講的。由於實施微服務架構後,整個系統的模塊一會兒比原來多了不少,模塊變多後,部署和維護的工做量都會變大。因此,解決運維難的問題,能夠先從 自動化 的角度來解決。

更進一步,若是但願更好地發揮微服務架構的優點,規避缺點,則建議準備一個可靠的基礎設施,包含自動構建、自動部署、日誌中心、健康檢查、性能監控等功能。

不然,頗有可能會由於微服務架構的缺點致使咱們的團隊喪失對微服務架構的信心,從而回到單體架構的老路上去。工欲善其事,必先利其器,這一點真的很重要

 持續集成

單體應用被微服務化後,頗有可能從原來的一個程序包分紅了 10 個、20 個甚至更多的程序包。那麼,咱們首先遇到的麻煩就是部署工做直接擴大了 10 - 20 倍。這時,持續集成的方法和工具就成了實施微服務架構的前提條件。咱們在實踐過程當中,利用基於 Docker 的容器服務平臺自動部署整個系統的微服務。其過程以下圖:

 

若是沒有微服務支撐平臺,也能夠經過 Shell 腳本的形式來調用 Jenkins API 和 Docker API。

主要過程是:

  1. 調用 Jenkins 命令從代碼倉庫拉取代碼,並打包代碼。

  2. 調用 Docker /build 和 /images/push 命令構建鏡像,並將鏡像推送到私有鏡像倉庫中。

  3. 調用 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。

除了以上模塊,咱們還開發了一個模塊,用來探測應用程序的健康狀況和性能,在主機、程序健康狀況、程序性能等各類指標出現異常時,發送警報給運維人員。

總 * 結

在這篇文章結束的時候,咱們能夠回過頭來看看,咱們只須要在開發層面理解了註冊中心、服務發現、負載均衡、服務網關和管理端集成框架,在運維層面準備好持續集成工具、配置中心和監控告警工具,就能夠很容易地落地微服務架構,享受微服務架構帶來的精彩。祝你們玩得愉快。

相關文章
相關標籤/搜索