單體架構(gòu)

單體架構(gòu)是什么

在搞懂DevOps和微服務(wù)之前，需要先搞懂什么是單體應(yīng)用/單體架構(gòu)。簡(jiǎn)單來(lái)說(shuō)，就跟在校的一些小項(xiàng)目一樣，項(xiàng)目的Demo寫好了，找一臺(tái)服務(wù)器安裝環(huán)境，然后把jar包遠(yuǎn)程上服務(wù)器，然后跑起來(lái)服務(wù)就可以了。這個(gè)時(shí)候進(jìn)行簡(jiǎn)單的服務(wù)監(jiān)控也不難，如果項(xiàng)目出了問(wèn)題，查看一下運(yùn)行日志，就可以知道哪一步出問(wèn)題了。如果懂一些腳本，也可以寫一些腳本分析日志，解放雙手監(jiān)控服務(wù)器。這種單體架構(gòu)就是采用瀑布流方式開(kāi)發(fā)的，服務(wù)的流程就是：設(shè)計(jì) -> 開(kāi)發(fā) -> 測(cè)試 -> 部署 。

單體B/S架構(gòu)

在還沒(méi)有微服務(wù)和DevOps之前，一個(gè)Web應(yīng)用的上線，一般都是將所有的功能都打包在一起，也就是都在一個(gè)項(xiàng)目包里面，然后將項(xiàng)目打包到一個(gè)服務(wù)器上跑起來(lái)就可以了，那個(gè)時(shí)候的B/S應(yīng)用架構(gòu)就是單體架構(gòu)，結(jié)構(gòu)圖如下：

單體B/S+負(fù)載均衡

如果當(dāng)用戶訪問(wèn)量變大導(dǎo)致一臺(tái)服務(wù)器無(wú)法支撐時(shí)，就需要加服務(wù)器進(jìn)行負(fù)載均衡，這個(gè)時(shí)候架構(gòu)的形式就是：?jiǎn)误wB/S+負(fù)載均衡

單體B/S+前后端分離(CDN)

用了一段時(shí)間負(fù)載均衡之后，發(fā)現(xiàn)通過(guò)CDN手段，把靜態(tài)文件獨(dú)立，可以加速服務(wù)，提升應(yīng)用速度，所以單體架構(gòu)就進(jìn)一步演變成了：B/S+前后端分離(CDN)

單體架構(gòu)總結(jié)

上面所說(shuō)的架構(gòu)都是單體應(yīng)用，只是某方面的部署形式進(jìn)行了優(yōu)化與改動(dòng)，所以最終都避免不了單體應(yīng)用的普遍缺陷：

單體

1、代碼量大，應(yīng)用啟動(dòng)時(shí)間較長(zhǎng)。
2、測(cè)試周期長(zhǎng)，更改Bug需要對(duì)全部業(yè)務(wù)進(jìn)行回歸測(cè)試。
3、應(yīng)用容錯(cuò)性差，當(dāng)某個(gè)程序出錯(cuò)后，導(dǎo)致整個(gè)項(xiàng)目業(yè)務(wù)宕機(jī)。
4、伸縮性困難，只能整個(gè)應(yīng)用進(jìn)行擴(kuò)展，浪費(fèi)資源。
5、開(kāi)發(fā)協(xié)作性困難，項(xiàng)目人員都在維護(hù)一套代碼，協(xié)作周期長(zhǎng)、難度大。

DevOps

DevOps是什么

DevOps：Development和Operations的組合詞，是一種重視“軟件開(kāi)發(fā)人員（Dev）”和“IT運(yùn)維技術(shù)人員（Ops）”之間溝通合作的文化、運(yùn)動(dòng)或慣例。透過(guò)自動(dòng)化“軟件交付”和“架構(gòu)變更”的流程，來(lái)使得構(gòu)建、測(cè)試、發(fā)布軟件能夠更加地快捷、頻繁和可靠。

分布式架構(gòu)+敏捷開(kāi)發(fā)模式

隨著上述說(shuō)的單體架構(gòu)時(shí)，業(yè)務(wù)流量越來(lái)越大，那么肯定幾臺(tái)服務(wù)器是不夠用的，這個(gè)時(shí)候就會(huì)加很多服務(wù)器機(jī)器，也會(huì)加入Nignx、CDN、緩存、消息隊(duì)列等技術(shù)棧，同時(shí)開(kāi)發(fā)人員也會(huì)變多，這個(gè)時(shí)候就是 多人多機(jī)協(xié)同開(kāi)發(fā)問(wèn)題。

多人協(xié)同開(kāi)發(fā)的問(wèn)題

這個(gè)時(shí)候，大多會(huì)將項(xiàng)目進(jìn)行拆分，每個(gè)人負(fù)責(zé)專注于開(kāi)發(fā)一部分業(yè)務(wù)，敏捷開(kāi)發(fā)的核心理念就是既然無(wú)法充分了解超高業(yè)務(wù)流量下的用戶的真實(shí)需求是怎樣的，就將一個(gè)大的目標(biāo)不斷拆解，把它變成一個(gè)個(gè)可交付的小目標(biāo)、小項(xiàng)目，然后通過(guò)不斷迭代，以小步快跑的方式持續(xù)開(kāi)發(fā)
。

此外，這個(gè)時(shí)候項(xiàng)目是非常大的，為保證項(xiàng)目質(zhì)量，測(cè)試環(huán)節(jié)不可減少，為了加快速度增大開(kāi)發(fā)效率，測(cè)試的工作最好是和開(kāi)發(fā)同步交替進(jìn)行的，需要將測(cè)試環(huán)節(jié)從后面注入到整個(gè)開(kāi)發(fā)環(huán)節(jié)當(dāng)中，每次可交付的都是一個(gè)可用的功能集合，對(duì)開(kāi)發(fā)交付的內(nèi)容進(jìn)行持續(xù)驗(yàn)證。這樣開(kāi)發(fā)產(chǎn)品的可控性也更強(qiáng)，可以階段性的檢驗(yàn)一下項(xiàng)目成果。

多機(jī)器問(wèn)題

之前機(jī)器很少架構(gòu)簡(jiǎn)單的時(shí)候，開(kāi)發(fā)就可以干運(yùn)維的活，就算加了幾臺(tái)服務(wù)器，那也是腳本將 jar包 發(fā)布到這些機(jī)器上，好像也挺簡(jiǎn)單，但是會(huì)有兩個(gè)人同時(shí)上線部署被覆蓋的問(wèn)題，但這些都不是問(wèn)題，只要約定好錯(cuò)開(kāi)時(shí)間進(jìn)行上線部署就可以了。

但你如果是幾千臺(tái)服務(wù)器起步，那就需要專門的運(yùn)維人員進(jìn)行維護(hù)項(xiàng)目了，因?yàn)殚_(kāi)發(fā)分工每個(gè)人都專注于自己的事情，不會(huì)那么用心進(jìn)行維護(hù)，另一方面是運(yùn)維的學(xué)習(xí)成本確實(shí)變高了，開(kāi)發(fā)人質(zhì)量參差不齊，如果服務(wù)器出問(wèn)題那就不是小事。

但是這個(gè)時(shí)候也不是 DevOps，而是 Dev+Ops，還沒(méi)有融合在一起。這時(shí) Ops 的主要職責(zé)就是：硬件維護(hù)、網(wǎng)絡(luò)設(shè)備維護(hù)、DBA 、基礎(chǔ)服務(wù)維護(hù)、數(shù)據(jù)監(jiān)控等，運(yùn)維們擅長(zhǎng)寫各種部署，監(jiān)控腳本，減少機(jī)械的重復(fù)工作，開(kāi)發(fā)模式變成了敏捷開(kāi)發(fā)模式。

這個(gè)時(shí)候，開(kāi)發(fā)設(shè)計(jì)流程大致是這樣。

到這里了，還沒(méi)有引入到DevOps，還要先再插入講講微服務(wù)，才能更好的說(shuō)明DevOps到底怎么理解。

微服務(wù)

微服務(wù)是什么

微服務(wù)（Microservices）是一種軟件架構(gòu)，它是以專注于單一責(zé)任與功能的小型功能區(qū)塊 (Small Building Blocks) 為基礎(chǔ)，利用模塊化的方式組合出復(fù)雜的大型應(yīng)用程序，各功能區(qū)塊使用與語(yǔ)言無(wú)關(guān) (Language-Independent/Language agnostic）的API集相互通信。

微服務(wù)的出現(xiàn)就是因?yàn)樵瓉?lái)單體應(yīng)用架構(gòu)已經(jīng)無(wú)法滿足當(dāng)前互聯(lián)網(wǎng)產(chǎn)品的技術(shù)需求。

那么，到底什么樣的服務(wù)才能算是微服務(wù)？
1、單一職責(zé)的。一個(gè)微服務(wù)應(yīng)該都是單一職責(zé)的，這才是“微”的體現(xiàn)，一個(gè)微服務(wù)解決一個(gè)業(yè)務(wù)問(wèn)題（注意是一個(gè)業(yè)務(wù)問(wèn)題而不是一個(gè)接口）。
2、面向服務(wù)的。將自己的業(yè)務(wù)能力封裝并對(duì)外提供服務(wù)，這是繼承SOA的核心思想，一個(gè)微服務(wù)本身也可能使用到其它微服務(wù)的能力。
（有點(diǎn)像SOA的演進(jìn)）

微服務(wù)架構(gòu)

微服務(wù)架構(gòu)，核心是為了解決應(yīng)用微服務(wù)化之后的服務(wù)治理問(wèn)題。

應(yīng)用微服務(wù)化之后，首先遇到的第一個(gè)問(wèn)題就是服務(wù)發(fā)現(xiàn)問(wèn)題，一個(gè)微服務(wù)如何發(fā)現(xiàn)其他微服務(wù)呢？最簡(jiǎn)單的方式就是每個(gè)微服務(wù)里面配置其他微服務(wù)的地址，但是當(dāng)微服務(wù)數(shù)量眾多的時(shí)候，這樣做明顯不現(xiàn)實(shí)。所以需要使用到微服務(wù)架構(gòu)中的一個(gè)最重要的組件：服務(wù)注冊(cè)中心，所有服務(wù)都注冊(cè)到服務(wù)注冊(cè)中心，同時(shí)也可以從服務(wù)注冊(cè)中心獲取當(dāng)前可用的服務(wù)清單：

解決服務(wù)發(fā)現(xiàn)問(wèn)題后，接著需要解決微服務(wù)分布式部署帶來(lái)的第二個(gè)問(wèn)題：服務(wù)配置管理的問(wèn)題。當(dāng)服務(wù)數(shù)量超過(guò)一定程度之后，如果需要在每個(gè)服務(wù)里面分別維護(hù)每一個(gè)服務(wù)的配置文件，運(yùn)維人員估計(jì)要哭了。那么，就需要用到微服務(wù)架構(gòu)里面第二個(gè)重要的組件：配置中心，微服務(wù)架構(gòu)就變成下面這樣了：

以上應(yīng)用內(nèi)部的服務(wù)治理，當(dāng)客戶端或外部應(yīng)用調(diào)用服務(wù)的時(shí)候怎么處理呢？服務(wù)A可能有多個(gè)節(jié)點(diǎn)，服務(wù)A、服務(wù)B和服務(wù)C的服務(wù)地址都不同，服務(wù)授權(quán)驗(yàn)證在哪里做？這時(shí)，就需要使用到服務(wù)網(wǎng)關(guān)提供統(tǒng)一的服務(wù)入口，最終形成典型微服務(wù)架構(gòu)：

上面是一個(gè)典型的微服務(wù)架構(gòu)，當(dāng)然微服務(wù)的服務(wù)治理還涉及很多內(nèi)容，比如：

1、通過(guò)熔斷、限流等機(jī)制保證高可用；
2、微服務(wù)之間調(diào)用的負(fù)載均衡；
3、分布式事務(wù)（2PC、3PC、TCC、LCN等）；
4、服務(wù)調(diào)用鏈跟蹤等等。

主流的微服務(wù)框架

目前國(guó)內(nèi)企業(yè)使用的微服務(wù)框架主要是Spring Cloud和Dubbo（或者DubboX），Spring Cloud已經(jīng)逐漸成為主流，比較兩個(gè)框架的優(yōu)劣勢(shì)的文章在網(wǎng)上有很多，這里就不重復(fù)了，選擇什么框架還是按業(yè)務(wù)需求來(lái)吧，業(yè)務(wù)框架決定技術(shù)框架。

Spring Cloud全家桶提供了各種各樣的組件，基本可以覆蓋微服務(wù)的服務(wù)治理的方方面面，以下列出了Spring Cloud一些常用組件：

DevOps+微服務(wù)：拆分解耦

了解完上述全部之后，假設(shè)當(dāng)原本是單體架構(gòu)的公司發(fā)展到非常大規(guī)模的時(shí)候，會(huì)有很多程序員、服務(wù)器等等，所以一個(gè)項(xiàng)目里面，什么語(yǔ)言、技術(shù)棧都會(huì)有，Java、Go、Python肯定是數(shù)不勝數(shù)的，所以，這個(gè)時(shí)候需要協(xié)調(diào)技術(shù)棧，并且項(xiàng)目后期肯定會(huì)變得非常大，全部都兌到一個(gè)項(xiàng)目里，最直接的后果就是項(xiàng)目變得很大，上線項(xiàng)目啟動(dòng)時(shí)間變長(zhǎng)，一個(gè)BUG可能導(dǎo)致整個(gè)業(yè)務(wù)全線崩潰，最終的后果就是項(xiàng)目變得越來(lái)越難以維護(hù)，加一個(gè)改一個(gè)東西幾乎搞不動(dòng)，而且還越來(lái)越難重構(gòu)。

所以，拆分解耦是最終的出路，將項(xiàng)目拆成一個(gè)個(gè)小的服務(wù)單獨(dú)部署，以電商項(xiàng)目為例，將整個(gè)項(xiàng)目拆分為用戶服務(wù)、商品服務(wù)、訂單服務(wù)，積分服務(wù)、支付服務(wù)每個(gè)服務(wù)單獨(dú)部署，之間通過(guò)互相調(diào)用的方式來(lái)交互，而且可以將一些基礎(chǔ)服務(wù)例如上傳圖片，發(fā)送短信等很多服務(wù)都需要的基礎(chǔ)服務(wù)，抽象到一個(gè)單獨(dú)的整合服務(wù)，也就是之前所謂的中臺(tái)服務(wù)。

拆分解耦演化催生DevOps

按照上述說(shuō)的微服務(wù)架構(gòu)進(jìn)行開(kāi)發(fā)DevOps的話，運(yùn)維需要做的上線工作，主要就是將代碼部署到對(duì)應(yīng)的機(jī)器里面，微服務(wù)有那么多的服務(wù)，每個(gè)大點(diǎn)的公司幾百個(gè)服務(wù)不算多，而且還可能隨時(shí)搞一個(gè)服務(wù)出來(lái)，如果還按照原始的腳本部署方式，可能最后連是哪個(gè)腳本都找不到。而且，如果每個(gè)服務(wù)上線都需要運(yùn)維來(lái)同意，開(kāi)發(fā)會(huì)非常難受，需要天天找運(yùn)維同意發(fā)布，運(yùn)維也會(huì)增加繁瑣的工作量。

所以，開(kāi)始演化出遠(yuǎn)程部署一些機(jī)器，專門用來(lái)管理代碼，進(jìn)行上線工作，由運(yùn)維事先把上線的規(guī)則都給定義好了，開(kāi)發(fā)只要按照他的規(guī)則都訪問(wèn)這臺(tái)服務(wù)器進(jìn)行各自的代碼合成和發(fā)布，自己上線呢，能用代碼自動(dòng)完成的事情就絕不要手動(dòng)解決，這是每個(gè)開(kāi)發(fā)人員都在想的東西。運(yùn)維需要做的事情，慢慢的都沉淀到了各個(gè)平臺(tái)上面，例如監(jiān)控，有專門的監(jiān)控組件和可視化，基礎(chǔ)服務(wù)例如服務(wù)器，CDN，負(fù)載均衡等基礎(chǔ)服務(wù)可以外包到云服務(wù)廠商，日志也有專門的日志工具，鏈路追蹤也有專門的組件和可視化，還有網(wǎng)關(guān)等，漸漸的，只要這些都配置好了，開(kāi)發(fā)也可以做運(yùn)維的部分工作，畢竟開(kāi)發(fā)才是最了解代碼的人，哪里出了問(wèn)題看看監(jiān)控日志，可以最快速度定位到問(wèn)題，于是DevOps開(kāi)發(fā)模式誕生了，開(kāi)發(fā)也是運(yùn)維。

早期的DevOps，大部分指的都是“開(kāi)發(fā)運(yùn)維一體化”。

而現(xiàn)在的DevOps，概念上已經(jīng)擴(kuò)大到端到端的概念了。

實(shí)現(xiàn)DevOps：DevOps搭建工具

綜上所示：DevOps 的三大支柱之中，即人（People）、流程（Process）和平臺(tái)（Platform）。

項(xiàng)目管理（PM）：Jira。運(yùn)營(yíng)可以上去提問(wèn)題，可以看到各個(gè)問(wèn)題的完整的工作流，待解決未解決等；
代碼管理：Gitlab。jenkins或者K8S都可以集成gitlab，進(jìn)行代碼管理，上線，回滾等；
持續(xù)集成CI（Continuous Integration）：gitlab ci。開(kāi)發(fā)人員提交了新代碼之后，立刻進(jìn)行構(gòu)建、（單元）測(cè)試。根據(jù)測(cè)試結(jié)果，我們可以確定新代碼和原有代碼能否正確地集成在一起。
持續(xù)交付CD（Continuous Delivery）：gitlab cd。完成單元測(cè)試后，可以把代碼部署到連接數(shù)據(jù)庫(kù)的 Staging 環(huán)境中更多的測(cè)試。如果代碼沒(méi)有問(wèn)題，可以繼續(xù)手動(dòng)部署到生產(chǎn)環(huán)境中。
鏡像倉(cāng)庫(kù)：VMware Harbor，私服nexus。
容器：Docker。
編排：K8S。
服務(wù)治理：Consul。
腳本語(yǔ)言：Python。
日志管理：Cat+Sentry，還有種常用的是ELK。
系統(tǒng)監(jiān)控：Prometheus。
負(fù)載均衡：Nginx。
網(wǎng)關(guān)：Kong，zuul。
鏈路追蹤：Zipkin。
產(chǎn)品和UI圖：藍(lán)湖。

參考文章：
1、知乎：什么是DevOps？ 作者：小龍飛
2、知乎：微服務(wù)入門 作者：未知

到此這篇關(guān)于深入理解DevOps+微服務(wù)的文章就介紹到這了,更多相關(guān)DevOps 微服務(wù)內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論