筆者認為“微服務”中的這個”微“字,給很多人帶來了很多誤解,從字面意思上,“微“會讓人聯想到一個微服務,就應該是功能足夠單一,甚至出現一個服務的實現,可能隻需要幾十或者上百行代碼的說法,這應該是最誤導人的觀點。
從技術角度出發,确實可以通過簡短的代碼實現功能單一的服務,但從整體架構上考慮,如果是以這樣的方式實現各個微服務,則在整個服務體系範疇當中,包含太多功能邊界,那麼對于服務運營的分工和邊界就很難界定,給服務接下來的持續運營和維護帶來困擾,另外拆分過于細化的服務,勢必将帶來大量無謂的分布式事務調用,給業務的實現帶來額外的工作量和風險。
随着“微服務”的理念越來越深入人心,加上最近幾年基于容器化技術Docker的不斷盛行,筆者看到一些文章和媒體将這兩個熱點的領域關聯到了一起,甚至畫上了等号。這就很有點誤導的嫌疑。
從技術角度,Docker完全有能力,而且适合微服務體系中給服務提供實際的運行容器,以及進行部署運維的平台,但Docker本身提供的核心能力還隻是在計算資源層面。對于微服務架構所需的應用服務層面,還存在着不小的空缺。構建企業微服務架構的建設過程中,一定會遇到一系列問題,而這些遠不是單單的Docker平台就能解決的問題。
總而言之,微服務不是“免費的午餐”,當越來越多人意識到這種架構給業務響應和創新帶來高效助推能力的時候,也需要深刻了解微服務架構建設中和建設後所将面臨的一系列問題,這需要一個專業的團隊和平台來保障微服務架構的成功落地。
正所謂羅馬不是一天建成的企業,如果要構建微服務體系架構,不要期望靠一個項目就能建立起來,需要多一份耐心。通過服務能力在企業發展過程中的不斷沉澱。當業務的能力沉澱到一個階段後,才能真正感受到微服務架構給企業的業務發展帶來的長遠價值。而這份價值體現出來時,會給企業插上高速發展的翅膀,真正讓企業的業務飛得更高、更快、更遠!
,
更多精彩资讯请关注tft每日頭條,我们将持续为您更新最新资讯!