Couchbase 的四種微服務架構

泰榮林黑皮 2021-11-06

展開全文

作者丨Marian Puhl

譯者丨馬可薇

策劃丨萬佳

來源丨架構頭條（ID：ArchFront）

在過去十年中，微服務已經(jīng)逐漸成為了一種常見的架構模式。

在這種方法中，許多小型、自動、松散耦合的服務通過分布式網(wǎng)絡運行在一起。每一種微服務通常都限定在特定的功能與業(yè)務邊界內，在各自的進程中運行，并且可以獨立于其他服務進行管理與部署。

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

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

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

微服務是與明確的業(yè)務領域綁定的。

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

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

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

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

隨著你的數(shù)據(jù)流量的增加，你要做的也只是增加更多的 Couchbase 節(jié)點。如果你需要額外的隊列容量，添加更多的 Couchbase 隊列節(jié)點到你的集群中即可。

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

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

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

2Couchbase 中微服務的常見模式

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

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

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

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

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

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

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

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

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

模式 2：使用桶進行隔離

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

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

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

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

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

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