成小胖學習微服務架構·基礎篇

来源:http://www.cnblogs.com/cyfonly/archive/2017/01/06/6251944.html
-Advertisement-
Play Games

隨著 RESTful、雲計算、DevOps、持續交付等概念的深入人心,微服務架構逐漸成為系統架構的一個代名詞。本文從理論出發,介紹微服務架構的概念、本質特征及優缺點,並與當前普遍的單塊(三層)架構進行全方面對比,讓你對微服務架構有很好的認知。 ...


看到最近“微服務架構”這個概念這麼火,作為一個積極上進的程式猿,成小胖忍不住想要學習學習。而架構師老王(不是隔壁老王)最近剛好在做公司基礎服務的微服務化研究和落地,對此深有研究。

於是成小胖馬上屁顛屁顛的跑過去向老王請教:“王哥,我看微服務架構這麼火,我也想學,您給我講講啥是微服務架構唄?”

老王笑了笑說:“要想知道什麼是微服務架構,你得先知道什麼系統架構設計。”

成小胖的理想是成為一名架構師,平時積累了不少知識,因此對“系統架構設計”這個概念還是很熟悉的,因此他馬上就給出了答案【1】

系統架構設計描述了在應用系統的內部,如何根據業務、技術、組織、靈活性、可擴展性以及可維護性等多種因素,將應用系統劃分成不同的部分,並使這些部分彼此之間相互分工、相互協作,從而為用戶提供某種特定的價值的方式。

老王滿意的點點頭,繼續問:“你看最近我在做微服務的研究和落地,你知道為什麼要做這個事情嗎?”

“因為目前的三層架構存在很多弊端,不滿足業務發展的需求了唄。”

“對的,我看你對公司目前的架構也非常熟悉了,你來仔細說說現在的三層架構吧。”

於是成小胖拿了一張A4紙,圖文並茂地給老王講了他對三層架構的理解

三層架構是指在業務和技術的發展過程中,系統中不同職責的部分被定義在不同的層次,每一層負責的功能更加具體化。三層架構通常包括表示層、業務邏輯層和數據訪問層,層與層之間互相連接、互相協作,構成一個整體,並且層的內部可以被替換成其他可以工作的部分,但對整體的影響不大。

以 Web 應用程式為例,早期是將所有的表示邏輯、業務邏輯和數據訪問邏輯放在一起,這就是一層架構。

後來隨著 java、.NET 等高級語言的發展,提供了越來越方便的數據訪問機制,如 java 的 JDBC 和 .NET 的 ADO.NET。這時數據訪問部分被分離開來,形成了二層架構。

再後來,隨著面向對象設計、企業架構模式等理念的不斷發展,表示邏輯和業務邏輯也被分離開來,形成了現在的三層架構。

三層架構的具體內容如下:

  • 表示層: 用戶使用應用程式時,看到的、聽見的、輸入的或者交互的部分。
  • 業務邏輯層: 根據用戶輸入的信息,進行邏輯計算或者業務處理的部分。
  • 數據訪問層: 關註有效地操作原始數據的部分,如將數據存儲到存儲介質(如資料庫、文件系統)及從存儲介質中讀取數據等。

老王對這個解釋非常滿意,作了進一步的補充:“你看雖然現在程式被分成了三層,但只是邏輯上的分層,並不是物理上的分層。也就是說,對不同層的代碼而言,經過編譯、打包和部署後,所有的代碼最終還是運行在同一個進程中。而這,就是所謂的單塊架構。”

成小胖撓了撓頭:“原來單塊架構是這個意思啊~~”

“嗯。根據你的實際工作經驗,你再總結下單塊架構的優缺點吧。”

平時勤於總結的成小胖很快便列出了單塊架構的優缺點:

 優點:

  • 易於開發: 開發方式簡單,IDE 支持好,方便運行和調試。
  • 易於測試: 所有功能運行在一個進程中,一旦進程啟動,便可以進行系統測試。
  • 易於部署: 只需要將打好的一個軟體包發佈到伺服器即可。
  • 易於水平伸縮: 只需要創建一個伺服器節點,配置好運行時環境,再將軟體包發佈到新伺服器節點即可運行程式(當然也需要採取分發策略保證請求能有效地分發到新節點)。

缺點:

  • 維護成本大: 當應用程式的功能越來越多、團隊越來越大時,溝通成本、管理成本顯著增加。當出現 bug 時,可能引起 bug 的原因組合越來越多,導致分析、定位和修複的成本增加;並且在對全局功能缺乏深度理解的情況下,容易在修複 bug 時引入新的 bug。
  • 持續交付周期長: 構建和部署時間會隨著功能的增多而增加,任何細微的修改都會觸發部署流水線。
  • 新人培養周期長: 新成員瞭解背景、熟悉業務和配置環境的時間越來越長。
  • 技術選型成本高: 單塊架構傾向於採用統一的技術平臺或方案來解決所有問題,如果後續想引入新的技術或框架,成本和風險都很大。
  • 可擴展性差: 隨著功能的增加,垂直擴展的成本將會越來越大;而對於水平擴展而言,因為所有代碼都運行在同一個進程,沒辦法做到針對應用程式的部分功能做獨立的擴展。

老王拍了拍成小胖的肩膀,眼睛眯成了一條縫:“小伙子總結的很不錯!既然你已經對目前的單塊架構的優缺點有了很好的理解,那現在咱們就可以開始來學習微服務架構了。”

老王先從網上搜索“微服務架構”關鍵字,出來這麼一段話:

微服務架構是一種架構模式,它提倡將單一應用程式劃分成一組小的服務,服務之間互相協調、互相配合,為用戶提供最終價值。每個服務運行在其獨立的進程中,服務於服務間採用輕量級的通信機制互相溝通(通常是基於 HTTP 的 RESTful API)。每個服務都圍繞著具體業務進行構建,並且能夠被獨立地部署到生產環境、類生產環境等。另外,應儘量避免統一的、集中式的服務管理機制,對具體的一個服務而言,應根據業務上下文,選擇合適的語言、工具對其進行構建。

成小胖看完了這段話,說:“看著有點暈,雲里霧裡的感覺……”

老王嘿嘿一笑:“莫慌,現在就給你詳細講講微服務架構的特性。” 

1. 單一職責

微服務架構中的每個服務,都是具有業務邏輯的,符合高內聚、低耦合原則以及單一職責原則的單元,不同的服務通過“管道”的方式靈活組合,從而構建出龐大的系統。

2. 輕量級通信

服務之間通過輕量級的通信機制實現互通互聯,而所謂的輕量級,通常指語言無關、平臺無關的交互方式。

對於輕量級通信的格式而言,我們熟悉的 XML 和 JSON,它們是語言無關、平臺無關的;對於通信的協議而言,通常基於 HTTP,能讓服務間的通信變得標準化、無狀態化。目前大家熟悉的 REST(Representational State Transfer)是實現服務間互相協作的輕量級通信機制之一。使用輕量級通信機制,可以讓團隊選擇更適合的語言、工具或者平臺來開發服務本身。

3. 獨立性

每個服務在應用交付過程中,獨立地開發、測試和部署。

在單塊架構中所有功能都在同一個代碼庫,功能的開發不具有獨立性;當不同小組完成多個功能後,需要經過集成和回歸測試,測試過程也不具有獨立性;當測試完成後,應用被構建成一個包,如果某個功能存在 bug,將導致整個部署失敗或者回滾。

在微服務架構中,每個服務都是獨立的業務單元,與其他服務高度解耦,只需要改變當前服務本身,就可以完成獨立的開發、測試和部署。

4. 進程隔離

單塊架構中,整個系統運行在同一個進程中,當應用進行部署時,必須停掉當前正在運行的應用,部署完成後再重啟進程,無法做到獨立部署。

有時候我們會將重覆的代碼抽取出來封裝成組件,在單塊架構中,組件通常的形態叫做共用庫(如 jar 包或者 DLL),但是當程式運行時,所有組件最終也會被載入到同一進程中運行。

在微服務架構中,應用程式由多個服務組成,每個服務都是高度自治的獨立業務實體,可以運行在獨立的進程中,不同的服務能非常容易地部署到不同的主機上。

理論上所有服務可以部署在同一個伺服器節點,但是並不推薦這麼做,因為微服務架構的主旨就是高度自治和高度隔離。

“王哥你真厲害,您這麼一說我的思維清晰了很多!”成小胖激動的幾乎要叫起來。

“我之前瞭解過 SOA,好像跟微服務架構的思想很像啊,您能幫我區分一下嗎?”成小胖追問到。

老王嘿嘿一笑,拿起成小胖手上的A4紙,翻到另外一面畫了個表格:

SOA實現 微服務架構實現
企業級,自頂向下開展實施 團隊級,自底向上開展實施
服務由多個子系統組成,粒度大 一個系統被拆分成多個服務,粒度細
企業服務匯流排,集中式的服務架構 無集中式匯流排,鬆散的服務架構
集成方式複雜(ESB/WS/SOAP) 集成方式簡單(HTTP/REST/JSON)
單塊架構系統,相互依賴,部署複雜 服務能獨立部署

 

 

 

 

 

 

接著老王又畫了一張圖:

成小胖看了之後說:“您這麼一畫我倒是大概明白了,但是圖裡面的 DevOps 這個概念我不懂誒……”

“這個 DevOps 就說來話長了,有時間你自己先去查查資料瞭解下吧。”

“好的。現在我對微服務架構的概念有了瞭解,您能再深入剖析下它的本質嗎?”

“好,你可仔細聽好了哈!” 

1. 服務作為組件

微服務也可以被認為是一種組件,但是跟傳統組件的區別在於它可以獨立部署,因此它的一個顯著的優勢。另外一個優點是,它在組件與組件之間定義了清晰的、語言無關、平臺無關的規範介面,耦合度低,靈活性非常高。但它的不足之處是,分散式調用嚴重依賴於網路的可靠性和穩定性。

2. 圍繞業務組織團隊

在單塊架構中,企業一般會根據技能劃分團隊,在這種組織架構下,即便是簡單的需求變更都有可能需要跨團隊協作,溝通成本很高。而在微服務架構中,它提倡以業務為核心,按照業務能力來組織團隊,團隊中的成員具有多樣性的技能。

3. 關註產品而非項目

在單塊架構中,應用基本上是基於“項目模式”構建的,即項目啟動時從不同技能資源池中抽取相關資源組成團隊,項目結束後釋放所有資源。這種情況下團隊成員缺乏主人翁意識和產品成就感。

 

在微服務架構中,提倡採用“產品模式”構建,即更傾向於讓團隊負責整個服務的生命周期,以便提供更優質的服務。

 

4. 技術多樣性

微服務架構中,提倡針對不同的業務特征選擇合適的技術方案,有針對性的解決具體業務問題,而不是像單塊架構中採用統一的平臺或技術來解決所有問題。

5. 業務數據獨立

微服務架構提供自主管理其相關的業務數據,這樣可以隨著業務的發展提供數據介面集成,而不是以資料庫的方式同其他服務集成。另外,隨著業務的發展,可以方便地選擇更合的工具管理或者遷移業務數據。

6. 基礎設施自動化

在微服務架構的實踐過程中,對持續交付和部署流水線的要求很高,將促進企業不斷尋找更高效的方式完成基礎設施的自動化及 DevOps 運維能力的提升。

聽完成小胖忍不住表達了敬佩之意:“老司機就是老司機,噢說錯了……架構師就是架構師,總結得這麼簡潔又深刻!”

“咳咳,低調低調……”

“聽您講解了這麼多,我覺得微服務架構解決了很多當前三層架構的痛點。不過我覺得沒有任何一項技術或架構是完美的。”

“非常正確。進行微服務架構的落地是存在很多挑戰的。” 

1. 分散式系統的複雜性

微服務架構是基於分散式的系統,而構建分散式系統必然會帶來額外的開銷。

  • 性能: 分散式系統是跨進程、跨網路的調用,受網路延遲和帶寬的影響。
  • 可靠性: 由於高度依賴於網路狀況,任何一次的遠程調用都有可能失敗,隨著服務的增多還會出現更多的潛在故障點。因此,如何提高系統的可靠性、降低因網路引起的故障率,是系統構建的一大挑戰。
  • 非同步: 非同步通信大大增加了功能實現的複雜度,並且伴隨著定位難、調試難等問題。
  • 數據一致性: 要保證分散式系統的數據強一致性,成本是非常高的,需要在 C(一致性)A(可用性)P(分區容錯性) 三者之間做出權衡。

2. 運維成本

運維主要包括配置、部署、監控與告警和日誌收集四大方面。微服務架構中,每個服務都需要獨立地配置、部署、監控和收集日誌,成本呈指數級增長。

3. 自動化部署

在微服務架構中,每個服務都獨立部署,交付周期短且頻率高,人工部署已經無法適應業務的快速變化。因此如何有效地構建自動化部署體系,是微服務面臨的另一個挑戰。

4. DevOps 與組織架構

在微服務架構的實施過程中,開發人員和運維人員的角色發生了變化,開發者將承擔起整個服務的生命周期的責任,包括部署和監控;而運維則更傾向於顧問式的角色,儘早考慮服務如何部署。因此,按需調整組織架構、構建全功能的團隊,也是一個不小的挑戰。

5. 服務間的依賴測試

單塊架構中,通常使用集成測試來驗證依賴是否正常。而在微服務架構中,服務數量眾多,每個服務都是獨立的業務單元,服務主要通過介面進行交互,如何保證依賴的正常,是測試面臨的主要挑戰。

6. 服務間的依賴管理

微服務架構中,服務數量眾多,如何清晰有效地展示服務間的依賴關係也是個不小的挑戰。

“微服務的落地需要經過全面的考察和完善的試驗,並不是每個場景都適合使用微服務架構,也不是每個企業都有能力或者精力去面對這些挑戰。”老王最後語重心長的說。

“嗯嗯,每件事都有兩面性,最合適的才是最好的!對了王哥,您已經給我上完理論課了,啥時候帶我實踐下唄?”

“你先好好消化完今天講的這些,下次再說吧……”

“好吧,很期待我們的下一次交流……”

 

 

【1】圖片源及內容主要參考《微服務架構與實踐》。


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

-Advertisement-
Play Games
更多相關文章
  • YII 2.x 模板文件的 beginBlock、beginContent、beginCache ...
  • 1 #include 2 #include 3 #include 4 struct student //定義結構體 5 { 6 char name[7]; //姓名 7 int number; //號碼 8 }student,student1; 9 void menu() //顯示欄 10 { 11... ...
  • 一.圖片驗證碼概述:很多網站都有該實現作用:為了提高系統的安全性有了驗證碼,我們就可以要求用戶在輸入用戶名,密碼等信息後,同時輸入圖片上的文字,用戶提交後,系統會首先從session中提取剛剛生成的驗證碼,並和用戶輸入的驗證碼進行比較,如果比較相等,表示用戶是從登錄界面登錄過來的,否則,表示用戶是非 ...
  • 在Spring+Struts+Hibernate中,有時需要使用到Spring上下文。項目啟動時,會自動根據applicationContext配置文件初始化上下文,可以使用ApplicationContextAware介面去獲得Spring上下文。創建以下的類: 在applicationConte ...
  • 大家好,今天我們學習了Java如何連接資料庫。之前學過.net語言的資料庫操作,感覺就是一通百通,大同小異。 JDBC是Java資料庫連接技術的簡稱,提供連接各種常用資料庫的能力。 JDBC API (主要功能:與資料庫建立連接、執行語句、處理結果): 提供者:Sun公司 內容:供程式員調用的介面與 ...
  • 首先為什麼要自己編寫Dockerfile來構建 nginx、php、mariadb這三個鏡像呢?一是希望更深入瞭解Dockerfile的使用,也就能初步瞭解docker鏡像是如何被構建的;二是希望將來可以定製自己的images,特別是能針對不同的系統環境與目標需求適當對鏡像進行調整改進。在編輯Doc... ...
  • Chatper 5 原型模式 核心思想是一個對象可以生成與自身相似的其他對象。 基類Monster,有一個抽象方法clone: 1 class Monster 2 { 3 public: 4 5 virtual ~Monster() {} 6 virtual Monster* clone() = 0 ...
  • 本文地址 分享提綱: 1. 概述 2. 知識點 1.概述 1)【書名及鏈接】 《大型網站技術架構 核心原理與案例分析》 2)【主要內容】 由李智慧著作的《大型網站技術架構(核心原理與案例分析)》通過梳理大型網站技術發展歷程,剖析大型網站技術架構模式,深入講述大型互聯網架構設計的核心原理,並通過一組典 ...
一周排行
    -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.數據驗證 在伺服器端進行嚴格的數據驗證,確保接收到的數據符合預期格 ...