架構設計之「 微服務入門 」

来源:https://www.cnblogs.com/SimpleWu/archive/2019/03/28/10612478.html
-Advertisement-
Play Games

微服務這幾年不可謂不火,很多技術團隊都開始在自己的項目上引入了微服務。一方面這些團隊確實很好的推動了微服務的應用和發展,另一方面也可以看到一些盲目追技術熱點的行為所帶來的危害,比如很多中小團隊對微服務的基礎知識只是做了很淺顯的瞭解就開始盲目的推動微服務的實施,最後導致了項目的失敗。 微服務要想做好是 ...


微服務這幾年不可謂不火,很多技術團隊都開始在自己的項目上引入了微服務。一方面這些團隊確實很好的推動了微服務的應用和發展,另一方面也可以看到一些盲目追技術熱點的行為所帶來的危害,比如很多中小團隊對微服務的基礎知識只是做了很淺顯的瞭解就開始盲目的推動微服務的實施,最後導致了項目的失敗。

微服務要想做好是一個非常複雜的架構,今天就先只聊一聊微服務的一些基礎架構,算是入門篇。

一、什麼是「 微服務 」?

「 微服務 」由 Martin Fowler 提出,它是指一種軟體架構風格。一個大型的系統可以由多個微服務組成,每個微服務是被獨立部署,獨立完成自己的任務單元,微服務之間是通過API方式進行通信調用,是松耦合的。

這個模式聽著是不是很熟悉的感覺?

因為在提出「 微服務 」概念之前,很多互聯網公司的中大型項目早就是按照將業務拆分成獨立單元的形式在部署和架構的,這與微服務的思路是一脈相通的,只不過實現方式沒有現在這麼規範與體系。

那「 微服務 」到底是怎麼演變過來的呢?

在做一個新項目的時候,一開始項目大多數都很小,都是「 單體應用 」,這是很常見的做法。在項目規模小的時候,這種方式開發效率和運維效率都最高,符合互聯網公司快速響應的要求。

但是隨著業務量越來越大,項目也越來越複雜,開發團隊人員也越來越多。這個時候還採用單體應用,問題就會很明顯了。下麵挑選兩個最為常見的問題來舉例:

  • 協同問題:多個人同時開發一份代碼,在工作協同上就會經常遇到代碼衝突問題。
  • 可用性問題:因為是單體應用,即使改個最小的功能,也需要整體發佈,不僅直接影響了線上可用性,還可能會對正常功能帶來風險。

為瞭解決這些問題,大家就開始考慮將「 單體應用 」進行拆分,進行服務化部署。然後又隨著 Martin Fowler對「 微服務 」概念的提出,加上 DevOps 的流行,進一步促進了微服務的火熱發展。

「 微服務 」的理念提倡每個服務都是單一職責,且每一個服務都能實現自治,因此可以帶來一些明顯好處:

  • 部署簡單:每個微服務都可以獨立去部署,方便快捷。
  • 邏輯清晰:將一個獨立功能邏輯封裝在單一微服務裡面,實現整體項目的邏輯清晰。
  • 可擴展:因為可以隨時增加和減少微服務,可以很方便的擴展功能。
  • 可靠性高:某一個功能的異常可以隔離在單一微服務裡面,可以提高整體可靠性。

二、「 微服務 」的架構是什麼樣?

我們先來看一下「 微服務 」的架構圖:

img

(圖片來源網路,粉絲太少就懶得畫圖了,大家發揮一下想象力將就的看看,哈哈)

看起來挺複雜對不對,事實上也確實很複雜。

所以微服務並不是適用於所有項目、所有團隊的。在應用之前一定要搞清楚是否適合自己。

要保證這麼一套微服務架構能成功運行起來,我們起碼需要以下這些 微服務的基礎組件

  • 服務註冊

    部署了一個微服務節點,得讓調用者知道啊,當微服務節點有增加或減少的時候,也得讓調用者及時知曉啊。這些問題都是通過“服務註冊”組件來實現的,服務提供者將自己的服務地址等信息登記到“服務註冊”組件中,調用者需要的時候,每次都先去查詢“服務註冊”即可。免去人工維護微服務節點的信息同步問題。

  • 服務網關

    是指提供給外部系統調用的是統一網關。主要做安全和許可權控制等。

  • 配置中心

    微服務的配置中心是用來統一管理所有微服務節點的配置信息的。因為同一個程式可能要適用於多個環境,所以在微服務實踐中要儘量做到程式與配置分離,將配置進行集中管理。包括微服務節點信息、程式運行時配置、變數配置、數據源配置、日誌配置、版本配置等。

  • 服務框架

    是指用來規範各個微服務節點之間通信標準的。服務間通信採用什麼協議、數據是如何傳輸的、數據格式是什麼樣的。有了這個統一的“服務框架”就能保證各個微服務節點之間高效率的協同。

  • 服務監控

    微服務運行起來之後,為了能夠監控節點的健康情況,保障節點的高可行,需要對各個服務節點進行收集數據指標、然後對數據進行實時處理和分析,形成監控報表和預警。

  • 服務追蹤

    一旦使用了微服務架構,那麼當有請求過來時,就會經過多個微服務節點的處理,形成了一個調用鏈。為了進行問題追蹤和故障的定位,需要對請求的完整調用鏈進行記錄。

    這裡的服務追蹤與上面的服務監控是不同維度的,一個是全局的,一個是微觀的,發揮的作用也不一樣。

  • 服務治理

    就是指需要通過準備一些策略和方案,來保障整個微服務架構在生產環境遇到極端情況下也能正常提供服務的措施。比如 熔斷、限流、隔離等等。

當然,上述只是一個微服務架構最為核心的基礎組件,一旦微服務體系過大,例如有幾十上百個微服務節點,那麼開發、維護、測試的成本就會非常大。因此一般還會引入 自動化部署 和 自動化測試 來提高協同效率。

三、「 微服務 」入門如何避免踩坑?

你以為微服務架構都是下麵這樣的嗎?

img

事實上,更能是下麵這樣的,哈哈。

img

(圖片來源網路)

大家都在宣揚「 微服務 」多麼多麼的好,例如:易擴展、松耦合、服務簡單、獨立開發、易維護、輕量級等等。雖然這些優勢也是事實,但是「 微服務 」帶來的問題也很多,尤其是對於剛入門的團隊而言,應用微服務後,趟坑真的可以趟到你崩潰。下麵就普及一些常見的問題來給大家打個預防針:

  • 不是所有項目都適用微服務

    有些項目規模還比較小,或者項目才剛立項啟動,也只有三四個人負責開發維護,這時候是不建議一上來就搞微服務架構的。這種情況下搞微服務,不僅是“殺雞用牛刀”,而且還無謂的增加了項目的複雜度,本身一個單體結構就可以搞定的事情,非得拆分N多節點,人員又不足以支撐這麼多節點的開發維護,這完全是自找苦吃。反而是等項目成熟了、規模大了之後,再開始慢慢將原有結構拆為微服務才是正確的做法。

  • 不要拆分過多過細的服務

    即使項目經過評估後適合拆為微服務架構,但也不要過度拆解。有的團隊喜歡將項目拆成很細很細的顆粒,最後把項目搞的特別複雜,整個團隊都陷進去了。

    拆分服務的顆粒度應該根據業務發展和團隊現狀綜合去考慮。這裡可以參考一個很火的理論「 康威定律 」。什麼樣的團隊,就產生什麼樣的架構,微服務拆分的顆粒度是需要和團隊結構相匹配的。當你著手拆微服務的時候,得先評估一下團隊人員和素質,一般在開發期,2-3個人開發一個服務是合理的,在維護期,1個人維護2-3個服務也是合理的。

    如果拆分過細,開發人員跟不上,會嚴重降低大家的工作效率。並且過細的服務,會導致一個請求的調用鏈條很長,不僅會影響請求的響應時間,也會對線上問題排查帶來增加難度。

  • 沒有DevOps就不要急於微服務

    一個穩定的微服務架構,是需要 持續集成、自動化部署、自動化測試、健全的監控體系來保障的。如果團隊還不具備DevOps,這些基礎的建設都沒有做好,一上來就搞微服務的話,就會導致實施過程中問題百出,微服務的優勢不能發揮。

以上,就是對架構設計中「 微服務基礎 」的一些思考。


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • 這是一個非常老牌的Bootstrap商業模板,全面性和穩定性俱佳 ...
  • JavaScript中的閉包 JavaScript中的閉包 介紹 在大多數常用語言中,函數返回後,所有局部變數不再可訪問,因為堆棧幀已被銷毀。牢記這一點,閉包可以被看作是當函數返回時不會釋放的棧幀。 為什麼使用閉包 我有很多人問我為什麼要關閉。我會儘力解釋。 我遇到過閉包的場景是使用Tabular ...
  • 什麼是事件冒泡 <div style="width: 200px;height: 200px;background: red;margin: 200px auto;" onclick="box()"> <p onclick="test()" style="background: blue"> wub ...
  • 1.無限滾動的運用場景: 一般運用在列表展示,有分頁、下拉載入更多的需求中。 2.代碼分析 代碼很簡單,實現了列表分頁,數據載入完之後顯示數據狀態 參考mint-ui官網介紹 1.為HTML元素添加v-infinite-scroll指令即可使用無限滾動。 2.滾動該元素,當其底部與被滾動元素底部的距 ...
  • 這裡先放上官網的教程和說明:點擊這裡,vue導航守衛官方文檔 路由守衛 路由守衛說白了就是路由攔截,在地址欄跳轉之前 之後 跳轉的瞬間 乾什麼事 全局守衛 全局守衛顧名思義,就是全局的,整個項目所有路由,跳轉所用到的守衛(攔截),設置了全局守衛之後,只要路由(瀏覽器地址欄)發生變化就會觸發的事件 全 ...
  • [toc] 1. 搭建環境 2. React知識點 1. 組件 組件:就是將整個UI拆分為很多小的,可重用的UI,每一個小的UI獨立做自己的事情。 1.1 定義一個組件 一個組件需要繼承 重寫 函數,返回 註意點: 1.只要有JSX的地方必須引入 2.返回值中只能有一個元素包裹, 包裹整個JSX,如 ...
  • 該文章用於督促自己學習TypeScript,作為學筆記進行保存,如果有錯誤的地方歡迎指正 2019-03-27 16:50:03 一、什麼是TypeScript? TypeScript是javascript的超集,在ts中可以使用所有的js代碼,並對js進行了擴展,包括類型效驗,數據類型,介面等 如 ...
  • 轉發:https://www.jianshu.com/p/f581cf9360a2 背景介紹 什麼是npm? npm(node package manager)是nodejs的包管理器,用於node插件管理(包括安裝、卸載、管理依賴等), NPM是隨同NodeJS一起安裝的包管理工具,能解決Node ...
一周排行
    -Advertisement-
    Play Games
  • 移動開發(一):使用.NET MAUI開發第一個安卓APP 對於工作多年的C#程式員來說,近來想嘗試開發一款安卓APP,考慮了很久最終選擇使用.NET MAUI這個微軟官方的框架來嘗試體驗開發安卓APP,畢竟是使用Visual Studio開發工具,使用起來也比較的順手,結合微軟官方的教程進行了安卓 ...
  • 前言 QuestPDF 是一個開源 .NET 庫,用於生成 PDF 文檔。使用了C# Fluent API方式可簡化開發、減少錯誤並提高工作效率。利用它可以輕鬆生成 PDF 報告、發票、導出文件等。 項目介紹 QuestPDF 是一個革命性的開源 .NET 庫,它徹底改變了我們生成 PDF 文檔的方 ...
  • 項目地址 項目後端地址: https://github.com/ZyPLJ/ZYTteeHole 項目前端頁面地址: ZyPLJ/TreeHoleVue (github.com) https://github.com/ZyPLJ/TreeHoleVue 目前項目測試訪問地址: http://tree ...
  • 話不多說,直接開乾 一.下載 1.官方鏈接下載: https://www.microsoft.com/zh-cn/sql-server/sql-server-downloads 2.在下載目錄中找到下麵這個小的安裝包 SQL2022-SSEI-Dev.exe,運行開始下載SQL server; 二. ...
  • 前言 隨著物聯網(IoT)技術的迅猛發展,MQTT(消息隊列遙測傳輸)協議憑藉其輕量級和高效性,已成為眾多物聯網應用的首選通信標準。 MQTTnet 作為一個高性能的 .NET 開源庫,為 .NET 平臺上的 MQTT 客戶端與伺服器開發提供了強大的支持。 本文將全面介紹 MQTTnet 的核心功能 ...
  • Serilog支持多種接收器用於日誌存儲,增強器用於添加屬性,LogContext管理動態屬性,支持多種輸出格式包括純文本、JSON及ExpressionTemplate。還提供了自定義格式化選項,適用於不同需求。 ...
  • 目錄簡介獲取 HTML 文檔解析 HTML 文檔測試參考文章 簡介 動態內容網站使用 JavaScript 腳本動態檢索和渲染數據,爬取信息時需要模擬瀏覽器行為,否則獲取到的源碼基本是空的。 本文使用的爬取步驟如下: 使用 Selenium 獲取渲染後的 HTML 文檔 使用 HtmlAgility ...
  • 1.前言 什麼是熱更新 游戲或者軟體更新時,無需重新下載客戶端進行安裝,而是在應用程式啟動的情況下,在內部進行資源或者代碼更新 Unity目前常用熱更新解決方案 HybridCLR,Xlua,ILRuntime等 Unity目前常用資源管理解決方案 AssetBundles,Addressable, ...
  • 本文章主要是在C# ASP.NET Core Web API框架實現向手機發送驗證碼簡訊功能。這裡我選擇是一個互億無線簡訊驗證碼平臺,其實像阿裡雲,騰訊雲上面也可以。 首先我們先去 互億無線 https://www.ihuyi.com/api/sms.html 去註冊一個賬號 註冊完成賬號後,它會送 ...
  • 通過以下方式可以高效,並保證數據同步的可靠性 1.API設計 使用RESTful設計,確保API端點明確,並使用適當的HTTP方法(如POST用於創建,PUT用於更新)。 設計清晰的請求和響應模型,以確保客戶端能夠理解預期格式。 2.數據驗證 在伺服器端進行嚴格的數據驗證,確保接收到的數據符合預期格 ...