組織通過微服務基本準則、領域驅動的設計概念和編碼優(yōu)秀實踐成功地使用微服務，可以充分利用Kubernetes/容器原生的優(yōu)勢。

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

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

系統(tǒng)設計的本質

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

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

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

微服務

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

這兩個概念推動了微服務的七個原則，允許團隊獨立地工作、部署、失敗、交付和擴展。

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

微服務的原則

使用微服務時，常見的故障點是過早分解。在通常情況下，團隊在與應用程序的用例相關的更改中會付出高昂的成本，或者初始服務邊界是錯誤的。將應用程序分解為微服務通常是開始微服務之旅的最簡單方法。

域驅動設計的原則

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

首先必須理解，組織使用的任何代碼都始于存在于域中的問題以及存在業(yè)務愿望的問題。因此，領域驅動設計的旅程始于領域專家和開發(fā)人員。通常，組織可能有多位領域專家一名開發(fā)人員或各種開發(fā)人員，但只有一名領域專家。無論組織結構如何，團隊的目標都是著眼于全局并創(chuàng)建所謂的場景地圖。

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

示例場景映射

這些域為組織提供了有關如何創(chuàng)建有限場景的好主意。有界場景表示屬于系統(tǒng)的服務，它封裝并定義了該模型的特定職責。創(chuàng)建有界場景就是要建立一個邊界，在這個邊界中，域語言在這個空間中不會造成混淆的問題。

定義有限的場景、通用語言和場景映射可以使組織在使用微服務時專注于全局。域驅動設計指導開發(fā)人員討論系統(tǒng)設計時，因為組織經常在尋找通過代碼表示真實世界的方法。域驅動設計（DDD）對于不熟悉特定領域的組織或開發(fā)人員，或者對于希望將其應用程序分解為微服務的組織而言，域驅動設計（DDD）尤其有用。

清潔代碼

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

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

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

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

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

結語

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