程序開(kāi)發(fā)中微服務(wù)架構(gòu)和容器的結(jié)合運(yùn)用論文
摘要：文章分析了微服務(wù)架構(gòu)和容器技術(shù)的應(yīng)用。微服務(wù)架構(gòu)是一種架構(gòu)概念, 通過(guò)將功能分解到各個(gè)離散的服務(wù)中以實(shí)現(xiàn)對(duì)解決方案的解耦, 在降低系統(tǒng)耦合的同時(shí), 還提供了十分靈活的服務(wù)支持, 這種架構(gòu)對(duì)應(yīng)用的功能進(jìn)行了充分的分離, 使開(kāi)發(fā)和部署非常的便捷, 結(jié)合容器技術(shù), 最大化地解決微服務(wù)架構(gòu)中所面臨的負(fù)載, 對(duì)微服務(wù)進(jìn)行更有效的支撐。微服務(wù)架構(gòu)中對(duì)容器技術(shù)的應(yīng)用主要看中容器的對(duì)解決復(fù)雜環(huán)境和用戶(hù)資源隔離問(wèn)題的能力, 這種新的開(kāi)發(fā)方式為開(kāi)發(fā)者提供了一種新的思路。
關(guān)鍵詞：微服務(wù); 容器; 共享; 解耦
微服務(wù)架構(gòu)的產(chǎn)生是軟件架構(gòu)不斷演進(jìn)的結(jié)果。Web開(kāi)發(fā)經(jīng)歷了單體結(jié)構(gòu), 集群結(jié)構(gòu), 分布式系統(tǒng), 最終演化到微服務(wù)架構(gòu)。微服務(wù)架構(gòu)按照業(yè)務(wù)劃分模塊, 實(shí)現(xiàn)一個(gè)個(gè)高度解耦的系統(tǒng)架構(gòu), 其中的分布式、快速演化、自動(dòng)化運(yùn)維和高容錯(cuò)性這些優(yōu)點(diǎn), 受到了大批互聯(lián)網(wǎng)公司的青睞。在保障軟件架構(gòu)的靈活伸縮, 系統(tǒng)架構(gòu)分布合理的同時(shí), Docker容器的加入, 進(jìn)一步降低了微服務(wù)的成本, 反過(guò)來(lái)也使得微服務(wù)和容器結(jié)合得越來(lái)越緊密。特別是云端平臺(tái)的興起, 加速了這種趨勢(shì)[1]。
1 設(shè)計(jì)架構(gòu)的演變。
1.1 單體結(jié)構(gòu)。
此時(shí)公司業(yè)務(wù)量比較小, 系統(tǒng)構(gòu)建并不復(fù)雜, 所有的代碼, 數(shù)據(jù)庫(kù), 文件都部署在一臺(tái)機(jī)器上, 對(duì)系統(tǒng)服務(wù)進(jìn)行常規(guī)的應(yīng)用服務(wù)和數(shù)據(jù)服務(wù)分離, 增加緩存可以滿(mǎn)足此時(shí)的訪(fǎng)問(wèn)量。
1.2 集群結(jié)構(gòu)。
公司業(yè)務(wù)逐漸增加, 用戶(hù)量增大, 服務(wù)器壓力也隨之增大, 高峰期已經(jīng)不能滿(mǎn)足用戶(hù)的操作, 于是增加服務(wù)器分擔(dān)原有服務(wù)器的訪(fǎng)問(wèn)和壓力, 同時(shí)有了負(fù)載均衡, 反向代理, 數(shù)據(jù)庫(kù)讀寫(xiě)分離的應(yīng)對(duì)方案。
1.3 分布式系統(tǒng)。
公司業(yè)務(wù)繼續(xù)發(fā)展, 用戶(hù)規(guī)模和業(yè)務(wù)復(fù)雜已經(jīng)到了一個(gè)量級(jí), 于是開(kāi)始把一個(gè)系統(tǒng)拆成許多不同的應(yīng)用, 每個(gè)應(yīng)用進(jìn)行獨(dú)立的開(kāi)發(fā)、測(cè)試、運(yùn)維, 應(yīng)用之間通過(guò)消息隊(duì)列來(lái)進(jìn)行數(shù)據(jù)分發(fā), 也可以訪(fǎng)問(wèn)同一個(gè)數(shù)據(jù)存儲(chǔ)來(lái)構(gòu)成一個(gè)關(guān)聯(lián)完整的系統(tǒng)。
1.4 微服務(wù)架構(gòu)。
微服務(wù)架構(gòu)以去中心化為特點(diǎn)。大規(guī)模用戶(hù)的使用需求, 對(duì)分布式系統(tǒng)的'要求很高, 并且業(yè)務(wù)快速發(fā)展, 迭代周期很短, 子系統(tǒng)也不需要如原來(lái)企業(yè)計(jì)算分布式那樣采用集中式存儲(chǔ), 通常采取前后端分離的方式, 使單個(gè)業(yè)務(wù)系統(tǒng)組件化, 不同的服務(wù)之間采用輕量級(jí)的交互機(jī)制進(jìn)行交互, 使各個(gè)子系統(tǒng)做到有效分割, 結(jié)合Docker容器, 使得微服務(wù)能進(jìn)行實(shí)際的應(yīng)用。
2 微服務(wù)的特性。
2.1 微服務(wù)架構(gòu)的優(yōu)勢(shì)。
2.1.1 降低復(fù)雜性。
微服務(wù)架構(gòu)通過(guò)分解單體式應(yīng)用為多個(gè)服務(wù)方法, 降低了系統(tǒng)的復(fù)雜性, 多個(gè)子系統(tǒng)的分離實(shí)現(xiàn)了組件化, 一個(gè)個(gè)組件成為可管理的分支或服務(wù), 使其通過(guò)模塊化的方式呈現(xiàn)出來(lái)。通過(guò)微服務(wù)這種架構(gòu)模式, 讓單個(gè)服務(wù)更容易開(kāi)發(fā)和維護(hù)。
2.1.2 部署的獨(dú)立性。
每個(gè)微服務(wù)都具備相對(duì)獨(dú)立的運(yùn)行進(jìn)程和業(yè)務(wù)處理的能力, 所以每個(gè)微服務(wù)的安裝和部署都可以獨(dú)立進(jìn)行。在傳統(tǒng)的架構(gòu)中, 如果要對(duì)某一程序內(nèi)的某一功能區(qū)進(jìn)行變更, 就需要對(duì)整體架構(gòu)進(jìn)行統(tǒng)一的重新建設(shè), 并進(jìn)行重新部署。而微服務(wù)架構(gòu)在變更時(shí), 由于其單個(gè)微服務(wù)的獨(dú)立性, 不需要對(duì)整個(gè)應(yīng)用進(jìn)行編譯和部署, 這大大提高了效率, 也降低了對(duì)系統(tǒng)環(huán)境所造成的風(fēng)險(xiǎn), 縮短了原有的時(shí)間操作周期。
2.1.3 容錯(cuò)性高。
在傳統(tǒng)單一的構(gòu)架中, 如果某一組的應(yīng)用功能發(fā)生故障, 那么系統(tǒng)整體的穩(wěn)定性就會(huì)受到影響, 子系統(tǒng)出現(xiàn)故障, 影響會(huì)在其他的子系統(tǒng)中蔓延, 輕的后果是會(huì)導(dǎo)致局部的系統(tǒng)受到影響, 部分業(yè)務(wù)無(wú)法得到處理, 嚴(yán)重的后果是導(dǎo)致整個(gè)應(yīng)用系統(tǒng)的崩潰。在微服務(wù)構(gòu)架中, 由于單個(gè)服務(wù)的獨(dú)立性, 所以故障的影響可以控制在單個(gè)的應(yīng)用中, 并不會(huì)對(duì)其他的服務(wù)造成影響, 而且微服務(wù)中有提前審計(jì)的功能, 有多種機(jī)制可以保證應(yīng)用運(yùn)行的穩(wěn)定[2]。
2.1.4 技術(shù)靈活。
微服務(wù)構(gòu)架有多種技術(shù)的選擇, 常見(jiàn)的Java, Node Js, Python, React Native都可以實(shí)現(xiàn)具體的微服務(wù)邏輯, 也可以混合使用。通過(guò)對(duì)技術(shù)的合理選擇, 節(jié)省成本的同時(shí), 做到專(zhuān)業(yè)分工。在使用不同的技術(shù)對(duì)微服務(wù)架構(gòu)進(jìn)行整合和部署的過(guò)程中, 由于微服務(wù)的相對(duì)簡(jiǎn)單, 在升級(jí)的時(shí)候面臨更小的破壞風(fēng)險(xiǎn), 微服務(wù)的技術(shù)重構(gòu)也更具有可行性[3]。
2.1.5 易擴(kuò)展。
微服務(wù)的架構(gòu)中, 系統(tǒng)的獨(dú)立性比較強(qiáng), 保證了系統(tǒng)的擴(kuò)展性也比較強(qiáng), 其擴(kuò)展的方向也相對(duì)較多, 在橫向的擴(kuò)展中可以使相同維度的業(yè)務(wù)實(shí)現(xiàn)無(wú)縫銜接, 當(dāng)不同的組件間接口出現(xiàn)差異的時(shí)候, 其獨(dú)立性也可以大大降低銜接的復(fù)雜性。在縱向的方向上, 組件化也使得多個(gè)維度的業(yè)務(wù)能有序地進(jìn)行數(shù)據(jù)交互, 微服務(wù)架構(gòu)的特點(diǎn)大大降低了擴(kuò)展風(fēng)險(xiǎn)。
2.2 微服務(wù)架構(gòu)面臨的問(wèn)題。
微服務(wù)的復(fù)雜性主要體現(xiàn)于分布式這種架構(gòu)方式上。由于應(yīng)用的是分布式系統(tǒng), 給開(kāi)發(fā)時(shí)帶來(lái)了天然的系統(tǒng)復(fù)雜性。開(kāi)發(fā)者需要在RPC或消息傳遞之間選擇進(jìn)程間通信機(jī)制, 更甚于開(kāi)發(fā)者必須平衡消息傳遞過(guò)快或者過(guò)慢的問(wèn)題, 顯然這加大了服務(wù)的復(fù)雜性[4]。
另一個(gè)挑戰(zhàn)是數(shù)據(jù)庫(kù)分區(qū)架構(gòu)。在微服務(wù)的應(yīng)用中, 應(yīng)用需要同時(shí)服務(wù)多個(gè)數(shù)據(jù)庫(kù)。No SQL數(shù)據(jù)庫(kù)和信息代理的機(jī)制的系統(tǒng), 并不支持分布式交易, 這對(duì)開(kāi)發(fā)者帶來(lái)了很高的挑戰(zhàn)。
3 容器技術(shù)。
容器技術(shù)的使用, 使得微服務(wù)器架構(gòu)中所面臨的壓力得到很大程度上的緩解。容器技術(shù)的特點(diǎn)為微服務(wù)構(gòu)架提供了落地的機(jī)會(huì), 其中的內(nèi)核機(jī)制可以實(shí)現(xiàn)不同的容器之間的聯(lián)系, 容器之間資源也能實(shí)現(xiàn)完全的隔離, 它們中有一個(gè)典型的代表—Docker。
容器技術(shù)的高速發(fā)展為計(jì)算機(jī)的云計(jì)算問(wèn)題提供了解決的可能, 現(xiàn)在多重容器技術(shù)都已經(jīng)成為容器的標(biāo)準(zhǔn)規(guī)范。Linux容器具有較多的功能, 也實(shí)現(xiàn)了十分規(guī)范的管理。微服務(wù)通過(guò)將單個(gè)應(yīng)用程序分解, 實(shí)現(xiàn)了組件化, 又通過(guò)Kubemetes等技術(shù)將原有的集群統(tǒng)一地編織在一起, 提供應(yīng)用的部署、維護(hù)、擴(kuò)展機(jī)制等功能, 實(shí)現(xiàn)對(duì)不同容器的有效管理[5]。
Docker是容器技術(shù)中的代表, 特點(diǎn)體現(xiàn)在具有標(biāo)準(zhǔn)的鏡像結(jié)構(gòu), 實(shí)現(xiàn)了對(duì)不同資源實(shí)行不同存儲(chǔ)的功能, 也能滿(mǎn)足大規(guī)模的托管服務(wù), 對(duì)于有主機(jī)集群的云服務(wù)平臺(tái), 通過(guò)分解應(yīng)用構(gòu)建、發(fā)布等方式實(shí)現(xiàn)對(duì)云計(jì)算技術(shù)的開(kāi)發(fā), 在實(shí)現(xiàn)云計(jì)算平臺(tái)的構(gòu)建的同時(shí), 還可以進(jìn)行優(yōu)化和自動(dòng)化維護(hù)環(huán)境, 使得工作的效率能夠得到有效的提升, 在降低成本的同時(shí), 滿(mǎn)足了微服務(wù)架構(gòu)所需要的資源。
Docker的體系中, 最關(guān)鍵的有兩個(gè), Docker Register和Docker Engine, 前者負(fù)責(zé)構(gòu)建和分發(fā)應(yīng)用鏡像, 后者負(fù)責(zé)構(gòu)建容器。這種組合方式, 是云服務(wù)的軟件即服務(wù) (Software as-a-Service, Saa S) 理念, 用戶(hù)可以在各自的數(shù)據(jù)中心內(nèi)建立私有的Docker Register, 形成屬于自己的私有集群, 以應(yīng)對(duì)大規(guī)模的應(yīng)用擴(kuò)展需求[6]。Docker很像一個(gè)集裝箱, 通過(guò)Lxc技術(shù)先進(jìn)行整合鏡像, 再集中匯總進(jìn)行分發(fā)。
普通的虛擬機(jī)與容器技術(shù)有一定的相似性, 但是容器技術(shù)在很多細(xì)節(jié)和虛擬機(jī)并不相同。虛擬機(jī)建立在硬件平臺(tái)上, 而容器技術(shù)建立在操作系統(tǒng) (Operating System, OS) 上, 可以把容器看作是虛擬機(jī)輕量化的實(shí)現(xiàn)。Docker在實(shí)現(xiàn)應(yīng)用隔離的同時(shí), 沒(méi)有虛擬機(jī)必須的虛擬化管理層, 對(duì)比虛擬機(jī)太長(zhǎng)的啟動(dòng)時(shí)間, 容器的啟動(dòng)與停止可以在毫秒級(jí)這個(gè)范圍內(nèi)啟動(dòng)。比較這些特性, Docker容器顯然更勝虛擬機(jī)一籌。
4 基于容器的微服務(wù)應(yīng)用。
Docker的細(xì)粒度松散耦合和微服務(wù)架構(gòu)相得益彰。我們可以讓Docker容器裝載這樣一個(gè)場(chǎng)景功能, 按照不同的角色分類(lèi), 每一個(gè)容器里裝一個(gè)服務(wù)和應(yīng)用, 一個(gè)服務(wù)器中運(yùn)行多個(gè)容器, 也可以將多個(gè)容器分散到多個(gè)服務(wù)器上運(yùn)行。整個(gè)項(xiàng)目架構(gòu)按照業(yè)務(wù)邏輯的規(guī)劃以細(xì)粒度的方式分散到了各個(gè)Docker中, 并可以根據(jù)Rest接口的方式進(jìn)行整合聯(lián)動(dòng)[7]。一個(gè)典型的例子可以是負(fù)載均衡層、綜合業(yè)務(wù)服務(wù)層、單業(yè)務(wù)服務(wù)層、存儲(chǔ)層。這種多分層的方式, 可以很好地保證容器對(duì)微服務(wù)的支持, 高效地保證每一層服務(wù)的運(yùn)行。當(dāng)然, 這種應(yīng)用方式也是有些許弊端, 在架構(gòu)設(shè)計(jì)的前期, 需要花費(fèi)較多時(shí)間來(lái)進(jìn)行詳細(xì)的系統(tǒng)分析和邏輯劃分。
5 結(jié)語(yǔ)。
微服務(wù)架構(gòu)和容器的結(jié)合在程序開(kāi)發(fā)中應(yīng)用已經(jīng)成為一種新的開(kāi)發(fā)方式, 通過(guò)不同的微服務(wù)實(shí)現(xiàn)業(yè)務(wù)架構(gòu)的粒度化, 通過(guò)不同的容器承載不同的業(yè)務(wù), 為用戶(hù)提供更多的開(kāi)發(fā)選擇。微服務(wù)構(gòu)架中采用容器技術(shù)后, 一方面更加微型化;另一方面容器使微服務(wù)開(kāi)發(fā)更加的便捷。這種開(kāi)發(fā)方式將隨著時(shí)間的推移越來(lái)越流行。
參考文獻(xiàn)
[1]楊鷗, 張羿, 耿貞偉.微服務(wù)架構(gòu)在容器云中的應(yīng)用實(shí)踐[J].電腦與電信, 2017 (7) :79-81.
[2]張晶, 黃小鋒, 李春陽(yáng).微服務(wù)框架的設(shè)計(jì)與實(shí)現(xiàn)[J].計(jì)算機(jī)系統(tǒng)應(yīng)用, 2017 (6) :259-262.
[3]王紀(jì)軍, 張斌, 顧永生, 等.云環(huán)境中Web應(yīng)用的微服務(wù)架構(gòu)評(píng)估[J].計(jì)算機(jī)系統(tǒng)應(yīng)用, 2017 (5) :9-15.
[4]劉為.微服務(wù)架構(gòu)及相應(yīng)云平臺(tái)解析[J].科教導(dǎo)刊, 2017 (1) :27-28.
[5]佚名.容器+微服務(wù)成為驅(qū)動(dòng)混合IT關(guān)鍵[J].郵電設(shè)計(jì)技術(shù), 2017 (1) :5.
[6]黃小鋒, 張晶.微服務(wù)框架介紹與實(shí)現(xiàn)[J].電腦與信息技術(shù), 2016 (6) :14-16.
[7]王健, 李冬睿.從單一模式系統(tǒng)架構(gòu)往微服務(wù)架構(gòu)遷移轉(zhuǎn)化技術(shù)研究[J].科教導(dǎo)刊, 2016 (9) :43-44.
【程序開(kāi)發(fā)中微服務(wù)架構(gòu)和容器的結(jié)合運(yùn)用論文】相關(guān)文章：
微課在C 程序設(shè)計(jì)課程教學(xué)中的運(yùn)用的探究論文06-19
中windows服務(wù)終端的運(yùn)用研究論文06-17
淺析軟件開(kāi)發(fā)中的三層架構(gòu)技術(shù)論文05-21
居室空間設(shè)計(jì)中虛實(shí)結(jié)合的運(yùn)用論文04-22
居室中色彩與光影的結(jié)合運(yùn)用解讀論文05-13
化工設(shè)備開(kāi)發(fā)中RPM技術(shù)的運(yùn)用論文05-20
程序教學(xué)法在排球教學(xué)中運(yùn)用論文推薦06-05