在這種方法中，許多小型、自動、松散耦合的服務(wù)通過分布式網(wǎng)絡(luò)運(yùn)行在一起。每一種微服務(wù)通常都限定在特定的功能與業(yè)務(wù)邊界內(nèi)，在各自的進(jìn)程中運(yùn)行，并且可以獨(dú)立于其他服務(wù)進(jìn)行管理與部署。
這種架構(gòu)與傳統(tǒng)的單體應(yīng)用相比更加靈活，但同時也要求各自的微服務(wù)能夠保證其彈性、可擴(kuò)展性與持久性。
在這篇文章中，我想要專注介紹微服務(wù)架構(gòu)的數(shù)據(jù)管理部分，以及 Couchbase 是如何為用戶的數(shù)據(jù)層提供低延遲、彈性與可延展性的。
微服務(wù)是與明確的業(yè)務(wù)領(lǐng)域綁定的。
舉例來說，你的業(yè)務(wù)領(lǐng)域可能是產(chǎn)品、活動、結(jié)算、電子商務(wù)應(yīng)用的用戶資料服務(wù)，不同的微服務(wù)在應(yīng)用內(nèi)共同協(xié)作，但其實(shí)卻在各自為營。通常情況下，不同的團(tuán)隊(duì)各自負(fù)責(zé)其獨(dú)立的服務(wù)，并擁有他們自己的發(fā)布循環(huán)與 CI/CD 管道，結(jié)果是更加敏捷并迅捷的開發(fā)過程。
在上圖中的場景里，不同的微服務(wù)都有其各自的域數(shù)據(jù)，并通過 API 進(jìn)行不同服務(wù)間的數(shù)據(jù)共享。在交易結(jié)算中，結(jié)算服務(wù)可以從用戶資料服務(wù)中調(diào)用對應(yīng)的客戶數(shù)據(jù)。這種架構(gòu)模式帶來了更多的靈活性的同時，也讓微服務(wù)跨平臺復(fù)用成為了可能。
搭建彈性與可擴(kuò)展的服務(wù)是很關(guān)鍵的。對于無狀態(tài)的微服務(wù)而言，這點(diǎn)應(yīng)當(dāng)很容易實(shí)現(xiàn)的。但如果需要保留數(shù)據(jù)，你最終還是需要一個彈性的數(shù)據(jù)庫架構(gòu)，隨著服務(wù)用量的增加而與微服務(wù)一同擴(kuò)展。
Couchbase 是搭建在一個內(nèi)存優(yōu)先的架構(gòu)上，不僅提供了為低延遲數(shù)據(jù)訪問的集成緩存，同時還有彈性的擴(kuò)展性。這樣你就可以單獨(dú)地?cái)U(kuò)展 Couchbase 的各個服務(wù)，而不會影響你的微服務(wù)運(yùn)維。
隨著你的數(shù)據(jù)流量的增加，你要做的也只是增加更多的 Couchbase 節(jié)點(diǎn)。如果你需要額外的隊(duì)列容量，添加更多的 Couchbase 隊(duì)列節(jié)點(diǎn)到你的集群中即可。
通過這種多維擴(kuò)展，不同的 Couchbase 服務(wù)將再也不用為系統(tǒng)資源而競爭了。與之相反，Couchbase 的底層基礎(chǔ)設(shè)施將是圍繞服務(wù)的特定需求而量身定制，舉例來說，Couchbase 查詢服務(wù)通過使用具有大量內(nèi)存的計(jì)算實(shí)例，盡可能多地提供來自集成緩存的數(shù)據(jù)，并利用一個具有額外內(nèi)核的節(jié)點(diǎn)以支持更大量的查詢請求。
Coachbase 的可擴(kuò)展性與資源的獨(dú)立性。
具備彈性與分布式的 Couchbase 架構(gòu)還可以通過維護(hù)數(shù)據(jù)的副本來保證其高可用性。在一個節(jié)點(diǎn)發(fā)生故障的情況下，Couchbase 會自動將其失效以保證整體繼續(xù)運(yùn)行。
微服務(wù)的關(guān)鍵特征之一就是其松散的耦合，而這一特征則允許它們單獨(dú)進(jìn)行開發(fā)、部署、訪問控制和擴(kuò)展。
松散耦合要求底層數(shù)據(jù)庫的基礎(chǔ)設(shè)施支持隔離各個微服務(wù)的數(shù)據(jù)，可以通過為每個微服務(wù)單獨(dú)運(yùn)行各自的數(shù)據(jù)庫實(shí)例，或者通過控制對數(shù)據(jù)相關(guān)部分的訪問來達(dá)成這一點(diǎn)。
雖然傳統(tǒng)的關(guān)系型數(shù)據(jù)庫支持使用數(shù)據(jù)庫模式（schema）進(jìn)行隔離，但這一類型的數(shù)據(jù)庫通常很難進(jìn)行擴(kuò)展。它們?nèi)狈?JSON 數(shù)據(jù)模型的靈活性，并且在數(shù)據(jù)庫基礎(chǔ)設(shè)施中斷的情況下將造成單點(diǎn)故障。在涉及微服務(wù)架構(gòu)時，我們尤其需要注意這一點(diǎn)，中斷將會對所有使用同一數(shù)據(jù)庫的微服務(wù)造成非常嚴(yán)重的后果。
Couchbase 是為微服務(wù)設(shè)計(jì)的。它是一個高度可擴(kuò)展且具有彈性的分布式數(shù)據(jù)庫，提供極強(qiáng)的靈活性以及多層次的隔離機(jī)制，以支持在同一 Couchbase 集群中運(yùn)行的多達(dá)一千的微服務(wù)。
Couchbase Server 7 引入了作用域以及集合的概念。
作用域和集合是在一個桶（bucket）中創(chuàng)建邏輯容器，用于數(shù)據(jù)的整理及隔離。桶作為一個關(guān)鍵空間，允許用戶進(jìn)行個人內(nèi)存配額、磁盤和 I/O 優(yōu)先級的配置，而這些設(shè)置也僅僅是提供了部分的資源隔離。桶、作用域以及集合在基于角色的訪問控制、跨數(shù)據(jù)中心復(fù)制（XDCR），以及備份和恢復(fù)等所有層面上，提供了獨(dú)立的部署和生命周期管理。
這些功能會為你的開發(fā)團(tuán)隊(duì)帶來更高的靈活性，并允許多種模式的微服務(wù)存在。下面我們將更詳細(xì)地為各位講解四種最常見的模式。
通過一個專門的 Couchbase 集群，以物理隔離的方式提供獨(dú)立的擴(kuò)展，雖然可行，但如果要處理的是成百上千的微服務(wù)，這種方式可能就不太現(xiàn)實(shí)了。
對比起使用專有集群進(jìn)行隔離的手段，桶可以通過內(nèi)存分配、磁盤 I/O 以及復(fù)制提供部分的資源隔離。然而，每個 Couchbase 集群擁有的桶的數(shù)量是有限制的，這就導(dǎo)致每個集群中支持的微服務(wù)數(shù)量不能超過 30 個。
如果你對于隔離不同服務(wù)之間的數(shù)據(jù)沒有嚴(yán)格的要求，或者還有其他用于確保每個微服務(wù)僅在自己的數(shù)據(jù)庫中運(yùn)行的手段，那么我們可以讓多個微服務(wù)使用同一個桶。一般來說，桶的共享使用是通過識別文檔中的密鑰或額外類型屬性來完成的。
在 Couchbase 7 中引入作用域和集合之前，這種模式就已經(jīng)在被業(yè)界普遍使用了。
另一種更為強(qiáng)大的微服務(wù)部署方式是利用集合進(jìn)行隔離。
雖然我們所使用的桶可以提供資源隔離，但集合可以在邏輯上隔離并控制微服務(wù)的訪問，使得用戶得以在一個 Couchbase 集群中運(yùn)行多達(dá)一千的微服務(wù)。在下面的示意圖中，每一個微服務(wù)都有各自的集合，Couchbase 基于角色的訪問限制確保了每個微服務(wù)都只能在對應(yīng)的集合中訪問它們各自的數(shù)據(jù)庫。
這一種微服務(wù)模式與模式 3 相類似，區(qū)別在于模式 3 是將所有的集合放進(jìn)一個桶，而模式 4 則是將不同的集合分組到不同的桶中。
這種模式允許你根據(jù)桶內(nèi)微服務(wù)或集合的特征分別配置桶，并以內(nèi)存分配或復(fù)制數(shù)等方式達(dá)成單獨(dú)桶和其內(nèi)含的集合的物理隔離。
Coachbase 中并不存在構(gòu)造與隔離數(shù)據(jù)的單一最佳解決方案，但通過使用桶作用域以及集合，你將擁有無窮盡的解決方案以輕松滿足你對微服務(wù)架構(gòu)的具體需求。
現(xiàn)如今的部署環(huán)境正在向微服務(wù)的方向轉(zhuǎn)移，這一點(diǎn)是毋庸置疑的。而于此同時，業(yè)界內(nèi)也在向通過 Kubernetes 和 OpenShift 管理的容器化部署發(fā)展。
有了 Couchbase，你的自主且完全管理的有狀態(tài)數(shù)據(jù)庫應(yīng)用和你的微服務(wù)將在同一 Kubernetes 平臺上運(yùn)行，這種方式為你提供了完全的隔離，并通過自動故障轉(zhuǎn)移，甚至是自動擴(kuò)展集群為你減輕工作負(fù)擔(dān)。
更多信息，請?jiān)L問 Couchbase 自動 Operator。
原文鏈接：
https://blog.couchbase.com/microservices-architecture-in-couchbase
-End-
