一線架構師詳解微服務技術架構、監控、Docker、服務治理等體系

1.什麼是微服務

  1. 一組小的服務(大小沒有特別的標準,只要同一團隊的工程師理解服務的標識一致即可)
  2. 獨立的進程(java的tomcat,nodejs等)
  3. 輕量級的通信(不是soap,是http協議)
  4. 基於業務能力(類似用戶服務,商品服務等等)
  5. 獨立部署(迭代速度快)
  6. 無集中式管理(無須統一技術棧,可以根據不同的服務或者團隊進行靈活選擇)

2. 怎麼權衡微服務的利於弊

  • 強模塊邊界 。(模塊化的演化過程:類-->組件/類庫(sdk)-->服務(service),方式越來越靈活)
  • 可獨立部署。
  • 技術多樣性。

  • 分佈式複雜性。
  • 最終一致性。(各個服務的團隊,數據也是分散式治理,會出現不一致的問題)
  • 運維複雜性。
  • 測試複雜性。

3. 企業在什麼時候考慮引入微服務

從生產力和系統的複雜性這兩個方面來看。公司一開始的時候,業務複雜性不高,這時候是驗證商業模式的時候,業務簡單,用單體服務反而生產力很高。隨著公司的發展,業務複雜性慢慢提高,這時候就可以採用微服務來提升生產力了。至於這個轉化的點,需要團隊的架構師來進行各方面衡量,就個人經驗而言,團隊發展到百人以上,採用微服務就很有必要了。

有些架構師是具有微服務架構能力,所以設計系統時就直接設計成了微服務,而不是通過單服務慢慢演化發展成微服務。在這裡我並不推薦這種做法,因為一開始對業務領域並不是很瞭解,並且業務模式還沒有得到驗證,這時候上微服務風險比較高,很有可能失敗。所以建議大家在單服務的應用成熟時,並且對業務領域比較熟悉的時候,如果發現單服務無法適應業務發展時,再考慮微服務的設計和架構。

4.微服務的組織架構

一線架構師詳解微服務技術架構、監控、Docker、服務治理等體系

如上圖左邊,傳統的企業中,團隊是按職能劃分的。開發一個項目時,會從不同的職能團隊找人進行開發,開發完成後,再各自回到自己的職能團隊,這種模式實踐證明,效率還是比較低的。

如上圖右邊,圍繞每個業務線或產品,按服務劃分團隊。團隊成員從架構到運維,形成一個完整的閉環。一直圍繞在產品周圍,進行不斷的迭代。不會像傳統的團隊一樣離開。這樣開發效率會比較高。至於這種團隊的規模,建議按照亞馬遜的兩個披薩原則,大概10人左右比較好。

5:怎麼理解中臺戰略和微服務

中臺戰略的由來:馬雲2015年去歐洲的一家公司supersell參觀,發現這個公司的創新能力非常強,團隊的規模很小,但是開發效率很高。他們就是採用中臺戰略。馬雲感觸很深,回國後就在集團內部推出了中臺戰略。

一線架構師詳解微服務技術架構、監控、Docker、服務治理等體系

簡單的理解就是把傳統的前後臺體系中的後臺進行了細分。阿里巴巴提出了大中臺小前臺的戰略。就是強化業務和技術中臺,把前端的應用變得更小更靈活。當中臺越強大,能力就越強,越能更好的快速響應前臺的業務需求。打個比喻,就是土壤越肥沃,越適合生長不同的生物,打造好的生態系統。

6:服務分層

每個公司的服務分層都不相同,有的公司服務沒有分層,有的怎分層很多。目前業界沒有統一的標準。

下面推薦一個比較容易理解的兩層結構。

一線架構師詳解微服務技術架構、監控、Docker、服務治理等體系

1:基礎服務: 比如一個電商網站,商品服務和訂單服務就屬於基礎服務(核心領域服務)。緩存服務,監控服務,消息隊列等也屬於基礎服務(公共服務)

2:聚合服務 :例如網關服務就算一種聚合服務(適配服務)。

這是一種邏輯劃分,不是物理劃分,實際設計的東西很多很複雜。

7:微服務的技術架構體系

下圖是一個成型的互聯網微服務的架構體系:

一線架構師詳解微服務技術架構、監控、Docker、服務治理等體系

1:接入層 負載均衡作用,運維團隊負責

2:網關層 反向路由,安全驗證,限流等

3:業務服務層 基礎服務和領域服務

4:支撐服務層

5:平臺服務

6:基礎設施層 運維團隊負責。(或者阿里雲)

8:微服務的服務發現的三種方式

第一種:如下圖所示,傳統的服務發現(大部分公司的做法)。服務上線後,通知運維,申請域名,配置路由。調用方通過dns域名解析,經過負載均衡路由,進行服務訪問。缺點: LB的單點風險,服務穿透LB,性能也不是太好

一線架構師詳解微服務技術架構、監控、Docker、服務治理等體系

第二種:也叫客戶端發現方式。如下圖所示。通過服務註冊的方式,服務提供者先註冊服務。消費者通過註冊中心獲取相應服務。

並且把LB的功能移動到了消費者的進程內,消費者根據自身路由去獲取相應服務。優點是,沒有了LB單點問題,也沒有了LB的中間一跳,性能也比較好。但是這種方式有一個非常明顯的缺點就是具有非常強的耦合性。針對不同的語言,每個服務的客戶端都得實現一套服務發現的功能。

一線架構師詳解微服務技術架構、監控、Docker、服務治理等體系

第三種:也叫服務端發現方式,如下圖所示。和第二種很相似。但是LB功能獨立進程單獨部署,所以解決了客戶端多語言開發的問題。唯一的缺點就是運維成比較高,每個節點都得部署一個LB的代理,例如nginx。

一線架構師詳解微服務技術架構、監控、Docker、服務治理等體系

9.微服務網關

網關就好比一個公司的門衛。屏蔽內部細節,統一對外服務接口。

一線架構師詳解微服務技術架構、監控、Docker、服務治理等體系

下圖是一個網關所處位置的示例圖。

一線架構師詳解微服務技術架構、監控、Docker、服務治理等體系

10:Netflix Zuul網關介紹

一線架構師詳解微服務技術架構、監控、Docker、服務治理等體系

核心就是一個servlet,通過filter機制實現的。主要分為三類過濾器:前置過濾器,過濾器和後置過濾器。

主要特色是,這些過濾器可以動態插拔,就是如果需要增加減少過濾器,可以不用重啟,直接生效。原理就是:通過一個db維護過濾器(上圖藍色部分),如果增加過濾器,就將新過濾器編譯完成後push到db中,有線程會定期掃描db,發現新的過濾器後,會上傳到網關的相應文件目錄下,並通知過濾器loader進行加載相應的過濾器。

一線架構師詳解微服務技術架構、監控、Docker、服務治理等體系

整個網關調用的流程

上圖從左變http Request開始經過三類過濾器,最終到最右邊的Http Response,這就是Zull網關的整個調用流程。

11:微服務的路由發現體系

整個微服務的路由發現體系,一般由服務註冊中心和網關兩部分組成。以NetFlix為例子,Eureka和Zull這兩個組件支撐了netFlix整個的路由發現體系。如下圖所示,首先外部請求發送到網關,網關去服務註冊中心獲取相應的服務,進行調用。其次內部服務間的調用,也通過服務註冊中心進行的

一線架構師詳解微服務技術架構、監控、Docker、服務治理等體系

12.微服務配置中心

目前大部分公司都是把配置寫到配置文件中,遇到修改配置的情況,成本很高。並且沒有修改配置的記錄,出問題很難追溯。配置中心就接解決了以上的問題。

可配置內容:數據庫連接,業務參數等等

配置中心就是一個web服務,配置人員通過後臺頁面修改配置,各個服務就會得到新的配置參數。實現方式主要有兩種,一種是push,另一種是pull。兩張方式各有優缺點。push實時性較好,但是遇到網絡抖動,會丟失消息。pull不會丟失消息但是實時性差一些。大家可以同時兩種方式使用,實現一個比較好的效果。如下圖所示,這是一個國內知名互聯網公司的配置中心架構圖。

一線架構師詳解微服務技術架構、監控、Docker、服務治理等體系

13:RPC遇到了REST

一線架構師詳解微服務技術架構、監控、Docker、服務治理等體系

內部一些核心服務,性能要求比較高的可以採用RPC,對外服務的一般可以採用rest。

14:服務框架和治理

微服務很多的時候,就需要有治理了。一個好的微服務框架一般分為以下14個部分。如下圖所示。這就是開篇所說的,微服務涉及的東西很多,有些初創公司和業務不成熟的產品是不太適合的,成本比較高。

目前國內比較好的微服務框架就是阿里巴巴的DUBBO了,國外的就是spring cloud,

一線架構師詳解微服務技術架構、監控、Docker、服務治理等體系

15:監控體系

監控是微服務治理的重要環節。一般分為以下四層。如下圖所示。

一線架構師詳解微服務技術架構、監控、Docker、服務治理等體系

監控的內容分為五個部分:日誌監控,Metrics監控(服務調用情況),調用鏈監控,告警系統和健康檢查。

日誌監控,國內常用的就是ELK+KAFKA來實現。健康檢查和Metrics,像spring boot會自帶。Nagios也是一個很好的開源監控框架。

16:Trace調用鏈監控

調用鏈監控是用來追蹤微服務之前依賴的路徑和問題定位。例如阿里的鷹眼系統。主要原理就是子節點會記錄父節點的id信息。

一線架構師詳解微服務技術架構、監控、Docker、服務治理等體系

下圖是目前比較流行的調用鏈監控框架。

一線架構師詳解微服務技術架構、監控、Docker、服務治理等體系

17:微服務的限流熔斷

假設服務A依賴服務B和服務C,而B服務和C服務有可能繼續依賴其他的服務,繼續下去會使得調用鏈路過長。如果在A的鏈路上某個或幾個被調用的子服務不可用或延遲較高,則會導致調用A服務的請求被堵住,堵住的請求會消耗佔用掉系統的線程、io等資源,當該類請求越來越多,佔用的計算機資源越來越多的時候,會導致系統瓶頸出現,造成其他的請求同樣不可用,最終導致業務系統崩潰。

一般情況對於服務依賴的保護主要有兩種方式:熔斷和限流。目前最流行的就是Hystrix的熔斷框架。

下圖是Hystrix的斷路器原理圖:

一線架構師詳解微服務技術架構、監控、Docker、服務治理等體系

限流方式可以採用zuul的API限流方法。

18.Docker 容器部署技術&持續交付流水線

隨著微服務的流行,容器技術也相應的被大家重視起來。容器技術主要解決了以下兩個問題:

1:環境一致性問題。例如java的jar/war包部署會依賴於環境的問題(操著系統的版本,jdk版本問題)。

2:鏡像部署問題。例如java,rubby,nodejs等等的發佈系統是不一樣的,每個環境都得很麻煩的部署一遍,採用docker鏡像,就屏蔽了這類問題。

下圖是Docker容器部署的一個完整過程。

一線架構師詳解微服務技術架構、監控、Docker、服務治理等體系

更重要的是,擁有如此多服務的集群環境遷移、複製也非常輕鬆,只需選擇好各服務對應的Docker服務鏡像、配置好相互之間訪問地址就能很快搭建出一份完全一樣的新集群。

19.容器調度和發佈體系

目前基於容器的調度平臺有Kubernetes,mesos,omega。下圖是mesos的一個簡單架構示意圖。

一線架構師詳解微服務技術架構、監控、Docker、服務治理等體系

下圖是一個完整的容器發佈體系

一線架構師詳解微服務技術架構、監控、Docker、服務治理等體系

那如何學習才能快速入門並精通呢?

當真正開始學習的時候難免不知道從哪入手,導致效率低下影響繼續學習的信心。

但最重要的是不知道哪些技術需要重點掌握,學習時頻繁踩坑,最終浪費大量時間,所以有一套實用的視頻課程用來跟著學習是非常有必要的。

為了讓學習變得輕鬆、高效,今天給大家免費分享一套阿里架構師傳授的一套教學資源。幫助大家在成為架構師的道路上披荊斬棘。

這套視頻課程詳細講解了(Spring,MyBatis,Netty源碼分析,高併發、高性能、分佈式、微服務架構的原理,JVM性能優化、分佈式架構)等這些成為架構師必備的內容!

而且還把框架需要用到的各種程序進行了打包,根據基礎視頻可以讓你輕鬆搭建分佈式框架環境,像在企業生產環境一樣進行學習和實踐。

一線架構師詳解微服務技術架構、監控、Docker、服務治理等體系

後臺私信回覆“架構” 就可以馬上免費獲得這套價值一萬八的內部教材!

最後,做一個愛思考,懂思考,會思考的程序員。


分享到:


相關文章: