隨著信息技術(shù)深入應(yīng)用，企業(yè)的IT組織效能提升與數(shù)字化轉(zhuǎn)型需求越發(fā)迫切。9月起，嘉為藍(lán)鯨《研效一體，價(jià)值釋放》線上課程直播，針對(duì)企業(yè)IT部門(mén)DevOps落地實(shí)踐分六期詳解項(xiàng)目管理、制品分發(fā)、持續(xù)交付、測(cè)試管理、研發(fā)效能洞察、價(jià)值流管理場(chǎng)景。

在企業(yè)數(shù)字化轉(zhuǎn)型進(jìn)程中，業(yè)務(wù)系統(tǒng)架構(gòu)將逐步經(jīng)歷由單體系統(tǒng)向微服務(wù)架構(gòu)的整體性轉(zhuǎn)變。這種轉(zhuǎn)變的背后，是企業(yè)對(duì)于快速響應(yīng)市場(chǎng)變化、提升業(yè)務(wù)靈活性和可擴(kuò)展性的迫切需求。但在架構(gòu)轉(zhuǎn)型過(guò)程中，不可避免地會(huì)遇到傳統(tǒng)服務(wù)及微服務(wù)并行的狀況。本次直播針對(duì)如何做好混合架構(gòu)發(fā)布編排的問(wèn)題，系統(tǒng)介紹了一套混合發(fā)布編排的可行思路及最佳實(shí)踐，為混合架構(gòu)發(fā)布設(shè)計(jì)提供參考。

01. 傳統(tǒng)單體架構(gòu)與微服務(wù)架構(gòu)

傳統(tǒng)單體系統(tǒng)架構(gòu)通常將所有功能集成在一個(gè)單一的、大型的應(yīng)用程序中，這種架構(gòu)雖然在初期階段有其便利性和效率性，但隨著業(yè)務(wù)的不斷擴(kuò)展和復(fù)雜化，其缺點(diǎn)也逐漸顯現(xiàn)出來(lái)。比如，任何一個(gè)小的修改都可能需要對(duì)整個(gè)系統(tǒng)進(jìn)行測(cè)試和部署，這無(wú)疑大大限制了企業(yè)的敏捷性和靈活性。

相比之下，微服務(wù)架構(gòu)將系統(tǒng)拆分為一組小的、獨(dú)立的、互相通信的服務(wù)，每個(gè)服務(wù)都有自己的數(shù)據(jù)庫(kù)和業(yè)務(wù)邏輯，可以獨(dú)立進(jìn)行開(kāi)發(fā)、部署和擴(kuò)展。這種架構(gòu)使得企業(yè)可以按需快速部署新的服務(wù)，也可以更靈活地對(duì)現(xiàn)有服務(wù)進(jìn)行優(yōu)化和升級(jí)，大大提升了系統(tǒng)的可擴(kuò)展性和可維護(hù)性。同時(shí)，通過(guò)服務(wù)之間的解耦，也可以降低系統(tǒng)的復(fù)雜性，提升系統(tǒng)的穩(wěn)定性。

因此，單體架構(gòu)向微服務(wù)架構(gòu)轉(zhuǎn)變，是大多數(shù)業(yè)務(wù)的整體趨勢(shì)。但一個(gè)系統(tǒng)是否采用微服務(wù)架構(gòu)設(shè)計(jì)或改造，仍需要綜合考慮各種因素，例如系統(tǒng)變更頻繁度、變更安全性要求等。實(shí)際上，單體架構(gòu)對(duì)于特定業(yè)務(wù)系統(tǒng)（如銀行核心系統(tǒng)）仍具有實(shí)用價(jià)值，采用單體架構(gòu)可保障其穩(wěn)定性和變更可控性，不會(huì)被完全替代；亦或是系統(tǒng)過(guò)于老舊，難以進(jìn)行微服務(wù)改造，從而必須繼續(xù)采用單體架構(gòu)。無(wú)論是何種原因，混合架構(gòu)在大部分行業(yè)將會(huì)不可避免地產(chǎn)生，并長(zhǎng)期存在。

02. 不同架構(gòu)發(fā)布方式存在差異

傳統(tǒng)單體架構(gòu)與微服務(wù)架構(gòu)，在發(fā)布方式上也具有顯著區(qū)別。

對(duì)于傳統(tǒng)單體架構(gòu)，應(yīng)用程序通常是單體應(yīng)用，所有的組件都打包在一起，形成一個(gè)單獨(dú)的部署包。部署時(shí)，需要將整個(gè)應(yīng)用程序部署到服務(wù)器上，這意味著對(duì)應(yīng)用程序的任何部分進(jìn)行更新，都需要重新打包整個(gè)應(yīng)用程序并重新部署。由于這種發(fā)布方式的特性，整個(gè)應(yīng)用程序的停機(jī)時(shí)間較長(zhǎng)，這可能對(duì)用戶(hù)體驗(yàn)產(chǎn)生負(fù)面影響。

然而，在微服務(wù)架構(gòu)中，發(fā)布方式則有所不同。開(kāi)發(fā)人員首先編寫(xiě)代碼并進(jìn)行測(cè)試，然后將代碼打包成一個(gè)單獨(dú)的部署包。接下來(lái)，部署人員將部署包上傳到服務(wù)器上，并在服務(wù)器上進(jìn)行部署和配置。最后，運(yùn)維人員會(huì)對(duì)部署的服務(wù)進(jìn)行監(jiān)控和維護(hù)。由于每個(gè)服務(wù)都是獨(dú)立的，因此在更新或者修改某一服務(wù)時(shí)，只需要重新部署對(duì)應(yīng)的服務(wù)，而不是整個(gè)應(yīng)用程序，這大大減少了停機(jī)時(shí)間，提高了系統(tǒng)的可用性和用戶(hù)體驗(yàn)。

傳統(tǒng)單體和微服務(wù)架構(gòu)在發(fā)布方式上的差異，意味著難以采用傳統(tǒng)的手工發(fā)布方式，對(duì)混合了兩種架構(gòu)的系統(tǒng)進(jìn)行逐步、逐級(jí)操作，這種方式將面臨巨大的不確定性和發(fā)布風(fēng)險(xiǎn)，例如發(fā)布版本、制品的錯(cuò)配，發(fā)布出現(xiàn)錯(cuò)誤后難以回滾等。

03. 混合發(fā)布的定義及必要性

當(dāng)前我們?cè)谂c眾多客戶(hù)的交流中，總結(jié)了混合架構(gòu)發(fā)布面臨的多種問(wèn)題和痛點(diǎn)，例如，如何在混合云環(huán)境下適配部署在不同環(huán)境應(yīng)用的協(xié)同發(fā)布，如何有效關(guān)聯(lián)發(fā)布資產(chǎn)，如何保障發(fā)布過(guò)程有序高效的同時(shí)還能夠盡可能地降低發(fā)布風(fēng)險(xiǎn)，如何有效地建設(shè)完整的混合發(fā)布管理體系等。

總體來(lái)說(shuō)，需要一種相對(duì)統(tǒng)一的混合發(fā)布實(shí)踐，整合復(fù)雜混合架構(gòu)發(fā)布過(guò)程，在保障發(fā)布高效性的同時(shí)，還能盡可能地保證多次發(fā)布一致性和穩(wěn)定性，實(shí)現(xiàn)混合發(fā)布編排的標(biāo)準(zhǔn)化、自動(dòng)化和一體化。

04. 混合發(fā)布最佳實(shí)踐

本次直播介紹的混合發(fā)布最佳實(shí)踐，將為上述問(wèn)題痛點(diǎn)提供一種解決的思路和框架。

混合發(fā)布實(shí)踐主要由雙模工程域、發(fā)布單、多級(jí)工程流水線編排三大子實(shí)踐組成，需要通過(guò)研發(fā)團(tuán)隊(duì)、組織級(jí)流程規(guī)范以及一體化研發(fā)工具的相互配合實(shí)現(xiàn)。

1）雙模工程域分解

對(duì)于單體架構(gòu)，更適合采用傳統(tǒng)的瀑布式研發(fā)模式。在單體架構(gòu)中，由于所有的功能模塊都集成在一個(gè)大的應(yīng)用中，修改和更新都需要對(duì)整個(gè)系統(tǒng)進(jìn)行，因此，預(yù)先進(jìn)行詳細(xì)的需求分析和設(shè)計(jì)，然后按部就班地進(jìn)行開(kāi)發(fā)和測(cè)試，這種方式更符合單體架構(gòu)的特性。

對(duì)于微服務(wù)架構(gòu)，更適合采用敏捷開(kāi)發(fā)模式。在微服務(wù)架構(gòu)中，系統(tǒng)被拆分成許多獨(dú)立的服務(wù)，每個(gè)服務(wù)都可以獨(dú)立進(jìn)行開(kāi)發(fā)、部署和更新。這種架構(gòu)讓團(tuán)隊(duì)有更多的靈活性，可以快速響應(yīng)業(yè)務(wù)需求的變化，迭代更新服務(wù)，因此，敏捷開(kāi)發(fā)模式與微服務(wù)架構(gòu)更為相配。

在這兩種模式中，工程部分并非是完全不同的，其中的開(kāi)發(fā)任務(wù)拆分、編碼、構(gòu)建、測(cè)試、制品分發(fā)、部署執(zhí)行等動(dòng)作，本質(zhì)上仍是一致的。因此，即使是傳統(tǒng)的單體架構(gòu)，依舊可以通過(guò)流水線編排，對(duì)發(fā)布工程進(jìn)行線上化和自動(dòng)化，并可加入原本手工操作中需要花費(fèi)大量時(shí)間完成的工作，如需求代碼比對(duì)和文檔清單校驗(yàn)等。通過(guò)對(duì)雙模主流程的區(qū)分和抽象，可以準(zhǔn)確識(shí)別出各自工程域中的關(guān)鍵節(jié)點(diǎn)，以及節(jié)點(diǎn)所需關(guān)聯(lián)的發(fā)布資產(chǎn)，進(jìn)而為后續(xù)環(huán)節(jié)打好基礎(chǔ)。

2）統(tǒng)一發(fā)布調(diào)度

在多模主流程節(jié)點(diǎn)及資產(chǎn)被清晰識(shí)別的基礎(chǔ)上，使用統(tǒng)一發(fā)布單對(duì)發(fā)布資產(chǎn)進(jìn)行標(biāo)注，從而便于后續(xù)通過(guò)工程流水線，按照既定配置，對(duì)各節(jié)點(diǎn)資產(chǎn)進(jìn)行統(tǒng)一匯聚。

3）工程編排實(shí)踐

在發(fā)布單關(guān)聯(lián)了相應(yīng)的發(fā)布資產(chǎn)后，需要按照最小化發(fā)布單元（如單個(gè)微服務(wù)），建設(shè)互相獨(dú)立自動(dòng)化發(fā)布流水線，并通過(guò)多級(jí)流水線的方式依次組裝，形成自動(dòng)化發(fā)布工程流水線組，按照固定的規(guī)則逐級(jí)匯聚，并按照系統(tǒng)間關(guān)聯(lián)，以靈活的調(diào)度方式進(jìn)行發(fā)布。

05. 混合發(fā)布最佳實(shí)踐收益

上述混合發(fā)布最佳實(shí)踐的核心收益在于，對(duì)于復(fù)雜混合系統(tǒng)的復(fù)雜業(yè)務(wù)需求，即能夠提高整體交付效率，降低交付成本，同時(shí)保障交付過(guò)程質(zhì)量，并增強(qiáng)了問(wèn)題追溯能力。

首先，通過(guò)采用“一包到底”的制品晉級(jí)方式，可以確保數(shù)據(jù)源（制品）的可信度，避免了生產(chǎn)與測(cè)試制品版本不一致的問(wèn)題。這種做法可以確保“所測(cè)即所構(gòu)”、“所發(fā)即所測(cè)”。

其次，基于統(tǒng)一發(fā)布單，可以實(shí)現(xiàn)發(fā)布資產(chǎn)關(guān)聯(lián)，快速確認(rèn)發(fā)布資產(chǎn)范圍，提升發(fā)布效率。這一做法避免了反復(fù)確認(rèn)發(fā)布范圍的需求，減少了審批流程，提高了工作效率。

再次，依托一體化研發(fā)平臺(tái)和自動(dòng)化流水線，能夠實(shí)現(xiàn)混合發(fā)布編排的自動(dòng)化和可視化，降低了混合發(fā)布編排的工程門(mén)檻，避免了人工操作導(dǎo)致的發(fā)布問(wèn)題。這一做法可以解決因缺乏統(tǒng)一發(fā)布工具而導(dǎo)致的發(fā)布編排困難，提升發(fā)布過(guò)程的效率。

最后，通過(guò)編排緊急回滾流水線和基于發(fā)布資產(chǎn)鏈路的溯源方式，可以快速向上游制品、配置和代碼溯源，提升缺陷修復(fù)效率和準(zhǔn)確性。這一做法提供了一種有效的問(wèn)題追溯機(jī)制，一旦業(yè)務(wù)系統(tǒng)出現(xiàn)問(wèn)題，能夠迅速回滾并找出問(wèn)題源頭。

總的來(lái)說(shuō)，本次介紹混合發(fā)布最佳實(shí)踐在提升整體發(fā)布效率、確保發(fā)布資產(chǎn)準(zhǔn)確性和增強(qiáng)問(wèn)題追溯能力等方面能夠?yàn)檠邪l(fā)和運(yùn)維發(fā)布團(tuán)隊(duì)帶來(lái)多種正面影響，為企業(yè)數(shù)字化轉(zhuǎn)型提供有效支持。

06. 發(fā)布管理體系建設(shè)

如果您希望參考上述實(shí)踐，構(gòu)建自己的混合發(fā)布體系，那么一個(gè)良好的組織架構(gòu)、合適的管理規(guī)范及成熟的一體化研發(fā)工具平臺(tái)，將是不可或缺的。若您在建設(shè)研發(fā)體系的過(guò)程中存在困惑，歡迎聯(lián)系嘉為藍(lán)鯨產(chǎn)品及咨詢(xún)團(tuán)隊(duì)，我們將為您提供一站式、全方位的研發(fā)體系轉(zhuǎn)型服務(wù)，助力您解決混合架構(gòu)發(fā)布的多重痛點(diǎn)，實(shí)現(xiàn)混合發(fā)布質(zhì)效的共同飛躍。