微服務(wù)轉(zhuǎn)型與DevOps
分享人：鄭云龍 睿云智合持續(xù)交付產(chǎn)品負(fù)責(zé)人，在敏捷和DevOps領(lǐng)域有豐富經(jīng)驗(yàn)的實(shí)踐，過(guò)去作為敏捷和DevOps技術(shù)教練向多家大型企業(yè)提供咨詢(xún)和培訓(xùn)服務(wù)。 微服務(wù)轉(zhuǎn)型與DevOps 1 遺留的現(xiàn)狀 在開(kāi)始微服務(wù)和DevOps主題之前，首先看看在過(guò)去我的咨詢(xún)工作中，對(duì)于大部分咨詢(xún)客戶(hù)而言，企業(yè)會(huì)邀請(qǐng)外部的顧問(wèn)來(lái)對(duì)團(tuán)隊(duì)進(jìn)行改進(jìn)，最主要的原因都是由于現(xiàn)有的研發(fā)體系和產(chǎn)品團(tuán)隊(duì)，難以跟上市場(chǎng)的變化，希望通過(guò)外部顧問(wèn)，通過(guò)一些手段來(lái)提高產(chǎn)品團(tuán)隊(duì)的響應(yīng)力。敏捷實(shí)踐亦或是DevOps實(shí)踐最終的目的都是為了能夠快速的交付高質(zhì)量的軟件產(chǎn)品。 究其原因，為什么這類(lèi)客戶(hù)會(huì)有如此大的需求去引入敏捷或者DevOps呢？遺留系統(tǒng)。 歷史遺留問(wèn)題與新問(wèn)題，新需求的持續(xù)混合發(fā)酵，導(dǎo)致系統(tǒng)的開(kāi)發(fā)效率無(wú)法滿(mǎn)足業(yè)務(wù)的發(fā)展需求。所以經(jīng)常會(huì)有如上圖這種對(duì)話(huà)。無(wú)論是新的需求，還是遺留的Bug都嚴(yán)重受制于遺留系統(tǒng) 如果從技術(shù)角度來(lái)看，對(duì)于遺留系統(tǒng)最主要的問(wèn)題包括：高耦合性，底可測(cè)試行，代碼質(zhì)量差，圈復(fù)雜度高，并且很難對(duì)系統(tǒng)進(jìn)行優(yōu)化。而這些東西我們都可以稱(chēng)之為技術(shù)債。 而這些技術(shù)債務(wù)的積累最終導(dǎo)致我們的系統(tǒng)越來(lái)越難以維護(hù)。舉個(gè)例子，在之前對(duì)客戶(hù)團(tuán)隊(duì)進(jìn)行敏捷技術(shù)培訓(xùn)時(shí)，嘗試在項(xiàng)目中使用TDD，最終的結(jié)果是在使用TDD的同時(shí)，我們進(jìn)行了大量的重構(gòu)，才能保證我們能夠順利的給某一個(gè)業(yè)務(wù)場(chǎng)景添加上相應(yīng)的測(cè)試代碼。 而技術(shù)債不是一開(kāi)始就有的東西，對(duì)于傳統(tǒng)單體架構(gòu)而言，在項(xiàng)目初期系統(tǒng)通常也是易于開(kāi)發(fā)，易于部署，易于測(cè)試的。 隨著時(shí)間和項(xiàng)目演進(jìn)，系統(tǒng)的代碼量以及復(fù)雜度呈指數(shù)型增長(zhǎng)，最終導(dǎo)致我們整個(gè)項(xiàng)目的交付周期越來(lái)越長(zhǎng)，同時(shí)系統(tǒng)很難進(jìn)行擴(kuò)展，并且當(dāng)擴(kuò)展時(shí)所需要的成本也越來(lái)越高。 對(duì)于新加入團(tuán)隊(duì)的成員，也需要花費(fèi)大量的時(shí)間了解業(yè)務(wù)背景，熟悉應(yīng)用程序的業(yè)務(wù)，配置本地開(kāi)發(fā)環(huán)境等等。這些看似簡(jiǎn)單的任務(wù)，往往需要花費(fèi)大量的時(shí)間。 同時(shí)對(duì)于傳統(tǒng)單體架構(gòu)隨著時(shí)間和項(xiàng)目的演進(jìn)，嘗試引入新技術(shù)或者對(duì)現(xiàn)有技術(shù)框架進(jìn)行改進(jìn)的成本和風(fēng)險(xiǎn)也越來(lái)越高。 而對(duì)于傳統(tǒng)的SOA架構(gòu)？ 如果用直白一點(diǎn)的話(huà)來(lái)說(shuō)，就是專(zhuān)注于使用ESB來(lái)集成企業(yè)內(nèi)的各個(gè)單體應(yīng)用。而往往導(dǎo)致的結(jié)果是兩個(gè)大的中心化，技術(shù)的中心化，以及流程的中心化。 由于EBS通?；谔囟ǖ募夹g(shù)棧，并且使用了中心化的標(biāo)準(zhǔn)個(gè)規(guī)范，使得業(yè)務(wù)難以根據(jù)業(yè)務(wù)場(chǎng)景去選擇合適的技術(shù)。 而ESB也往往嵌入了大量的業(yè)務(wù)流程，所以導(dǎo)致任何服務(wù)的修改都需要進(jìn)過(guò)復(fù)雜的流程，修改系統(tǒng)的工作量不減反增，維護(hù)成本和產(chǎn)品成本也呈非線(xiàn)性增長(zhǎng)。 2 什么是微服務(wù)架構(gòu) 通常而言我們對(duì)于微服務(wù)并沒(méi)有一個(gè)準(zhǔn)確的定義，但是我們可以認(rèn)為，微服務(wù)就是我們?nèi)ヒ哉_的姿勢(shì)去實(shí)現(xiàn)SOA。 對(duì)于微服務(wù)通常具有以下特性：獨(dú)立進(jìn)程，獨(dú)立部署，獨(dú)立技術(shù)以及獨(dú)立團(tuán)隊(duì)。 對(duì)于每一個(gè)服務(wù)而言都是以開(kāi)發(fā)一個(gè)小的獨(dú)立的應(yīng)用系統(tǒng)，并且每個(gè)服務(wù)都是運(yùn)行在自己的進(jìn)程中；這些服務(wù)圍繞業(yè)務(wù)功能進(jìn)行構(gòu)建，并且能夠獨(dú)立的部署和發(fā)布；同時(shí)服務(wù)與服務(wù)之間可以使用不同的技術(shù)語(yǔ)言以及存儲(chǔ)技術(shù)；而對(duì)于每一個(gè)微服務(wù)都是由一個(gè)充分獨(dú)立自治的團(tuán)隊(duì)進(jìn)行端到端的管理，從開(kāi)發(fā)，構(gòu)建，部署，上線(xiàn)運(yùn)維。并且這些服務(wù)之間通常采用一些輕量級(jí)的通訊接口包括像Rest API以及消息隊(duì)列 而對(duì)于每一個(gè)微服務(wù)而言我們都可以根據(jù)其不同的業(yè)務(wù)場(chǎng)景去選擇適合的技術(shù)，并且這些服務(wù)之間可以有不同的發(fā)布節(jié)奏 除了技術(shù)上的去中心化，在團(tuán)隊(duì)組織結(jié)構(gòu)上，每一個(gè)微服務(wù)團(tuán)隊(duì)都應(yīng)該具有和當(dāng)前業(yè)務(wù)功能開(kāi)發(fā)所需的全方位技術(shù)，及所謂的全功能團(tuán)隊(duì)。這些團(tuán)隊(duì)圍繞著各自的業(yè)務(wù)管理相關(guān)的服務(wù)。相比于傳統(tǒng)的通過(guò)組件的方式拆分團(tuán)隊(duì)，微服務(wù)團(tuán)隊(duì)可以端到端的完成特性交付，減少由于將特性分配給多個(gè)團(tuán)隊(duì)而導(dǎo)致的溝通問(wèn)題，系統(tǒng)集成問(wèn)題，能夠更加快速的交付所需的特性，減少等待時(shí)間。 同時(shí)微服務(wù)架構(gòu)能夠幫助我們快速的開(kāi)辟新的渠道，助力企快速獲取市場(chǎng)機(jī)會(huì)。 剛才談了很多關(guān)于微服務(wù)本身的特性，以及能夠?yàn)槲覀儙?lái)的好處。但是事無(wú)好壞，對(duì)于任何一家公司和組織，在轉(zhuǎn)向微服務(wù)之前都應(yīng)該明白它為我們帶來(lái)的潛在的挑戰(zhàn)。 微服務(wù)化帶來(lái)的挑戰(zhàn)？ 運(yùn)維的挑戰(zhàn)?、質(zhì)量保證體系、分布式系統(tǒng)的復(fù)雜度 首先我們來(lái)說(shuō)關(guān)于質(zhì)量的部分 對(duì)于任何傳統(tǒng)意義上的測(cè)試保障體系，我們通常會(huì)通過(guò)單元測(cè)試，API測(cè)試，系統(tǒng)集成測(cè)試，以及其他的非功能性測(cè)試，諸如性能測(cè)試，安全測(cè)試等來(lái)保證我們軟件交付的質(zhì)量。在敏捷測(cè)試實(shí)踐中我們通常以測(cè)試金字塔的方式來(lái)評(píng)估我們現(xiàn)有系統(tǒng)的自動(dòng)化測(cè)試水平以及合理性。 那在微服務(wù)中呢？剛才我們已經(jīng)說(shuō)過(guò)，微服務(wù)是一組獨(dú)立的去中心化得服務(wù)，服務(wù)和服務(wù)之間必然存在相應(yīng)的依賴(lài)關(guān)系。 在這里我們仿照敏捷測(cè)試金字塔的方式將微服務(wù)的質(zhì)量保證體系劃分為3層:服務(wù)內(nèi)，服務(wù)間，以及服務(wù)集成。 相比與過(guò)去的軟件質(zhì)量保證體系，我們?cè)黾恿似跫s測(cè)試來(lái)保證服務(wù)和服務(wù)之間的依賴(lài)，確保各個(gè)服務(wù)是能夠獨(dú)立的進(jìn)行演進(jìn)升級(jí)的。對(duì)于契約測(cè)試目前包括像Thoughtworks開(kāi)源的契約測(cè)試工具Pact以及Swagger這樣的工具都能夠幫助我們將契約測(cè)試添加到我們的質(zhì)量保證體系中。 當(dāng)然對(duì)于所有的自動(dòng)化的質(zhì)量保證過(guò)程，我們都應(yīng)該將他們納入到CI流水線(xiàn)中，通過(guò)自動(dòng)化的方式來(lái)保證我們每一次代碼變更都是能夠滿(mǎn)足質(zhì)量要求的。 那對(duì)于運(yùn)維體系而言呢？ 運(yùn)維體系面臨的挑戰(zhàn) 1，部署環(huán)境的多樣性，對(duì)于傳統(tǒng)團(tuán)隊(duì)的Ops人員，他通常都是接觸一些固定的技術(shù)棧相關(guān)的運(yùn)維和管理工作，但是在服務(wù)下，每一個(gè)服務(wù)都都可能采用不同的技術(shù)，數(shù)據(jù)庫(kù)，以及中間件。那對(duì)于Ops人員而言所需要面臨管理和運(yùn)維的環(huán)境的復(fù)雜度和難度也隨著服務(wù)化得進(jìn)程變得越來(lái)越困難 2，對(duì)于公司而言從開(kāi)發(fā)，測(cè)試到部署上線(xiàn)，我們通常需要使用大量的服務(wù)器資源來(lái)保證我們各個(gè)環(huán)節(jié)的部署環(huán)境需求。舉例來(lái)講，在敏捷當(dāng)中我們通常會(huì)有Dev環(huán)境，UAT環(huán)境，Prod環(huán)境去提供軟件交付過(guò)程中各個(gè)階段的部署需求。但是微服務(wù)之后我們可能有幾個(gè)，幾十個(gè)甚至幾百個(gè)不同的服務(wù)，而這些服務(wù)都需要相應(yīng)的部署資源，同時(shí)如何保證各個(gè)階段的環(huán)境一致性問(wèn)題 3，CI維護(hù)成本暴增，在過(guò)去我們通常會(huì)花費(fèi)通常一個(gè)迭代的時(shí)間來(lái)搭建我們項(xiàng)目的CI基礎(chǔ)設(shè)施，但是現(xiàn)在隨著服務(wù)數(shù)量的增加我們管理和配置Jenkins的成本也越來(lái)越大 4，除此之外包括，日志，監(jiān)控，彈性，高可用都是我們?cè)谖⒎?wù)轉(zhuǎn)型過(guò)程需要面臨的挑戰(zhàn)。 如何解決 充分授權(quán)團(tuán)隊(duì) 在微服務(wù)下我們希望每一個(gè)團(tuán)隊(duì)都是能夠充分獨(dú)立和自治的。但是往往對(duì)于企業(yè)而言對(duì)于基礎(chǔ)設(shè)施環(huán)境的管控要求其實(shí)非常高，包括像網(wǎng)絡(luò)，安全等等。 所以往往對(duì)于一個(gè)團(tuán)隊(duì)想要獲取一個(gè)服務(wù)器資源通常需要復(fù)雜的審批以及配置過(guò)程。 而通過(guò)引入像Rancher這樣的輕量級(jí)的容器化管理平臺(tái)，我們可以將底層基礎(chǔ)設(shè)施的管理問(wèn)題交給專(zhuān)門(mén)的運(yùn)維團(tuán)隊(duì)來(lái)進(jìn)行處理。這些基礎(chǔ)設(shè)施可以是物理機(jī)，IaaS，甚至是容器集群。并且將這些資源按照環(huán)境的形式分配給不同的團(tuán)隊(duì)，充分授權(quán)團(tuán)隊(duì)，管理自己的所有的開(kāi)發(fā)，構(gòu)建與部署環(huán)節(jié)。 基礎(chǔ)設(shè)施代碼 而對(duì)于持續(xù)集成流水線(xiàn)，以及持續(xù)交付流水線(xiàn)的管理和配置，Jenkins2.0通過(guò)Pipeline As Code的方式通過(guò)編寫(xiě)DSL來(lái)幫助我們實(shí)現(xiàn)全面的基礎(chǔ)設(shè)施及代碼的要求。 在代碼庫(kù)當(dāng)中及包含源代碼src，也包含我們的環(huán)境準(zhǔn)備過(guò)程Dockerfile以及環(huán)境定義docker-compose.yml. rancher-compose.yml. 同時(shí)我們將我們的持續(xù)交付流水線(xiàn)也通過(guò)Jenkinsfile的形式保存在源代碼庫(kù)中，那么只要我們獲取了軟件倉(cāng)庫(kù)的代碼，就能夠獲取支撐我們軟件交付各個(gè)階段的所有物品，包括源代碼以及運(yùn)行時(shí)環(huán)境。并且對(duì)于任何代碼或者環(huán)境的變更都能夠通過(guò)持續(xù)交付流水線(xiàn)進(jìn)行持續(xù)的驗(yàn)證和反饋 同時(shí)Rancher也提供了內(nèi)置的監(jiān)控功能：包括主機(jī)以及容器。通過(guò)Catalog我們也能快速的搭建ELK的日志分析平臺(tái)以及其他的監(jiān)控服務(wù)。 通過(guò)服務(wù)容器化，以及引入諸如Rancher這樣的容器管理平臺(tái)。我們可以使我們的研發(fā)團(tuán)隊(duì)更加專(zhuān)注于軟件架構(gòu)以及環(huán)境架構(gòu)的設(shè)計(jì)，而將一些其他的運(yùn)維和管理工作交給容器管理平臺(tái)來(lái)管理。能有效的減少我們?cè)贒evOps實(shí)踐當(dāng)中的成本，包括人員能力以及自動(dòng)化能力的要求。 同時(shí)對(duì)于微服務(wù)團(tuán)隊(duì)而言，我們基于持續(xù)交付流水線(xiàn)能夠使軟件交付各個(gè)階段的人員能夠有效的協(xié)同工作，保證我們能夠又快又安全的交付軟件，每一次代碼變更都能夠產(chǎn)生一個(gè)可工作的軟件（當(dāng)然前提是這些人都是屬于同一個(gè)團(tuán)隊(duì)） 所以對(duì)于轉(zhuǎn)型微服務(wù)而言，我們需要明白持續(xù)交付以及DevOps文化是支撐我們微服務(wù)轉(zhuǎn)型的一個(gè)重要手段。 我們需要有獨(dú)立自治的全功能型團(tuán)隊(duì)，通過(guò)引入虛擬化技術(shù)，容器化技技術(shù)，以及相應(yīng)的管理平臺(tái)來(lái)減少我們部署和運(yùn)維的復(fù)雜度。并且通過(guò)更加完善的質(zhì)量保證體系來(lái)確保我們的服務(wù)能夠確實(shí)的去支撐我們的軟件交付質(zhì)量。 總結(jié) 就像開(kāi)篇說(shuō)的一樣，“微服務(wù)可能是實(shí)現(xiàn)SOA的最正確的姿勢(shì)”，它實(shí)際上是我們軟件交付領(lǐng)域大量?jī)?yōu)秀實(shí)踐的一個(gè)集合。同時(shí)微服務(wù)是不銀彈，在引入微服務(wù)后我們同時(shí)需要面對(duì)更多復(fù)雜的問(wèn)題。 通過(guò)引入容器化，以及容器化管理平臺(tái)能夠減少我們?cè)谵D(zhuǎn)型微服務(wù)過(guò)程中的大量成本；通過(guò)小步嘗試，積累經(jīng)驗(yàn)和能力，能夠幫助我們?cè)谖⒎?wù)化轉(zhuǎn)型中走的更加順暢； 同時(shí)根據(jù)不同的業(yè)務(wù)模式選擇不同的微服務(wù)重構(gòu)模式能夠幫組我們能夠在解決現(xiàn)有問(wèn)題的同時(shí)來(lái)全面提升我們整個(gè)產(chǎn)品的響應(yīng)力； 最后一張圖，簡(jiǎn)單總結(jié)了一下微服務(wù)中關(guān)于實(shí)踐與設(shè)計(jì)模式的概覽，希望能夠?qū)Υ蠹以诜?wù)化轉(zhuǎn)型中提供幫助； 最后在準(zhǔn)備這次分享的過(guò)程中我準(zhǔn)備了一些例子，包括Jenkins2的容器化，以及基于Jenkins2和Rancher實(shí)現(xiàn)端到端的持續(xù)交付過(guò)程： https://github.com/yunlzheng/rancher-jenkins2 https://github.com/yunlzheng/jpetstore-6 有興趣的同學(xué)可以進(jìn)行參考，當(dāng)中不完善的部分也希望能夠提供反饋，能夠進(jìn)行相應(yīng)的改進(jìn)。...
Read More