亚洲视频二区_亚洲欧洲日本天天堂在线观看_日韩一区二区在线观看_中文字幕不卡一区

公告:魔扣目錄網(wǎng)為廣大站長提供免費收錄網(wǎng)站服務,提交前請做好本站友鏈:【 網(wǎng)站目錄:http://www.430618.com 】, 免友鏈快審服務(50元/站),

點擊這里在線咨詢客服
新站提交
  • 網(wǎng)站:51998
  • 待審:31
  • 小程序:12
  • 文章:1030137
  • 會員:747

從微服務基本概念到核心組件-通過一個實例來講解和分析

 

作者:人月神話,新浪博客同名

簡介:多年SOA規(guī)劃建設,私有云PaaS平臺架構設計經(jīng)驗,長期從事一線項目實踐

今天我準備重新講解下微服務的基礎概念,關鍵組件和組件間關系等核心邏輯。這篇文章我會對我原來寫過的微服務類文章內(nèi)容進行大量重構,去掉里面比較技術化的內(nèi)容,而轉(zhuǎn)為一種非開發(fā)人員也容易理解的方式來講解。

概念模型為何如此重要?

從微服務基本概念到核心組件-通過一個實例來講解和分析

 

最近我思考比較多的一個詞就是概念模型,不管新知識的學習,新事物的認知,新領域的快速切入還是面對新問題的快速分析和解決,認識和理解概念模型都是相當重要的一個步驟。

概念模型本身是我們認知事物核心框架和基礎邏輯的自我可理解的最簡模型

這里面有幾個關鍵點,其一是對事物形成基礎認知,其二是最簡和最容易模型,其三則是對我們自己最佳適用的模型

每個人的知識積累和經(jīng)驗不同,最適用于他們的概念模型就是不一樣的。因此對于有理論和實踐經(jīng)驗積累的人,你可能并不需要用簡單的方式闡述事物,有時候連比喻都不需要,而對于初次接觸陌生領域的人來說,那么對核心邏輯的形象比喻就顯得相當重要了。

一個事物只有在自己腦海里面形成了初步的概念模型的時候,才能夠算對該事物有了初步的認識,接下來才談得上如何層層剝繭和分解,深入到內(nèi)部機理進行深入了解。這和我們在學習方法和模式里面談到一開始的學習應該是不求甚解是一個道理。

只有搭建了大框架,理清主脈絡,你才可能有目標和有興趣深入。

但是實際我們?nèi)匀豢吹剑ê芏嗳藛T頭腦里面仍然是采用了SpringCLoud框架,采用了Http Rest接口服務集成或API網(wǎng)關就是微服務了。而對微服務架構思想的本質(zhì)并沒有形成完整的理解,這些都是我們在學習新知識,認識新事物時候必須要避免的。

從微服務基本定義說起

從微服務基本概念到核心組件-通過一個實例來講解和分析

 

我們先看下當前互聯(lián)網(wǎng)上對微服務的主流定義。

微服務可以在“自己的程序”中運行,并通過“輕量級設備與HTTP型API進行溝通”。關鍵在于該服務可以在自己的程序中運行。通過這一點我們就可以將服務公開與微服務架構(在現(xiàn)有系統(tǒng)中分布一個API)區(qū)分開來。在服務公開中,許多服務都可以被內(nèi)部獨立進程所限制。如果其中任何一個服務需要增加某種功能,那么就必須縮小進程范圍。在微服務架構中,只需要在特定的某種服務中增加所需功能,而不影響整體進程。

 

微服務不需要像普通服務那樣成為一種獨立的功能或者獨立的資源。定義中稱,微服務是需要與業(yè)務能力相匹配,這種說法完全正確。不幸的是,仍然意味著,如果能力模型粒度的設計是錯誤的,那么,我們就必須付出很多代價。

看完上面的圖后,估計還是很難真正抓住微服務的關鍵點。

在我很早就談到過,在理解和認識一個概念的時候,你一定要用和你已有的知識概念做對比,進行差異分析,你就很容易抓住要點在哪里。

而要了解微服務一樣,你了解了和傳統(tǒng)單體應用的差別,基本微服務核心就了解了。簡單來說微服務本身就是將傳統(tǒng)的單體應用大拆小,然后通過一種輕量高效的標準接口進行協(xié)同的架構模式。

舉一個單體應用到微服務的例子說明

為了更好的解釋微服務,包括后面對微服務很多關鍵組件的解釋,我們需要準備一個業(yè)務系統(tǒng)功能常見來進行舉例說明,具體的背景如下。

當前我們準備構建一個SRM供應商關系管理業(yè)務系統(tǒng),這個系統(tǒng)經(jīng)過前期業(yè)務和需求分析,包括了供應商管理,物料管理,招投標,供應商績效評估四個功能模塊。當然在構建整個系統(tǒng)的時候還有類似底層的系統(tǒng)管理,流程引擎等技術模塊組件。

我們要構建的SRM系統(tǒng)就是典型的單體應用,那么我們來看這個單體應用構建模式轉(zhuǎn)變到微服務構建模式后究竟帶來了哪些變化。如下圖,我們從開發(fā)態(tài)和運行態(tài)去分析。

從微服務基本概念到核心組件-通過一個實例來講解和分析

 

從這個圖我們基本就把微服務核心的關鍵點看清楚了。即:

  • 一個單體變多個微服務模塊,而且從數(shù)據(jù)庫到邏輯層到前端完全獨立
  • 微服務模塊間通過Http Rest接口高效集成協(xié)同
  • 各個微服務完全獨立部署,擴展的時候數(shù)據(jù)庫,集群都單獨擴展

以上實際上就是我們經(jīng)常談到的微服務區(qū)別于單體架構最關鍵的幾個點。在掌握了這個核心概念后你才清楚哪些不是微服務基本特征。比如微服務必須容器化部署,沒有這個說法,微服務也可以傳統(tǒng)方式部署。還有就是微服務開發(fā)必須前后端分離,實際上也沒有這個說法,前后端不分離只要微服務間完全縱向解耦就是微服務架構。

基于SOA和中臺思想對上面拆分進行重構

如果按照上面的模塊拆分進行獨立的設計,開發(fā)和部署,完全是符合微服務架構的思想的。但是是否符合SOA和中臺能力共享思想呢?

將數(shù)據(jù)提供和形成數(shù)據(jù)的流程分開形成分層

我再強調(diào)下SOA和中臺里面的一個關鍵思想,即:

你要去找到你的核心業(yè)務能力提供,而不是馬上去關心你的能力或最終數(shù)據(jù)是如何形成的。能力最終提供屬于中臺能力,能力如何形成的可以屬于前臺應用能力。

比如上面談到的供應商,物料兩個微服務,我們發(fā)現(xiàn)核心就是提供可共享的供應商和物料數(shù)據(jù)能力。但是這兩個數(shù)據(jù)如何形成的? 一方面是可以直接在后臺錄入,一個方面還是可以是供應商自己進行供應商認證申請,我們審核通過后進入到供應商庫。

 

那么供應商數(shù)據(jù)本身屬于中臺能力,供應商信息的申請流程可屬于前臺應用功能。

是否嚴格的邏輯層和數(shù)據(jù)庫1對1對應?

這個是我今天想拿出來討論的第二個問題,即很多人在進行微服務架構設計的時候往往走兩個極端。或者是數(shù)據(jù)庫不拆分就一個大庫,或者就是數(shù)據(jù)庫完全按微服務1對1拆分。那么我們上層規(guī)劃的20個微服務,是否就一定有20個對應的數(shù)據(jù)庫實例ID?

在數(shù)據(jù)庫拆分細一定帶來我們在設計實現(xiàn)時候兩個問題

  • 其一是我們常說的分布式事務處理問題,有用庫拆分無法再用數(shù)據(jù)庫層事務
  • 其二是原來一個關聯(lián)sql搞定的事情,全部變成了邏輯層多次服務調(diào)用后進行服務組裝

以上兩個問題不僅僅是帶來的開發(fā)工作量,而且更重要的是影響到數(shù)據(jù)一致性。

正是由于這個原因,我們提出一個微服務集的概念。

微服務集的意思可以理解為邏輯層仍然按照標準的微服務要求去構建,每個邏輯層都可以編譯可獨立部署的Jar包。但是對應微服務集里面的多個微服務可共用一個數(shù)據(jù)庫。

而基于上面場景,供應商和物料本身關聯(lián)業(yè)務場景相當多,放在一個數(shù)據(jù)庫顯然是更加適合。經(jīng)過重新思考后,我們整體的邏輯架構變化為:

從微服務基本概念到核心組件-通過一個實例來講解和分析

 

基于實際業(yè)務場景驅(qū)動,對微服務初步設計重構后體現(xiàn)為兩點

  • 其一是供應商和物料合并為一個數(shù)據(jù)庫而不進行拆分
  • 其二是邏輯層的微服務基于復用分層思路拆分為三個微服務模塊

拆分后的三個微服務如何交互?

在完成基本的拆分后,我們來看拆分完成后的三個微服務模塊如何交互。

如果我們?nèi)匀话裇RM看成一個大的應用,并且SRM系統(tǒng)的能力接口不需要對外暴露,不需要互聯(lián)網(wǎng)App應用協(xié)同的時候。在這種情況下,走微服務架構體系里面的服務注冊中心來完成接口交互。簡單來說就是微服務間的接口消費調(diào)用是一種去中心化的架構模式。

我們以供應商申請微服務,需要在申請審核通過后,調(diào)用供應商管理提供的信息導入API接口將數(shù)據(jù)導入到供應商管理模塊中來舉例說明。

從微服務基本概念到核心組件-通過一個實例來講解和分析

 

從圖里面可以看到整個過程簡單的三個關鍵步驟。

  • 第一,供應商管理將實現(xiàn)的API接口注冊到注冊中心
  • 第二,申請模塊從注冊中心獲取接口的地址信息
  • 第三,根據(jù)拿到的地址信息直接發(fā)起對接口的點對點調(diào)用

為何叫去中心化?

從上圖整個過程可以看到,整個服務調(diào)用只有獲取地址會和數(shù)據(jù)中心發(fā)生關系,實際獲取到地址后即是接口的點對點調(diào)用,這個時候接口的數(shù)據(jù)流完全不經(jīng)過注冊中心。

那么獲取地址的時候注冊中心宕機了怎么辦?

所以可以看到一般來說,獲取的地址信息都會在本地微服務模塊緩存,后續(xù)在調(diào)用的時候如果注冊中心有故障,那么就訪問本地緩存的地址信息。對于這點本身又需要稍微展開下分兩個實現(xiàn)方式來進一步解釋下。

其一,負載均衡的能力在注冊中心

在這種情況下,我們每次消費接口,都必須調(diào)用注冊中心服務來獲取最終輪詢出來的目標地址信息。只有在注冊中心不可用情況下,我們才訪問本地緩存。

其二,負載均衡的能力在本地微服務

在這種情況下,只需要獲取注冊中心的地址信息清單,同時在地址狀態(tài)變更的時候被動獲取注冊中心的變更消息推送。那么后續(xù)所有接口訪問都和注冊中心無關。

微服務間交互是否一定是Http Rest接口?

多個微服務如果不對外提供能力,僅僅是內(nèi)部接口交互,那么Http Rest接口并不是必須的。比如我們常說的Dubbo框架,可以采用更加高效的RPC接口進行交互,而且底層還可以走TCP協(xié)議。

但是一涉及到對外能力提供,涉及到主動網(wǎng)絡防火墻問題時,一般只能走Http接口交互。

當然你可以理解為,同樣一個接口實現(xiàn),我們可以在內(nèi)部交互的時候走高效的RPC接口模式,而僅僅需要對外暴露服務能力的時候?qū)⑵浒l(fā)布為Http Rest接口。

從服務注冊中心到API網(wǎng)關

對于一個應用里面的多個微服務需要統(tǒng)一對外暴露接口能力的時候,這個時候就涉及到OpenAPI能力開放平臺或API網(wǎng)關,那么首先來解釋下API網(wǎng)關。

從微服務基本概念到核心組件-通過一個實例來講解和分析

 

如何給API網(wǎng)關一個定義?

簡單來說API網(wǎng)關就是將所有的微服務提供的API接口服務能力全部匯聚進來,統(tǒng)一接入進行管理,也正是通過統(tǒng)一攔截,就可以通過網(wǎng)關實現(xiàn)對API接口的安全,日志,限流熔斷等共性需求。如果再簡單說下,通過網(wǎng)關實現(xiàn)了幾個關鍵能力。

  • 內(nèi)部的微服務對外部訪問來說位置透明,外部應用只需和網(wǎng)關交互
  • 統(tǒng)一攔截接口服務,實現(xiàn)安全,日志,限流熔斷等需求

從這里,我們就可以看到API網(wǎng)關和傳統(tǒng)架構里面的ESB總線是類似的,這些關鍵能力本身也是ESB服務總線的能力,但是ESB服務總線由于要考慮遺留系統(tǒng)的接入,因此增加了類似遺留系統(tǒng)適配,協(xié)議轉(zhuǎn)換,復雜數(shù)據(jù)映射等能力。

微服務架構不再需要ESB,并且一定是去中心化的?

這是必須要搞清楚的一個問題。

首先看下微服務架構里面確實不需要傳統(tǒng)ESB,但是需要一個ESB的輕量實現(xiàn),即我們說的API網(wǎng)關。因為微服務架構里面都是標準的Http Rest接口,不再存在復雜的遺留接口適配,復雜協(xié)議轉(zhuǎn)換等問題。但是我們常說的接口服務代理,統(tǒng)一的安全,日志,流控功能仍然需要。

同時微服務架構內(nèi)部各個微服務模塊間本身是去中心化的,但是當微服務架構里面各個微服務需要對外提供接口服務能力給外部應用使用時候,外部應用和微服務間由于增加了API網(wǎng)關又變成了一個中心化的架構。所以不要一提到微服務就去中心化,這個理解本身也是不對的。

對于API網(wǎng)關來說,核心就是實現(xiàn)兩類能力,一個是對API全生命周期管理能力,包括了API接口的注冊,接入,發(fā)布,測試,變更和版本管理,下線等。另外一個關鍵能力就是我們常說的安全,日志,流控方面的能力。

而這些能力最常見的實現(xiàn)方式就是通過插件進行攔截處理,如下:

從微服務基本概念到核心組件-通過一個實例來講解和分析

 

如上圖,API網(wǎng)關里面的關鍵對象注意包括了接入系統(tǒng)(微服務),消費系統(tǒng),注冊接入的API接口,發(fā)布的Proxy API接口,在代理和原始服務間有一個路由對象。只要有這些最基本的對象就可以實現(xiàn)最簡單場景下的服務接入。

而其它所有的擴展可以看到都應該基于插件式方式的擴展,這些插件包括了安全認證類插件,流量控制類插件,日志監(jiān)控類插件,轉(zhuǎn)換類插件。

任何一個API接口和插件之間是一種多對多的關系。即一個API接口可以被作用多個插件,同時一個插件本身又可以應用在多個API接口上。插件本身就類似于AOP橫切,對服務請求消息的輸入和輸出進行攔截,在攔截到信息后進行相關的安全或其他管控處理。

當然插件本身一定會損耗性能,在實現(xiàn)的時候需要考慮對服務運行數(shù)據(jù),運行統(tǒng)計數(shù)據(jù)的緩存,特別是對于流控的實時計算過程。

業(yè)務場景需求引入網(wǎng)關

還是基于上面的案例,供應商申請流程我們希望開發(fā)一個APP應用給用戶自己申請。這個APP供應商在公網(wǎng)就可以正常訪問和登錄使用。

前面談到,API網(wǎng)關使用重要場景就是需要對外提供服務能力。這個對外可能是和外部其它系統(tǒng)集成,也可以是我們的應用本身會開發(fā)外部互聯(lián)網(wǎng)使用的APP。

在這個時候API網(wǎng)關引入就變成了必須。

從微服務基本概念到核心組件-通過一個實例來講解和分析

 

API網(wǎng)關本身也實現(xiàn)了外部應用和我們內(nèi)部微服務間的安全隔離,比如我們把API網(wǎng)關還可以部署到整個基礎設施架構的DMZ區(qū)等。

是否可以不用API網(wǎng)關?

當然,你也可以不用類似Kong等API網(wǎng)關產(chǎn)品,那么這個時候我們常說的一些共性的安全,日志,限流熔斷能力無法實現(xiàn)。但是最基本的代理路由轉(zhuǎn)發(fā)能力是必須的,因此你在前期可以使用類似Ngnix來實現(xiàn)請求轉(zhuǎn)發(fā)并替代API網(wǎng)關的使用

API網(wǎng)關的幾個關鍵功能分析

下面來看下API網(wǎng)關實現(xiàn)的幾個關鍵功能。其中附帶介紹下Kong網(wǎng)關的一些關鍵能力。

從微服務基本概念到核心組件-通過一個實例來講解和分析

 

日志攔截和記錄

對于日志攔截和記錄是最常見的一個API網(wǎng)關功能,但是類似開源的API網(wǎng)關產(chǎn)品往往也僅僅是提供日志輸入接口,如果需要對日志進行集中化存儲和日志查詢分析,仍然需要自己開發(fā)相關的功能來完成。

日志攔截簡單來說三點

  • 其一:首先是通過插件攔截到輸入和輸出消息信息
  • 其二:將信息寫入異步寫入到消息中間件中
  • 其三:通過程序從消息中間件中獲取消息,再將日志持久化到數(shù)據(jù)庫或分布式對象存儲

如果整個微服務里面日志產(chǎn)生量大,而且對歷史日志的查詢時間段也要求較長的情況下,建議將日志存在到分布式文件存儲或分布式對象存儲中。

可以看到日志信息本身復合服務實例ID+實例報文體這種對象存儲結(jié)構。

比如我們可以基于Kong網(wǎng)關的擴展能力來自己開發(fā)日志記錄存儲和查詢插件,對于Kong網(wǎng)關來說插件的定制化開發(fā)能力相當強。

一個是sysLog在配置后可以直接將Kong產(chǎn)生的日志寫入到應用服務器的系統(tǒng)日志文件中。如果配置了file-log則是單獨寫入到你指定的file文件中。對于http-log則是對于http服務請求,可以詳細的記錄請求的輸入和輸出報文信息,但是具體是記錄到哪里,需要通過config.http_endpoint配置。

從微服務基本概念到核心組件-通過一個實例來講解和分析

 

安全功能

從微服務基本概念到核心組件-通過一個實例來講解和分析

 

對于安全功能我們先簡單談下實際需要哪些安全能力。

最常見的就是接口服務訪問控制安全能力,即API網(wǎng)關暴露的一個接口,必須通過安全認證通過后才能夠訪問接口。供應商信息導入API比如你授權給供應商申請流程微服務模塊(SUP)使用。那么可以看到常見的一些方法。

  • 其一:分配給SUP一個靜態(tài)的用戶名和密碼,調(diào)用服務的時候基于這個進行驗證
  • 其二:對SUP系統(tǒng)的IP地址進行配置,只有授權的IP地址能夠訪問

但是對于方法1容易出現(xiàn)用戶名密碼泄漏或被截取;第2種方法容易出現(xiàn)IP偽造,或者對于容器云環(huán)境IP本身就是不斷動態(tài)變化你很難去控制。

因此在這種常見下,我們出現(xiàn)了動態(tài)Token安全的處理方法。

簡單來說就是你每次調(diào)用服務前,都先向API網(wǎng)關申請一個動態(tài)申請的Token碼,然后在調(diào)用服務的時候連帶上這個token碼一起發(fā)送過去進行校驗,只要校驗通過才允許訪問服務。

當然對于開源各類API網(wǎng)關產(chǎn)品基本也提供常見的各類安全能力。

從微服務基本概念到核心組件-通過一個實例來講解和分析

 

比如當前網(wǎng)關提供basic-auth,key-auth、ldap-auth,hmac-auth多種認證插件。

限流熔斷功能

從微服務基本概念到核心組件-通過一個實例來講解和分析

 

對限流熔斷的理解,首先本文談到的服務限流和熔斷,和常規(guī)我們說的限流和熔斷有區(qū)別。

具體說明為:

  • 服務限流:取消某個消費方對某個服務的訪問授權,只單個消費方受影響
  • 服務熔斷:直接對該服務進行下線處理,或?qū)⒃摲諣顟B(tài)設置為不可用,所有消費方受影響

其次,對于服務流控我們需要設置具體要監(jiān)控哪些指標,注意這個指標監(jiān)控是在單位時間里面的監(jiān)控指標,即計算在單位時間的累計數(shù)據(jù),當觸發(fā)后即進行流控。具體包括:

  1. 運行次數(shù):單位時間里面的運行次數(shù)累計,比如一個消費方大并發(fā)調(diào)用,可以限流
  2. 業(yè)務系統(tǒng)異常次數(shù):源服務出現(xiàn)異常的次數(shù),也可以考慮異常占比率
  3. 系統(tǒng)異常:即出現(xiàn)系統(tǒng)級異常次數(shù),本身包括Token失效,也包括ESB總線本身故障
  4. 報文量:即單位時間內(nèi)傳輸?shù)膱笪牧窟_到某個值,考慮是輸入+輸出報文量和的累計

對于運行時長更多是預警,而實際上直接限流和熔斷不現(xiàn)實。因此主要的流控指標就是上面這些,基于以上指標本身又有兩種操作,一種是限流,一種是整個服務熔斷。而實際上可以看到。

  1. 限流:運行次數(shù),Token失效,報文量
  2. 熔斷:業(yè)務系統(tǒng)異常,系統(tǒng)ESB本身故障異常

限流熔斷解除,最后,在還需要考慮的就是在實施了限流和熔斷后如何解除的問題,在實際實現(xiàn)的時候,對于限流可以在規(guī)定時間后自動解除,而對于熔斷最好還是人工恢復解除。

比如對CRM系統(tǒng)訪問MDM的查詢供應商服務進行限流后,在啟動限流后的某個時間間隔后,比如2小時后,可以自動進行解除。這個時間間隔可以靈活配置。

而對于類似Kong網(wǎng)關當前提供的限流相對來說還是比較弱,即主要是控制某一個API接口服務在單位時間內(nèi)最多只能夠調(diào)用多少次,如果超過這個次數(shù)那么網(wǎng)關就直接拒絕訪問并返回錯誤提示信息。

而在前面我講限流和流量控制的時候經(jīng)常說到,就是限流實際上一個是根據(jù)服務調(diào)用次數(shù),一個是根據(jù)服務調(diào)用數(shù)據(jù)量,需要在這兩個方面進行限流。而里面更加重要的反而是數(shù)據(jù)量的限流,因為大數(shù)據(jù)量報文往往更加容易造成內(nèi)存溢出異常。

API全生命周期管理包括了API接口的定義,API快速開發(fā)的支持,API的注冊和接入,API模擬測試和自動化測試,API文檔自動生成,API版本和變更管理,API下線,API監(jiān)控運維等一系列的功能,本部分后續(xù)單獨文章說明。

遺漏了什么?

基于上面的例子來分析,我們整體感覺進行微服務架構設計和開發(fā)并不困難。但是如果站在整體企業(yè)應用架構規(guī)劃視角來看,你會發(fā)現(xiàn)有內(nèi)容遺漏,即技術平臺建設。

這也是我們經(jīng)常在強調(diào)的,共性技術平臺能力下沉是進行微服務開發(fā)的基礎。

還是以上面的例子來進一步分析。

從微服務基本概念到核心組件-通過一個實例來講解和分析

 

四個模塊都需要用到系統(tǒng)管理和工作流引擎,那么我們在進行微服務拆分后,不可能在每個微服務里面還各自含有相同的4A系統(tǒng)管理和流程引擎等共性技術能力。

共性技術能力下沉,然后共性技術服務能力給微服務使用是必須的

對于系統(tǒng)管理和流程引擎本身也是一個或二個獨立建設的微服務。

企業(yè)要進行微服務架構規(guī)劃和建設,那么最基礎的技術平臺規(guī)劃建設,將共性技術能力從傳統(tǒng)遺留系統(tǒng)移出,作為微服務功能模塊單獨建設并能力共享,是基礎的基礎。

企業(yè)核心技術中臺能力支撐微服務

從微服務基本概念到核心組件-通過一個實例來講解和分析

 

微服務架構思想實際上是包含了平臺+應用思想,業(yè)務組件化服務化思想,SOA和云思想,包括當前主流的DevOps思想的一個融合,而不僅僅是簡單的微服務架構。

因此企業(yè)在轉(zhuǎn)型到微服務架構時候必須重新規(guī)劃和建設技術中臺能力,包括前面的遺留問題分析我們也看到共性技術能力下沉是微服務建設的基礎。共性技術能力下沉后,微服務才能夠只關心業(yè)務而更加輕量。

首先我們對整體規(guī)劃建設進行拆分,主要應該包括以下關鍵的建設任務和內(nèi)容:

從微服務基本概念到核心組件-通過一個實例來講解和分析

 

底層私有云IaaS平臺建設

在建設時候可以基于IaaS資源池進行并盡量去IOE架構。當前實際上對于數(shù)據(jù)庫仍然會涉及到部分的Oracle數(shù)據(jù)庫和集中存儲,企業(yè)在選型和規(guī)劃的時候要考慮去掉這部分潛在風險。

服務器資源可以考慮全部采用X86服務器并進行虛擬化,提供虛擬機資源作為計算能力。

容器化PaaS平臺建設

對于PaaS平臺建設當前可以基于輕量的Docker容器進行,并通過Kubernetes進行資源管理和動態(tài)調(diào)度。而如果規(guī)劃建設DevOps支撐平臺,即在DevOps平臺建設過程中統(tǒng)一建設容器化PaaS平臺,當然在DevOps平臺中會進一步實現(xiàn)了持續(xù)集成和流水線作業(yè)能力,實現(xiàn)開發(fā),運行和后期運維監(jiān)控的一體化管理。

微服務開發(fā)框架和環(huán)境

在微服務架構實施中,還有一個重點就是制定微服務架構開發(fā)框架,標準和規(guī)范體系,以指導后續(xù)開發(fā)廠商按照統(tǒng)一的標準方法、工具和流程進行微服務組件模塊和接口服務的開發(fā),確保開發(fā)標準和規(guī)范一致性,也進一步確保了后續(xù)多個微服務模塊在集成的時候不會出現(xiàn)問題。

從微服務基本概念到核心組件-通過一個實例來講解和分析

 

把這些都談后,再轉(zhuǎn)回談需要統(tǒng)一建設的技術平臺部分:

4A平臺和系統(tǒng)管理

這個是必須建設的內(nèi)容,不僅僅是實現(xiàn)統(tǒng)一用戶,統(tǒng)一認證和鑒權,統(tǒng)一組織,統(tǒng)一審計等內(nèi)容。在微服務架構下,4A平臺需進一步擴展傳統(tǒng)業(yè)務系統(tǒng)中系統(tǒng)管理模塊的內(nèi)容,即能夠?qū)崿F(xiàn)到微服務模塊內(nèi)部的功能菜單和按鈕級的操作授權,同時能夠?qū)崿F(xiàn)靈活定義的數(shù)據(jù)級授權和配置。

公共流程平臺

從微服務基本概念到核心組件-通過一個實例來講解和分析

 

這個公共流程平臺也是必須,實現(xiàn)統(tǒng)一的類似內(nèi)部多租戶的流程引擎,實現(xiàn)流程的設計建模,運行,監(jiān)控的全部統(tǒng)一化。各個業(yè)務組件模塊僅僅是使用流程平臺提供的能力。

技術服務平臺

從微服務基本概念到核心組件-通過一個實例來講解和分析

 

這個實際涉及到消息,緩存,文件,任務,日志,通知,分布式存儲等諸多技術服務能力,可以根據(jù)企業(yè)需要來確定哪些要單獨實現(xiàn)為獨立的技術服務能力開放提供。這個沒有明確的要求,但是根據(jù)實際項目實踐來看,類似發(fā)送短信郵件的通知類服務,文件存儲類服務往往都是必須要規(guī)劃建設的。

監(jiān)控運維平臺

這個平臺實際上包括了傳統(tǒng)的IT網(wǎng)管監(jiān)控,同時還包括了當前的APM業(yè)務性能監(jiān)控兩個方面的內(nèi)容。同時兩者內(nèi)容本身又相互集成和融合。由于采用了容器化PaaS,實際上微服務開發(fā)商對底層資源的情況并不清楚,因此更加需要這樣一個監(jiān)控運維平臺能夠同時監(jiān)控到業(yè)務性能和資源層性能,并實時預警。

微服務架構設計還有哪些關鍵點?

從微服務基本概念到核心組件-通過一個實例來講解和分析

 

對于微服務架構設計,要明白遠遠不是采用了類似SpringCloud微服務開發(fā)框架,或者說采用了Http Rest接口服務就是微服務架構,更加重要的還是業(yè)務能力的組件化或者叫微服務模塊化,組件能力的接口服務化。對于微服務架構設計,可以思考的關鍵點如下:

基于業(yè)務交互分析劃分合理的微服務組件模塊

微服務模塊劃分是否合理將直接影響到后續(xù)微服務模塊的開發(fā)集成和實施難度。

看到很多例子就是一個本來很小的業(yè)務系統(tǒng)居然會劃分出20多個微服務模塊,每個模塊全部采用單獨的容器部署。這個在互聯(lián)網(wǎng)應用里面可能適合,但是在企業(yè)微服務架構轉(zhuǎn)型里面一定不適合。

模塊劃分越細,模塊間接口交互和集成就越復雜,后續(xù)微服務的運維管控治理就越難。

如何劃分?一個傳統(tǒng)的業(yè)務系統(tǒng)建議最多拆分為6到8個微服務組件,對于縱向流程工單驅(qū)動型由于本身耦合小可以劃分的更細,但是其它類似核心業(yè)務數(shù)據(jù)驅(qū)動型都不要劃分太細。

面向接口開發(fā)同時識別粗粒度的服務接口

從微服務基本概念到核心組件-通過一個實例來講解和分析

 

微服務在架構設計階段除了技術架構外核心就是兩個事情

  • 一個就是劃分微服務模塊
  • 一個就是識別和定義粗粒度的微服務API接口

注意微服務模塊間的接口要提前進行識別和定義,從頂向下面向接口開發(fā),這本身也是傳統(tǒng)架構設計就遵循的原則。一定不能是一開始不定義接口,后續(xù)各個模塊開發(fā)到哪里了發(fā)現(xiàn)接口缺少再臨時倉促定義,這個帶來的最大問題就是接口粒度管理失控,后續(xù)運維也失控,導致大量的接口重復定義等。

如果你是采用Http Rest接口,那么你更要了解面向資源設計和領域建模的概念,怎樣定義才算得上是面向資源的,而不是簡單的隨便定義Http API操作。

在架構設計階段就完成數(shù)據(jù)庫拆分設計

從微服務基本概念到核心組件-通過一個實例來講解和分析

 

注意在微服務架構設計階段一開始就應該完成數(shù)據(jù)庫拆分,每個微服務模塊對應獨立的數(shù)據(jù)庫。

一定要注意微服務一定不是簡單的應用組件拆分,而是包括了后端的數(shù)據(jù)庫也有拆分,這樣才是完整意義上的微服務架構。同時拆分后的數(shù)據(jù)庫間不應該有交互和集成,所有的交互和集成都應該通過應用組件層的API接口服務進行。只有這樣才是完整意義上的微服務架構。

搞清微服務注冊中心和微服務網(wǎng)關的區(qū)別并按需使用

在一個完整的微服務架構里面涉及到微服務注冊中心和微服務網(wǎng)關,務必注意到兩個組件的區(qū)別并按需使用。簡單來說就是一個微服務架構應用內(nèi)部所有的微服務模塊組件之間的接口交互都只需要通過注冊中心來完成即可,這種方式是性能最佳,去中心化的方式。當一個微服務架構應用需要和外部交互,或者說需要開放能力給外部業(yè)務系統(tǒng)使用的時候才需要將API接口服務接入到微服務網(wǎng)關或API網(wǎng)關。

做好開發(fā)團隊劃分和微服務模塊劃分之間的匹配工作

從微服務基本概念到核心組件-通過一個實例來講解和分析

 

在微服務架構設計做好了微服務模塊劃分后,另外一個重點工作就是做好開發(fā)團隊的劃分和匹配工作。按道理這個不屬于微服務架構設計的內(nèi)容,但是屬于整個研發(fā)過程和項目管理的內(nèi)容。

開發(fā)團隊的劃分基本要做到和微服務模塊劃分匹配,能夠完全隔離和松耦合是最好。

要明白,如果一個人負責多個微服務模塊,那我們原來定義的微服務模塊間的接口規(guī)則,交互規(guī)則,技術標準規(guī)范很難真正做到徹底執(zhí)行。

即多個微服務模塊間協(xié)同變成一個開發(fā)人員內(nèi)部管理的事情,那么開發(fā)就容易怎么方便怎么來,而忽視了關鍵的架構規(guī)則和約束。也就是到最后你會發(fā)現(xiàn),分配給一個人負責的多個微服務模塊,本身一開始是松耦合的設計,但是最后完全變樣為難以拆分的緊耦合關系。

面向產(chǎn)品集成和持續(xù)集成而設計

從微服務基本概念到核心組件-通過一個實例來講解和分析

 

在微服務架構設計的時候,必須要考慮到產(chǎn)品集成和持續(xù)集成。對于持續(xù)集成可以參考標準的持續(xù)集成方法,也可以參考DevOps標準過程體系以實現(xiàn)持續(xù)集成和持續(xù)交付,當然在整個過程中可以和容器化PaaS平臺融合,進一步實現(xiàn)持續(xù)交付過程的自動化。

另外在整個架構設計中的模塊劃分和接口設計的時候,還需要考慮到整個產(chǎn)品集成順序,即一個大系統(tǒng)劃分為了多個微服務模塊,他們之間的構建順序,集成順序究竟是如何的?為了更好的實現(xiàn)產(chǎn)品集成,原則上應該是基于完整的業(yè)務流生命周期,模塊之間更多的是由上游流程到下游流程進行逐層集成,同時盡量要避免雙向集成導致后續(xù)集成測試很難進行集成和組裝。

對于DevOps研發(fā)運維一體化,持續(xù)集成和持續(xù)交付,以及DevOps過程支撐平臺如何和微服務架構設計開發(fā),研發(fā)過程管理更好的協(xié)同,我后面會專門再寫一篇文章進行描述。

面向業(yè)務和應用監(jiān)控運維而設計

從微服務基本概念到核心組件-通過一個實例來講解和分析

 

要注意在微服務架構下實際上是獨立自治的微服務模塊變多,接口變多,集成關系更加復雜,這些都直接導致了后續(xù)業(yè)務和應用監(jiān)控更加復雜。很多企業(yè)在進行微服務架構轉(zhuǎn)型的時候,由于后期的自動化監(jiān)控運維能力跟不上導致最終轉(zhuǎn)型中出現(xiàn)大量的問題無法解決,這些也是在架構設計時要考慮的。

即在進行微服務架構設計的時候,要基于DevOps的思想,將很多可監(jiān)控,可運維需求作為關鍵的非功能性需求納入到架構設計中,在微服務模塊間的接口服務設計的時候都需要加入這些設計原則和關鍵屬性,以方便后續(xù)進行業(yè)務監(jiān)控和服務鏈監(jiān)控,同時在業(yè)務出現(xiàn)問題的時候能夠快速定位。

分享到:
標簽:微服
用戶無頭像

網(wǎng)友整理

注冊時間:

網(wǎng)站:5 個   小程序:0 個  文章:12 篇

  • 51998

    網(wǎng)站

  • 12

    小程序

  • 1030137

    文章

  • 747

    會員

趕快注冊賬號,推廣您的網(wǎng)站吧!
最新入駐小程序

數(shù)獨大挑戰(zhàn)2018-06-03

數(shù)獨一種數(shù)學游戲,玩家需要根據(jù)9

答題星2018-06-03

您可以通過答題星輕松地創(chuàng)建試卷

全階人生考試2018-06-03

各種考試題,題庫,初中,高中,大學四六

運動步數(shù)有氧達人2018-06-03

記錄運動步數(shù),積累氧氣值。還可偷

每日養(yǎng)生app2018-06-03

每日養(yǎng)生,天天健康

體育訓練成績評定2018-06-03

通用課目體育訓練成績評定