組織通過(guò)微服務(wù)基本準(zhǔn)則、領(lǐng)域驅(qū)動(dòng)的設(shè)計(jì)概念和編碼優(yōu)秀實(shí)踐成功地使用微服務(wù)，可以充分利用Kubernetes/容器原生的優(yōu)勢(shì)。

行業(yè)專家參加了DevOps Institue日前在企業(yè)Kubernetes上進(jìn)行的SkiLUp演講。在一個(gè)名為“通過(guò)持續(xù)交付導(dǎo)航Kubernetes之旅”的會(huì)議中，行業(yè)討論了企業(yè)Kubernetes的狀態(tài)以及持續(xù)交付對(duì)于那些使用容器技術(shù)的組織的影響。其演講的中心主題是Kubernetes如何為交付團(tuán)隊(duì)引入新的范例。

對(duì)于使用微服務(wù)的組織來(lái)說(shuō)，其成功應(yīng)用可能是多種多樣的，從云計(jì)算中獲益可能是一個(gè)代價(jià)高昂的過(guò)程。以下將分享如何通過(guò)微服務(wù)原理、領(lǐng)域驅(qū)動(dòng)的設(shè)計(jì)概念以及有關(guān)編碼優(yōu)秀實(shí)踐的注意事項(xiàng)來(lái)成功實(shí)現(xiàn)微服務(wù)。云原生應(yīng)用程序、Kubernetes實(shí)例和微服務(wù)都代表了一個(gè)由層組成的系統(tǒng)。了解這些層使人們能夠獲得釋放云計(jì)算和容器原生優(yōu)勢(shì)所需的見解。

系統(tǒng)設(shè)計(jì)的本質(zhì)

系統(tǒng)設(shè)計(jì)是一個(gè)權(quán)衡的游戲。當(dāng)脫離組織環(huán)境時(shí)，許多架構(gòu)決策在本質(zhì)上并不是對(duì)與錯(cuò)。組織做出決策的優(yōu)秀建議是盡可能擴(kuò)大決策范圍和框架，以在初始時(shí)理解決策。其基本準(zhǔn)則始終是將這些決策與組織的目標(biāo)聯(lián)系起來(lái)。在組織環(huán)境中，基本準(zhǔn)則、實(shí)踐和模式需要與組織的目標(biāo)保持一致。基本準(zhǔn)則為實(shí)現(xiàn)目標(biāo)確定方向，而實(shí)踐和模式代表團(tuán)隊(duì)為實(shí)現(xiàn)這些目標(biāo)而采取的實(shí)際步驟。

例如，很多組織的目標(biāo)可能是成為面向全球市場(chǎng)的事實(shí)上的軟件解決方案。其基本原則之一就是實(shí)行持續(xù)交付，以確保高質(zhì)量的生產(chǎn)部署并很大程度地減少可能造成高昂成本的事故。實(shí)踐是針對(duì)團(tuán)隊(duì)的，并且是特定的。為了支持組織的工程業(yè)務(wù)部門遵循的原則，可以讓SRE團(tuán)隊(duì)針對(duì)事件管理進(jìn)行實(shí)踐，其中包括使用持續(xù)交付平臺(tái)來(lái)跟蹤或?qū)徲?jì)失敗的部署。可以讓開發(fā)人員使用持續(xù)交付解決方案進(jìn)行頻繁的發(fā)布或自助部署。組織的開發(fā)團(tuán)隊(duì)的另一個(gè)實(shí)踐是測(cè)試所有代碼。

雖然不可能知道每一個(gè)決策在未來(lái)會(huì)對(duì)整個(gè)系統(tǒng)產(chǎn)生怎樣的影響，但組織能做的最好的事情就是確定目標(biāo)，以及基本原則和實(shí)踐如何幫助其實(shí)現(xiàn)這些目標(biāo)。

微服務(wù)

微服務(wù)是一種小型的、自主的、協(xié)同工作的服務(wù)。松散耦合和高內(nèi)聚性是指微服務(wù)的兩個(gè)概念。內(nèi)聚性是將相關(guān)代碼分組在一起的方式，而耦合性是指不同的服務(wù)如何相互依賴。軟件工程大師RobertC.Martin對(duì)“單一責(zé)任原則”的定義是微服務(wù)的核心，它的定義是“將因相同原因而發(fā)生變化的那些事物聚集在一起，并將因不同原因而發(fā)生變化的那些事物分開。”

這兩個(gè)概念推動(dòng)了微服務(wù)的七個(gè)原則，允許團(tuán)隊(duì)獨(dú)立地工作、部署、失敗、交付和擴(kuò)展。

面向服務(wù)的架構(gòu)（SOA）旨在應(yīng)對(duì)大型單片應(yīng)用程序、代碼的可重用性和維護(hù)方面的挑戰(zhàn)。微服務(wù)是通過(guò)獨(dú)立服務(wù)實(shí)現(xiàn)面向服務(wù)的架構(gòu)（SOA）的一種方法，其中每個(gè)服務(wù)都充當(dāng)組織業(yè)務(wù)領(lǐng)域的邊界。在微服務(wù)架構(gòu)中，每個(gè)更改都可以彼此獨(dú)立地實(shí)現(xiàn)和部署，而無(wú)需用戶更改。

微服務(wù)的原則

使用微服務(wù)時(shí)，常見的故障點(diǎn)是過(guò)早分解。在通常情況下，團(tuán)隊(duì)在與應(yīng)用程序的用例相關(guān)的更改中會(huì)付出高昂的成本，或者初始服務(wù)邊界是錯(cuò)誤的。將應(yīng)用程序分解為微服務(wù)通常是開始微服務(wù)之旅的最簡(jiǎn)單方法。

域驅(qū)動(dòng)設(shè)計(jì)的原則

域驅(qū)動(dòng)設(shè)計(jì)（DDD）是如何通過(guò)代碼對(duì)現(xiàn)實(shí)世界進(jìn)行建模。因此，域驅(qū)動(dòng)設(shè)計(jì)（DDD）介于出色的代碼和微服務(wù)成功之間。盡管有許多文獻(xiàn)討論了如何從戰(zhàn)略和戰(zhàn)術(shù)上實(shí)施域驅(qū)動(dòng)設(shè)計(jì)（DDD），但在沒有實(shí)踐和指導(dǎo)的情況下，這仍然是一個(gè)相當(dāng)復(fù)雜的話題。以下是利用域驅(qū)動(dòng)設(shè)計(jì)（DDD）概念的入門方法。

首先必須理解，組織使用的任何代碼都始于存在于域中的問題以及存在業(yè)務(wù)愿望的問題。因此，領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的旅程始于領(lǐng)域?qū)＜液烷_發(fā)人員。通常，組織可能有多位領(lǐng)域?qū)＜乙幻_發(fā)人員或各種開發(fā)人員，但只有一名領(lǐng)域?qū)＜摇o(wú)論組織結(jié)構(gòu)如何，團(tuán)隊(duì)的目標(biāo)都是著眼于全局并創(chuàng)建所謂的場(chǎng)景地圖。

構(gòu)建場(chǎng)景映射時(shí)，組織可以通過(guò)了解問題空間、發(fā)現(xiàn)通用語(yǔ)言并為系統(tǒng)創(chuàng)建表示模型來(lái)提取領(lǐng)域知識(shí)。系統(tǒng)由代表問題空間的域和子域組成。這些域在場(chǎng)景映射中稱為場(chǎng)景，并且可以描述組織內(nèi)的不同系統(tǒng)。例如，組織可能需要表示一個(gè)銷售場(chǎng)景和客戶支持場(chǎng)景，以對(duì)處理食品包裝廠的銷售和客戶支持的新軟件應(yīng)用程序進(jìn)行建模。

示例場(chǎng)景映射

這些域?yàn)榻M織提供了有關(guān)如何創(chuàng)建有限場(chǎng)景的好主意。有界場(chǎng)景表示屬于系統(tǒng)的服務(wù)，它封裝并定義了該模型的特定職責(zé)。創(chuàng)建有界場(chǎng)景就是要建立一個(gè)邊界，在這個(gè)邊界中，域語(yǔ)言在這個(gè)空間中不會(huì)造成混淆的問題。

定義有限的場(chǎng)景、通用語(yǔ)言和場(chǎng)景映射可以使組織在使用微服務(wù)時(shí)專注于全局。域驅(qū)動(dòng)設(shè)計(jì)指導(dǎo)開發(fā)人員討論系統(tǒng)設(shè)計(jì)時(shí)，因?yàn)榻M織經(jīng)常在尋找通過(guò)代碼表示真實(shí)世界的方法。域驅(qū)動(dòng)設(shè)計(jì)（DDD）對(duì)于不熟悉特定領(lǐng)域的組織或開發(fā)人員，或者對(duì)于希望將其應(yīng)用程序分解為微服務(wù)的組織而言，域驅(qū)動(dòng)設(shè)計(jì)（DDD）尤其有用。

清潔代碼

微服務(wù)成功的最后一件事是如何維護(hù)和使用組織的代碼。有許多建議可以鼓勵(lì)持久和可理解的企業(yè)代碼庫(kù)。它們中的一些引入了額外的權(quán)衡，但通常的經(jīng)驗(yàn)法則是避免對(duì)不斷增長(zhǎng)的代碼庫(kù)感到自滿，并尋找對(duì)組織有用的做法。

提供共享庫(kù)。跨領(lǐng)域、行業(yè)、團(tuán)隊(duì)和各種代碼庫(kù)重復(fù)的方法是共享庫(kù)的理想選擇。第三方庫(kù)或自定義庫(kù)是使代碼庫(kù)得到良好管理和測(cè)試的一種很好方法，尤其是當(dāng)組織繼續(xù)在域內(nèi)開發(fā)更多功能和服務(wù)時(shí)。建議不要為頻繁更改的代碼引入自定義庫(kù)。定制庫(kù)添加了應(yīng)用程序依賴項(xiàng)，其中對(duì)庫(kù)的更新迫使使用者重新部署。受信任或成熟的第三方庫(kù)通常是避免與自定義庫(kù)相關(guān)的某些維護(hù)和不穩(wěn)定的很好資源。

強(qiáng)制執(zhí)行模塊化分離。正如人們經(jīng)常聽到關(guān)于模塊化隔離的建議一樣，由于變更的性質(zhì)，它在實(shí)踐中經(jīng)常失敗。作為新功能，開發(fā)人員和流程已引入代碼庫(kù)，人們構(gòu)造提供這些功能的模塊和文件的方式也發(fā)生了變化。保持每個(gè)適當(dāng)大小的模塊和文件也很重要。作為準(zhǔn)則，以團(tuán)隊(duì)為單位設(shè)置一些實(shí)踐，以指導(dǎo)組織如何在代碼庫(kù)中組織業(yè)務(wù)邏輯。一些團(tuán)隊(duì)具有三個(gè)組織層，包括表示層、邏輯層和數(shù)據(jù)層。該策略確保業(yè)務(wù)邏輯不會(huì)在應(yīng)用程序邏輯內(nèi)丟失。強(qiáng)制執(zhí)行代碼的模塊化分離也可以幫助團(tuán)隊(duì)成功實(shí)現(xiàn)域驅(qū)動(dòng)設(shè)計(jì)（DDD）。

保持較小的代碼庫(kù)。以前的建議都會(huì)導(dǎo)致維護(hù)較小的代碼庫(kù)。但是，圍繞使代碼庫(kù)保持精簡(jiǎn)和小型化經(jīng)常會(huì)出現(xiàn)一個(gè)常見的問題，即小型化小到什么程度？在許多方面，小型代碼庫(kù)成為一種反模式，因?yàn)閳F(tuán)隊(duì)無(wú)法理解他們的服務(wù)在整個(gè)系統(tǒng)的場(chǎng)景中提供了業(yè)務(wù)責(zé)任。同樣，對(duì)于大型代碼庫(kù)來(lái)說(shuō)，團(tuán)隊(duì)將難以分散決策，了解其代碼庫(kù)，并應(yīng)對(duì)其他形式的更改。這兩個(gè)挑戰(zhàn)的關(guān)鍵指標(biāo)是問題的增加。

維護(hù)干凈的代碼庫(kù)是域驅(qū)動(dòng)設(shè)計(jì)（DDD）、微服務(wù)以及編寫Kubernetes或云原生應(yīng)用程序所不可或缺的。正如Kubernetes、微服務(wù)和域驅(qū)動(dòng)設(shè)計(jì)（DDD）影響組織設(shè)計(jì)代碼的方式一樣。希望這些解釋能夠說(shuō)明其應(yīng)用程序是如何由相互重疊和互補(bǔ)的層組成的，從而形成一個(gè)有效且成功的系統(tǒng)。

結(jié)語(yǔ)

許多投資Kubernetes計(jì)劃的組織都希望通過(guò)微服務(wù)獲得成功。本文展示了如何通過(guò)微服務(wù)獲得成功。擁有如此多的工具、流程和原則來(lái)管理流程可能會(huì)很困難，尤其是當(dāng)最終客戶無(wú)法獲得頻繁的軟件交付時(shí)。持續(xù)交付可幫助組織交付價(jià)值、管理微服務(wù)部署、定義發(fā)布和回滾策略，并降低微服務(wù)的總體成本。