Couchbase 的四種微服務架構

作者 | Marian Puhl

譯者 | 馬可薇

策劃 | 萬佳

在過去十年中，微服務已經逐漸成爲了一種常見的架構模式。

在這種方法中，許多小型、自動、鬆散耦合的服務通過分佈式網絡運行在一起。每一種微服務通常都限定在特定的功能與業務邊界內，在各自的進程中運行，並且可以獨立於其他服務進行管理與部署。

這種架構與傳統的單體應用相比更加靈活，但同時也要求各自的微服務能夠保證其彈性、可擴展性與持久性。

在這篇文章中，我想要專注介紹微服務架構的數據管理部分，以及 Couchbase 是如何爲用戶的數據層提供低延遲、彈性與可延展性的。

1 集成緩存與彈性擴展帶來的簡單性

微服務是與明確的業務領域綁定的。

舉例來說，你的業務領域可能是產品、活動、結算、電子商務應用的用戶資料服務，不同的微服務在應用內共同協作，但其實卻在各自爲營。通常情況下，不同的團隊各自負責其獨立的服務，並擁有他們自己的發佈循環與 CI/CD 管道，結果是更加敏捷並迅捷的開發過程。

在上圖中的場景裏，不同的微服務都有其各自的域數據，並通過 API 進行不同服務間的數據共享。在交易結算中，結算服務可以從用戶資料服務中調用對應的客戶數據。這種架構模式帶來了更多的靈活性的同時，也讓微服務跨平臺複用成爲了可能。

搭建彈性與可擴展的服務是很關鍵的。對於無狀態的微服務而言，這點應當很容易實現的。但如果需要保留數據，你最終還是需要一個彈性的數據庫架構，隨着服務用量的增加而與微服務一同擴展。

Couchbase 是搭建在一個內存優先的架構上，不僅提供了爲低延遲數據訪問的集成緩存，同時還有彈性的擴展性。這樣你就可以單獨地擴展 Couchbase 的各個服務，而不會影響你的微服務運維。

隨着你的數據流量的增加，你要做的也只是增加更多的 Couchbase 節點。如果你需要額外的隊列容量，添加更多的 Couchbase 隊列節點到你的集羣中即可。

通過這種多維擴展，不同的 Couchbase 服務將再也不用爲系統資源而競爭了。與之相反，Couchbase 的底層基礎設施將是圍繞服務的特定需求而量身定製，舉例來說，Couchbase 查詢服務通過使用具有大量內存的計算實例，儘可能多地提供來自集成緩存的數據，並利用一個具有額外內核的節點以支持更大量的查詢請求。

Coachbase 的可擴展性與資源的獨立性。

具備彈性與分佈式的 Couchbase 架構還可以通過維護數據的副本來保證其高可用性。在一個節點發生故障的情況下，Couchbase 會自動將其失效以保證整體繼續運行。

2Couchbase 中微服務的常見模式

微服務的關鍵特徵之一就是其鬆散的耦合，而這一特徵則允許它們單獨進行開發、部署、訪問控制和擴展。

鬆散耦合要求底層數據庫的基礎設施支持隔離各個微服務的數據，可以通過爲每個微服務單獨運行各自的數據庫實例，或者通過控制對數據相關部分的訪問來達成這一點。

雖然傳統的關係型數據庫支持使用數據庫模式（schema）進行隔離，但這一類型的數據庫通常很難進行擴展。它們缺乏 JSON 數據模型的靈活性，並且在數據庫基礎設施中斷的情況下將造成單點故障。在涉及微服務架構時，我們尤其需要注意這一點，中斷將會對所有使用同一數據庫的微服務造成非常嚴重的後果。

Couchbase 是爲微服務設計的。它是一個高度可擴展且具有彈性的分佈式數據庫，提供極強的靈活性以及多層次的隔離機制，以支持在同一 Couchbase 集羣中運行的多達一千的微服務。

Couchbase Server 7 引入了作用域以及集合的概念。

作用域和集合是在一個桶（bucket）中創建邏輯容器，用於數據的整理及隔離。桶作爲一個關鍵空間，允許用戶進行個人內存配額、磁盤和 I/O 優先級的配置，而這些設置也僅僅是提供了部分的資源隔離。桶、作用域以及集合在基於角色的訪問控制、跨數據中心複製（XDCR），以及備份和恢復等所有層面上，提供了獨立的部署和生命週期管理。

這些功能會爲你的開發團隊帶來更高的靈活性，並允許多種模式的微服務存在。下面我們將更詳細地爲各位講解四種最常見的模式。

模式 1：每個微服務的專用 Couchbase 集羣

通過一個專門的 Couchbase 集羣，以物理隔離的方式提供獨立的擴展，雖然可行，但如果要處理的是成百上千的微服務，這種方式可能就不太現實了。

模式 2：使用桶進行隔離

對比起使用專有集羣進行隔離的手段，桶可以通過內存分配、磁盤 I/O 以及複製提供部分的資源隔離。然而，每個 Couchbase 集羣擁有的桶的數量是有限制的，這就導致每個集羣中支持的微服務數量不能超過 30 個。

如果你對於隔離不同服務之間的數據沒有嚴格的要求，或者還有其他用於確保每個微服務僅在自己的數據庫中運行的手段，那麼我們可以讓多個微服務使用同一個桶。一般來說，桶的共享使用是通過識別文檔中的密鑰或額外類型屬性來完成的。

在 Couchbase 7 中引入作用域和集合之前，這種模式就已經在被業界普遍使用了。

模式 3：使用集合進行隔離

另一種更爲強大的微服務部署方式是利用集合進行隔離。

雖然我們所使用的桶可以提供資源隔離，但集合可以在邏輯上隔離並控制微服務的訪問，使得用戶得以在一個 Couchbase 集羣中運行多達一千的微服務。在下面的示意圖中，每一個微服務都有各自的集合，Couchbase 基於角色的訪問限制確保了每個微服務都只能在對應的集合中訪問它們各自的數據庫。

模式 4：使用桶和集合進行隔離

這一種微服務模式與模式 3 相類似，區別在於模式 3 是將所有的集合放進一個桶，而模式 4 則是將不同的集合分組到不同的桶中。

這種模式允許你根據桶內微服務或集合的特徵分別配置桶，並以內存分配或複製數等方式達成單獨桶和其內含的集合的物理隔離。

Coachbase 中並不存在構造與隔離數據的單一最佳解決方案，但通過使用桶作用域以及集合，你將擁有無窮盡的解決方案以輕鬆滿足你對微服務架構的具體需求。

3 容器化部署

現如今的部署環境正在向微服務的方向轉移，這一點是毋庸置疑的。而於此同時，業界內也在向通過 Kubernetes 和 OpenShift 管理的容器化部署發展。

有了 Couchbase，你的自主且完全管理的有狀態數據庫應用和你的微服務將在同一 Kubernetes 平臺上運行，這種方式爲你提供了完全的隔離，並通過自動故障轉移，甚至是自動擴展集羣爲你減輕工作負擔。

更多信息，請訪問 Couchbase 自動 Operator。

原文鏈接：

https://blog.couchbase.com/microservices-architecture-in-couchbase

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/fijbTWjIZpMVvvfW_cvWGA