博文谷

位置:首頁 > 實用範文 > 論文

程序開發中微服務架構和容器的結合運用論文

論文1.37W

摘要:文章分析了微服務架構和容器技術的應用。微服務架構是一種架構概念, 透過將功能分解到各個離散的服務中以實現對解決方案的解耦, 在降低系統耦合的同時, 還提供了十分靈活的服務支援, 這種架構對應用的功能進行了充分的分離, 使開發和部署非常的便捷, 結合容器技術, 最大化地解決微服務架構中所面臨的負載, 對微服務進行更有效的支撐。微服務架構中對容器技術的應用主要看中容器的對解決複雜環境和用戶資源隔離問題的能力, 這種新的開發方式爲開發者提供了一種新的思路。

程序開發中微服務架構和容器的結合運用論文

關鍵詞:微服務; 容器; 共享; 解耦

微服務架構的產生是軟件架構不斷演進的結果。Web開發經歷了單體結構, 集羣結構, 分佈式系統, 最終演化到微服務架構。微服務架構按照業務劃分模組, 實現一個個高度解耦的系統架構, 其中的分佈式、快速演化、自動化運維和高容錯性這些優點, 受到了大批互聯網公司的青睞。在保障軟件架構的靈活伸縮, 系統架構分佈合理的同時, Docker容器的加入, 進一步降低了微服務的成本, 反過來也使得微服務和容器結合得越來越緊密。特別是雲端平臺的興起, 加速了這種趨勢[1]。

1 設計架構的演變。

1.1 單體結構。

此時公司業務量比較小, 系統構建並不複雜, 所有的代碼, 數據庫, 檔案都部署在一臺機器上, 對系統服務進行常規的應用服務和數據服務分離, 增加快取可以滿足此時的訪問量。

1.2 集羣結構。

公司業務逐漸增加, 用戶量增大, 服務器壓力也隨之增大, 高峯期已經不能滿足用戶的操作, 於是增加服務器分擔原有服務器的訪問和壓力, 同時有了負載均衡, 反向代理, 數據庫讀寫分離的應對方案。

1.3 分佈式系統。

公司業務繼續發展, 用戶規模和業務複雜已經到了一個量級, 於是開始把一個系統拆成許多不同的應用, 每個應用進行獨立的開發、測試、運維, 應用之間透過消息隊列來進行數據分發, 也可以訪問同一個數據存儲來構成一個關聯完整的系統。

1.4 微服務架構。

微服務架構以去中心化爲特點。大規模用戶的使用需求, 對分佈式系統的要求很高, 並且業務快速發展, 迭代週期很短, 子系統也不需要如原來企業計算分佈式那樣採用集中式存儲, 通常採取前後端分離的方式, 使單個業務系統組件化, 不同的服務之間採用輕量級的交互機制進行交互, 使各個子系統做到有效分割, 結合Docker容器, 使得微服務能進行實際的應用。

2 微服務的特性。

2.1 微服務架構的優勢。

2.1.1 降低複雜性。

微服務架構透過分解單體式應用爲多個服務方法, 降低了系統的複雜性, 多個子系統的分離實現了組件化, 一個個組件成爲可管理的分支或服務, 使其透過模組化的方式呈現出來。透過微服務這種架構模式, 讓單個服務更容易開發和維護。

2.1.2 部署的獨立性。

每個微服務都具備相對獨立的執行進程和業務處理的能力, 所以每個微服務的安裝和部署都可以獨立進行。在傳統的架構中, 如果要對某一程序內的某一功能區進行變更, 就需要對整體架構進行統一的重新建設, 並進行重新部署。而微服務架構在變更時, 由於其單個微服務的獨立性, 不需要對整個應用進行編譯和部署, 這大大提高了效率, 也降低了對系統環境所造成的風險, 縮短了原有的時間操作週期。

2.1.3 容錯性高。

在傳統單一的構架中, 如果某一組的應用功能發生故障, 那麼系統整體的穩定性就會受到影響, 子系統出現故障, 影響會在其他的子系統中蔓延, 輕的後果是會導致局部的系統受到影響, 部分業務無法得到處理, 嚴重的後果是導致整個應用系統的崩潰。在微服務構架中, 由於單個服務的獨立性, 所以故障的影響可以控制在單個的應用中, 並不會對其他的服務造成影響, 而且微服務中有提前審計的功能, 有多種機制可以保證應用執行的穩定[2]。

2.1.4 技術靈活。

微服務構架有多種技術的選擇, 常見的Java, Node Js, Python, React Native都可以實現具體的微服務邏輯, 也可以混合使用。透過對技術的合理選擇, 節省成本的同時, 做到專業分工。在使用不同的技術對微服務架構進行整合和部署的過程中, 由於微服務的相對簡單, 在升級的時候面臨更小的破壞風險, 微服務的技術重構也更具有可行性[3]。

2.1.5 易擴展。

微服務的架構中, 系統的獨立性比較強, 保證了系統的擴展性也比較強, 其擴展的方向也相對較多, 在橫向的擴展中可以使相同維度的業務實現無縫銜接, 當不同的組件間接口出現差異的時候, 其獨立性也可以大大降低銜接的複雜性。在縱向的方向上, 組件化也使得多個維度的業務能有序地進行數據交互, 微服務架構的特點大大降低了擴展風險。

2.2 微服務架構面臨的問題。

微服務的複雜性主要體現於分佈式這種架構方式上。由於應用的是分佈式系統, 給開發時帶來了天然的系統複雜性。開發者需要在RPC或消息傳遞之間選擇進程間通信機制, 更甚於開發者必須平衡消息傳遞過快或者過慢的問題, 顯然這加大了服務的複雜性[4]。

另一個挑戰是數據庫分區架構。在微服務的應用中, 應用需要同時服務多個數據庫。No SQL數據庫和資訊代理的機制的系統, 並不支援分佈式交易, 這對開發者帶來了很高的挑戰。

3 容器技術。

容器技術的使用, 使得微服務器架構中所面臨的壓力得到很大程度上的緩解。容器技術的特點爲微服務構架提供了落地的機會, 其中的內核機制可以實現不同的容器之間的聯繫, 容器之間資源也能實現完全的隔離, 它們中有一個典型的代表—Docker。

容器技術的高速發展爲計算機的雲計算問題提供瞭解決的可能, 現在多重容器技術都已經成爲容器的.標準規範。Linux容器具有較多的功能, 也實現了十分規範的管理。微服務透過將單個應用程序分解, 實現了組件化, 又透過Kubemetes等技術將原有的集羣統一地編織在一起, 提供應用的部署、維護、擴展機制等功能, 實現對不同容器的有效管理[5]。

Docker是容器技術中的代表, 特點體現在具有標準的鏡像結構, 實現了對不同資源實行不同存儲的功能, 也能滿足大規模的託管服務, 對於有主機集羣的雲服務平臺, 透過分解應用構建、發佈等方式實現對雲計算技術的開發, 在實現雲計算平臺的構建的同時, 還可以進行優化和自動化維護環境, 使得工作的效率能夠得到有效的提升, 在降低成本的同時, 滿足了微服務架構所需要的資源。

Docker的體系中, 最關鍵的有兩個, Docker Register和Docker Engine, 前者負責構建和分發應用鏡像, 後者負責構建容器。這種組合方式, 是雲服務的軟件即服務 (Software as-a-Service, Saa S) 理念, 用戶可以在各自的數據中心內建立私有的Docker Register, 形成屬於自己的私有集羣, 以應對大規模的應用擴展需求[6]。Docker很像一個集裝箱, 透過Lxc技術先進行整合鏡像, 再集中彙總進行分發。

普通的虛擬機與容器技術有一定的相似性, 但是容器技術在很多細節和虛擬機並不相同。虛擬機建立在硬件平臺上, 而容器技術建立在操作系統 (Operating System, OS) 上, 可以把容器看作是虛擬機輕量化的實現。Docker在實現應用隔離的同時, 沒有虛擬機必須的虛擬化管理層, 對比虛擬機太長的啓動時間, 容器的啓動與停止可以在毫秒級這個範圍內啓動。比較這些特性, Docker容器顯然更勝虛擬機一籌。

4 基於容器的微服務應用。

Docker的細粒度鬆散耦合和微服務架構相得益彰。我們可以讓Docker容器裝載這樣一個場景功能, 按照不同的角色分類, 每一個容器裏裝一個服務和應用, 一個服務器中執行多個容器, 也可以將多個容器分散到多個服務器上執行。整個項目架構按照業務邏輯的規劃以細粒度的方式分散到了各個Docker中, 並可以根據Rest接口的方式進行整合聯動[7]。一個典型的例子可以是負載均衡層、綜合業務服務層、單業務服務層、存儲層。這種多分層的方式, 可以很好地保證容器對微服務的支援, 高效地保證每一層服務的執行。當然, 這種應用方式也是有些許弊端, 在架構設計的前期, 需要花費較多時間來進行詳細的系統分析和邏輯劃分。

5 結語。

微服務架構和容器的結合在程序開發中應用已經成爲一種新的開發方式, 透過不同的微服務實現業務架構的粒度化, 透過不同的容器承載不同的業務, 爲用戶提供更多的開發選擇。微服務構架中採用容器技術後, 一方面更加微型化;另一方面容器使微服務開發更加的便捷。這種開發方式將隨着時間的推移越來越流行。

參考文獻

[1]楊鷗, 張羿, 耿貞偉.微服務架構在容器雲中的應用實踐[J].電腦與電信, 2017 (7) :79-81.

[2]張晶, 黃小鋒, 李春陽.微服務框架的設計與實現[J].計算機系統應用, 2017 (6) :259-262.

[3]王紀軍, 張斌, 顧永生, 等.雲環境中Web應用的微服務架構評估[J].計算機系統應用, 2017 (5) :9-15.

[4]劉爲.微服務架構及相應雲平臺解析[J].科教導刊, 2017 (1) :27-28.

[5]佚名.容器+微服務成爲驅動混合IT關鍵[J].郵電設計技術, 2017 (1) :5.

[6]黃小鋒, 張晶.微服務框架介紹與實現[J].電腦與資訊技術, 2016 (6) :14-16.

[7]王健, 李冬睿.從單一模式系統架構往微服務架構遷移轉化技術研究[J].科教導刊, 2016 (9) :43-44.