單體架構(gòu)

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

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

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

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

單體B/S+負載均衡

如果當用戶訪問量變大導致一臺服務器無法支撐時，就需要加服務器進行負載均衡，這個時候架構(gòu)的形式就是：單體B/S+負載均衡

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

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

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

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

單體

1、代碼量大，應用啟動時間較長。
2、測試周期長，更改Bug需要對全部業(yè)務進行回歸測試。
3、應用容錯性差，當某個程序出錯后，導致整個項目業(yè)務宕機。
4、伸縮性困難，只能整個應用進行擴展，浪費資源。
5、開發(fā)協(xié)作性困難，項目人員都在維護一套代碼，協(xié)作周期長、難度大。

DevOps

DevOps是什么

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

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

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

多人協(xié)同開發(fā)的問題

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

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

多機器問題

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

但你如果是幾千臺服務器起步，那就需要專門的運維人員進行維護項目了，因為開發(fā)分工每個人都專注于自己的事情，不會那么用心進行維護，另一方面是運維的學習成本確實變高了，開發(fā)人質(zhì)量參差不齊，如果服務器出問題那就不是小事。

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

這個時候，開發(fā)設計流程大致是這樣。

到這里了，還沒有引入到DevOps，還要先再插入講講微服務，才能更好的說明DevOps到底怎么理解。

微服務

微服務是什么

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

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

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

微服務架構(gòu)

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

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

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

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

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

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

主流的微服務框架

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

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

DevOps+微服務：拆分解耦

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

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

拆分解耦演化催生DevOps

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

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

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

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

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

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

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

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

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

最新評論