體系化認識微服務之三:微服務總體技術架構

體系化認識微服務之三:微服務總體技術架構

這篇文章,介紹下微服務的總體架構體系,微服務拆分後涉及的服務眾多,我們從一個全域性的視角看下微服務架構涉及哪些方面。從上層到下層依次分為:接入層、閘道器、業務服務層、支撐服務層、平臺服務層、基礎設施層
技術構架總覽:

接入層

接入層是入口,比如支付寶,接入層包括手機APP、Web、H5,是流量的入口,負責把外部的流量接入到系統的內部。

閘道器

流量來後需要經入閘道器,閘道器的作用是智慧路由、請求轉發、監控、使用者驗證、限流、熔斷等,閘道器的出現解決的主要問題客戶端不需要與後端細粒度的微服務進行通訊,只需要與閘道器提供的一個統一的REST API通訊就能完成一次完整的請求。

這裡寫圖片描述

比如獲取一個商品的資訊,對於客戶端來說只需要訪問http ://xx.com/product?id=1就能拿到所有的商品明細,然而這個api轉發到後臺的微服務可能需要呼叫購物車服務、商品服務、商品明細服務、促銷服務等眾多服務才能拿到完整的商品資訊。除此之外,後臺的微服務通訊複雜,如果客戶端直接與微服務通訊一是導致客戶端需要關心每個微服務的作用,而這根本不是客戶端應該關心的;而是導致後端服務重構困難,服務的升級改造都需要通知客戶端並作相應的更改。

閘道器基礎元件:Netflix Zuul、Nginx

服務層

服務層就是後端的微服務了,按照之前文章提到的服務拆分原則,微服務可以分為資料層服務和業務服務。閘道器的請求會路由到各個微服務,通常服務層會有很多公用的東西,比如配置、開發框架、持續互動、工程開發規範等,這些都是開發微服務不可缺少的東西。

配置:Disconf、Apollo、spring cloud config
開發框架:springboot、spring cloud
持續互動:jenkins、maven、gradle、IDE(IntelliJ家族、eclipse)
工程規範:alibaba code guidelines、checkstyle

支撐服務

支撐服務包括註冊發現、集中配置、認證授權、日誌聚合、監控報警、容錯限流、後臺服務
註冊發現:springcloud consul、dubbo
集中配置:disconf、spring cloud config
認證授權:CAS、Spring Cloud Security oauth2.0
日誌聚合:elk log4j2
監控報警:influxdb grafana
鏈路監控:pinpoint、zipkin、CAT
熔斷限流:hystrix、dubbo mock
後臺服務:MQ、Cache、schedule Job

平臺服務

平臺服務包括髮布系統、叢集資源排程、映象治理、資源治理、IAM
釋出系統:微服務的線上釋出不可能每個都讓運維支援,所以釋出系統可以讓運維零參與,工程師可以在平臺完成打包、機器分發和釋出整個過程
叢集資源排程:容器排程
映象治理:如果使用了容器,比如Docker會涉及映象治理
IAM:許可權管控

基礎設施

基礎設施包括計算、儲存、網路、IDC