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

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

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

系統設計的本質

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

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

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

微服務

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

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

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

微服務的原則

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

域驅動設計的原則

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

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

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

示例場景映射

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

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

清潔代碼

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

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

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

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

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

結語

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