在古代,帶兵作戰(zhàn)的將領(lǐng),不僅要能善于用兵,而且要能保障糧食的充足。正所謂兵馬未動,糧草先行。糧草永遠(yuǎn)擺在第一位,因為在冷**時代,戰(zhàn)爭中的將士都是在拼力氣,吃飽才有力氣打仗。
在今天互聯(lián)網(wǎng)的“戰(zhàn)爭”環(huán)境中,我們?yōu)榱四芨鞈?yīng)對市場變化,一直以來不斷調(diào)整作戰(zhàn)的方針和打法,也從傳統(tǒng)的開發(fā)方式轉(zhuǎn)變?yōu)榱嗣艚蓍_發(fā),由敏捷開發(fā)又過渡了到DevOps。在2019年的中國DevOps行業(yè)報告中指出:“盡管受訪企業(yè)期望 DevOps 能夠帶來更高效的交付效率,提升客戶滿意度,創(chuàng)造更多的商業(yè)價值,但成功實踐 DevOps 依然是一個難題 ?!?/p>
其中,28.22% 被調(diào)查者認(rèn)為自己組織的 DevOps 實踐是不成功的, 41.13%的被調(diào)查者不清楚如何衡量自己組織的 DevOps 實踐是否成功。如果以一個更加直觀的數(shù)據(jù)來展示,就是在接受調(diào)查的企業(yè)中有69.35%是沒有能很好的了解和實踐DevOps的。
也許,在實踐DevOps的這幾年來,并沒有多少公司是真正知道什么是DevOps的。DevOps只是從字面上理解的打破部門墻的一鍵發(fā)布的工具鏈嗎,是否有了這個工具鏈就是DevOps?答案是否定的。
那么,DevOps是什么?
DevOps 是集文化理念、實踐和工具于一身,可以提高組織高速交付應(yīng)用程序和服務(wù)的能力,與使用傳統(tǒng)軟件開發(fā)和基礎(chǔ)設(shè)施管理流程相比,能夠幫助組織更快地發(fā)展和改進(jìn)產(chǎn)品。這種速度使組織能夠更好地服務(wù)其客戶,并在市場上更高效地參與競爭。
——AWS
從AWS給出的定義來看,好像也還是比較的抽象。那如果簡單的來說,DevOps就是讓軟件過程既“快”又“穩(wěn)”。何為快和穩(wěn),這個快和穩(wěn)體現(xiàn)在,部署頻率、交付周期、平均修復(fù)時長、變更失敗比例這4個維度上。
在2018年的DevOps調(diào)查報告中基于上述4個維度,由于僅有6%達(dá)到了所規(guī)定的高性能指標(biāo),為了避免特殊原因造成數(shù)據(jù)過低,所以放寬的條件,并給出了準(zhǔn)高性能DevOps指標(biāo)。
從達(dá)成這一準(zhǔn)高性能DevOps指標(biāo)的團隊分析來看,其具體體現(xiàn)在三個方面:一方面是自動化、標(biāo)準(zhǔn)化、質(zhì)量保證、敏捷方法的實踐活動上;一方面是DevOps各個階段的對應(yīng)工具上。除此以外就是,團隊正在開發(fā)應(yīng)用的架構(gòu)上。 架構(gòu)的選擇對于DevOps的實踐是至關(guān)重要的,從某種程度上來說,架構(gòu)就是DevOps這場戰(zhàn)役的糧草,它是支撐著DevOps成功落地的重要前提。受訪的準(zhǔn)高性能DevOps指標(biāo)的團隊將“使用微服務(wù)框架”作為團隊正在開發(fā)應(yīng)用的架構(gòu)上的Top1。
什么是微服務(wù)
是一種軟件架構(gòu)風(fēng)格,它是以專注于單一責(zé)任與功能的小型功能區(qū)塊 (Small Building Blocks) 為基礎(chǔ),利用模塊化的方式組合出復(fù)雜的大型應(yīng)用程序,各功能區(qū)塊使用與語言無關(guān) (Language-Independent/Language agnostic) 的 API 集相互通信。
微服務(wù)的起源是由 Peter Rodgers 博士于 2005 年度云計算博覽會提出的微 Web 服務(wù) (Micro-Web-Service) 開始,Juval L?wy 則是與他有類似的前導(dǎo)想法,將類別變成細(xì)粒服務(wù) (granular services),以作為Microsoft下一階段的軟件架構(gòu),其核心想法是讓服務(wù)是由類似 Unix 管道的訪問方式使用,而且復(fù)雜的服務(wù)背后是使用簡單URI來開放接口,任何服務(wù),任何細(xì)粒都能被開放 (exposed)。這個設(shè)計在 HP 的實驗室被實現(xiàn),具有改變復(fù)雜軟件系統(tǒng)的強大力量。
2014年,Martin Fowler與James Lewis共同提出了微服務(wù)的概念,定義了微服務(wù)是由以單一應(yīng)用程序構(gòu)成的小服務(wù),自己擁有自己的行程與輕量化處理,服務(wù)依業(yè)務(wù)功能設(shè)計,以全自動的方式部署,與其他服務(wù)使用 HTTP API 通信。同時服務(wù)會使用最小的規(guī)模的集中管理 (例如Docker) 能力,服務(wù)可以用不同的編程語言與數(shù)據(jù)庫等組件實現(xiàn)。
微服務(wù)的特點
根據(jù)Martin Fowler的分析,微服務(wù)架構(gòu)有以下的一些通用特性,但并非所有微服務(wù)架構(gòu)應(yīng)用都必須具備所有這些特性:
1.通過服務(wù)實現(xiàn)應(yīng)用的組件化(Componentizationvia Services):微服務(wù)架構(gòu)中將組件定義為可被獨立替換和升級的軟件單元,在應(yīng)用架構(gòu)設(shè)計中通過將整體應(yīng)用切分成可獨立部署及升級的微服務(wù)方式進(jìn)行組件化設(shè)計。
2.圍繞業(yè)務(wù)能力組織服務(wù)(Organizedaround Business Capabilities):微服務(wù)架構(gòu)采取以業(yè)務(wù)能力為出發(fā)點組織服務(wù)的策略,因此微服務(wù)團隊的組織結(jié)構(gòu)必須是跨功能的(如:既管應(yīng)用,也管數(shù)據(jù)庫)、強搭配的DevOps開發(fā)運維一體化團隊,通常這些團隊不會太大(如:亞馬遜的“Two pizza team”- 不超過12人)。
3.產(chǎn)品而非項目模式(Productsnot Projects):傳統(tǒng)的應(yīng)用模式是一個團隊以項目模式開發(fā)完整的應(yīng)用,開發(fā)完成后就交付給運維團隊負(fù)責(zé)維護;微服務(wù)架構(gòu)則倡導(dǎo)一個團隊?wèi)?yīng)該如開發(fā)產(chǎn)品般負(fù)責(zé)一個“微服務(wù)”完整的生命周期,倡導(dǎo)“誰開發(fā),誰運營”的開發(fā)運維一體化方法。
4.智能端點與管道扁平化(Smartendpoints and dumb pipes):微服務(wù)架構(gòu)主張將組件間通訊的相關(guān)業(yè)務(wù)邏輯/智能放在組件端點側(cè)而非放在通訊組件中,通訊機制或組件應(yīng)該盡量簡單及松耦合。RESTful HTTP協(xié)議和僅提供消息路由功能的輕量級異步機制是微服務(wù)架構(gòu)中最常用的通訊機制。
5.“去中心化”治理(DecentralizedGovernance):整體式應(yīng)用往往傾向于采用單一技術(shù)平臺,微服務(wù)架構(gòu)則鼓勵使用合適的工具完成各自的任務(wù),每個微服務(wù)可以考慮選用最佳工具完成(如不同的編程語言)。微服務(wù)的技術(shù)標(biāo)準(zhǔn)傾向于尋找其他開發(fā)者已成功驗證解決類似問題的技術(shù)。
6.“去中心化”數(shù)據(jù)管理(DecentralizedData Management):微服務(wù)架構(gòu)倡導(dǎo)采用多樣性持久化(PolyglotPersistence)的方法,讓每個微服務(wù)管理其自有數(shù)據(jù)庫,并允許不同微服務(wù)采用不同的數(shù)據(jù)持久化技術(shù)。
7.基礎(chǔ)設(shè)施自動化(InfrastructureAutomation):云化及自動化部署等技術(shù)極大地降低了微服務(wù)構(gòu)建、部署和運維的難度,通過應(yīng)用持續(xù)集成和持續(xù)交付等方法有助于達(dá)到加速推出市場的目的。
8.故障處理設(shè)計(Designfor failure):微服務(wù)架構(gòu)所帶來的一個后果是必須考慮每個服務(wù)的失敗容錯機制。因此,微服務(wù)非常重視建立架構(gòu)及業(yè)務(wù)相關(guān)指標(biāo)的實時監(jiān)控和日志機制。
9.演進(jìn)式的設(shè)計(EvolutionaryDesign):微服務(wù)應(yīng)用更注重快速更新,因此系統(tǒng)的設(shè)計會隨時間不斷變化及演進(jìn)。微服務(wù)的設(shè)計受業(yè)務(wù)功能的生命周期等因素影響。如某應(yīng)用是整體式應(yīng)用,但逐漸朝微應(yīng)用架構(gòu)方向演進(jìn),整體式應(yīng)用仍是核心,但新功能將使用應(yīng)用所提供的API構(gòu)建。再如在某微服務(wù)應(yīng)用中,可替代性模塊化設(shè)計的基本原則,在實施后發(fā)現(xiàn)某兩個微服務(wù)經(jīng)常必須同時更新,則這很可能意味著應(yīng)將其合并為一個微服務(wù)。
微服務(wù)適用的場景
基于微服務(wù)的優(yōu)勢,我們可以看到,微服務(wù)比較實用于以下場景:
對于業(yè)務(wù)流程較為復(fù)雜,且業(yè)務(wù)會變得逐漸復(fù)雜的項目,可以考慮使用微服務(wù)架構(gòu)
項目存在多個團隊(公司)多種開發(fā)語言時
核心業(yè)務(wù)和非核心業(yè)務(wù)變得涇渭分明
需要平滑升級時(服務(wù)無中斷、客戶無感知)
想對系統(tǒng)進(jìn)行細(xì)粒度監(jiān)控時 (bug調(diào)查困難或性能等問題)
既然微服務(wù)有其使用的場景,那么也一定有其優(yōu)缺點。
既然微服務(wù)有其使用的場景,那么也一定有其優(yōu)缺點。
微服務(wù)的優(yōu)勢
微服務(wù)的誕生正是在互聯(lián)網(wǎng)高速發(fā)展,技術(shù)日新月異變化以及傳統(tǒng)架構(gòu)無法適應(yīng)快速變化等多種因素共同推動下的必然產(chǎn)物。從一個網(wǎng)站的演變可以看到使用微服務(wù)后帶來了很多優(yōu)點,總結(jié)如下:
邏輯清晰:
這個特點是由微服務(wù)的單一職責(zé)的要求所帶來的。邏輯清晰帶來的是微服務(wù)的可維護性,在我們對一個微服務(wù)進(jìn)行修改時,能夠更容易分析到這個修改到底會產(chǎn)生什么影響,從而通過完備的測試保證修改質(zhì)量。
簡化部署:
微服務(wù)則可以只對一個微服務(wù)單獨進(jìn)行部署,不影響其他功能的同時,在效率上也得到了提升,從而快速的發(fā)布新的功能。
可擴展性強:
在分布式系統(tǒng)中,采用微服務(wù)的系統(tǒng)相對單塊系統(tǒng)具備更好的可擴展性。 靈活組合減少浪費:在微服務(wù)架構(gòu)中,可以通過組合已有的微服務(wù)以達(dá)到功能重用的目的,減少了重復(fù)浪費。
技術(shù)異構(gòu):
微服務(wù)間松耦合,不同的微服務(wù)可以選擇不同的技術(shù)棧進(jìn)行開發(fā)。
微服務(wù)的缺點
以往單體應(yīng)用,排查問題通常是看一下日志,研究錯誤信息和調(diào)用堆棧。而微服務(wù)架構(gòu)整個應(yīng)用分散成多個服務(wù),定位故障點非常困難。在微服務(wù)架構(gòu)中,一個服務(wù)故障可能會產(chǎn)生雪崩效用,導(dǎo)致整個系統(tǒng)故障。微服務(wù)架構(gòu)雖然邏輯設(shè)計上看是完美的,但就像積木搭建的華麗宮殿一樣,經(jīng)不起風(fēng)吹草動。
微服務(wù)架構(gòu)雖然解決了舊問題,也引入了新的問題:提高了系統(tǒng)的復(fù)雜度,此外還有:
服務(wù)的注冊與發(fā)現(xiàn)問題;
服務(wù)之間的分布式事務(wù)問題;
數(shù)據(jù)隔離再來的報表處理問題;
服務(wù)之間的分布式一致性問題;
服務(wù)管理的復(fù)雜性,服務(wù)的編排;
不同服務(wù)實例的管理。
微服務(wù)在使用上是一把“雙刃劍”,這就像糧草如果在搬運的過程中被敵方奪取,那可能會是毀滅性的。所以DevOps團隊在微服務(wù)的架構(gòu)上需要非常的重視,一個成熟度高的微服務(wù)框架才是實現(xiàn)其DevOps的重要前提,反之亦然。
責(zé)任編輯:lq
-
模塊化
+關(guān)注
關(guān)注
0文章
326瀏覽量
21305 -
應(yīng)用程序
+關(guān)注
關(guān)注
37文章
3226瀏覽量
57508 -
devops
+關(guān)注
關(guān)注
0文章
108瀏覽量
11980
原文標(biāo)題:沒有它你的DevOps是玩不轉(zhuǎn)的,你信不信?
文章出處:【微信號:Huawei_Developer,微信公眾號:華為開發(fā)者社區(qū)】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。
發(fā)布評論請先 登錄
相關(guān)推薦
評論