 在这种方法中，许多小型、自动、松散耦合的服务通过分布式网络运行在一起。每一种微服务通常都限定在特定的功能与业务边界内，在各自的进程中运行，并且可以独立于其他服务进行管理与部署。 这种架构与传统的单体应用相比更加灵活，但同时也要求各自的微服务能够保证其弹性、可扩展性与持久性。 在这篇文章中，我想要专注介绍微服务架构的数据管理部分，以及 Couchbase 是如何为用户的数据层提供低延迟、弹性与可延展性的。 微服务是与明确的业务领域绑定的。 举例来说，你的业务领域可能是产品、活动、结算、电子商务应用的用户资料服务，不同的微服务在应用内共同协作，但其实却在各自为营。通常情况下，不同的团队各自负责其独立的服务，并拥有他们自己的发布循环与 CI/CD 管道，结果是更加敏捷并迅捷的开发过程。 在上图中的场景里，不同的微服务都有其各自的域数据，并通过 API 进行不同服务间的数据共享。在交易结算中，结算服务可以从用户资料服务中调用对应的客户数据。这种架构模式带来了更多的灵活性的同时，也让微服务跨平台复用成为了可能。 搭建弹性与可扩展的服务是很关键的。对于无状态的微服务而言，这点应当很容易实现的。但如果需要保留数据，你最终还是需要一个弹性的数据库架构，随着服务用量的增加而与微服务一同扩展。 Couchbase 是搭建在一个内存优先的架构上，不仅提供了为低延迟数据访问的集成缓存，同时还有弹性的扩展性。这样你就可以单独地扩展 Couchbase 的各个服务，而不会影响你的微服务运维。 随着你的数据流量的增加，你要做的也只是增加更多的 Couchbase 节点。如果你需要额外的队列容量，添加更多的 Couchbase 队列节点到你的集群中即可。 通过这种多维扩展，不同的 Couchbase 服务将再也不用为系统资源而竞争了。与之相反，Couchbase 的底层基础设施将是围绕服务的特定需求而量身定制，举例来说，Couchbase 查询服务通过使用具有大量内存的计算实例，尽可能多地提供来自集成缓存的数据，并利用一个具有额外内核的节点以支持更大量的查询请求。 Coachbase 的可扩展性与资源的独立性。 具备弹性与分布式的 Couchbase 架构还可以通过维护数据的副本来保证其高可用性。在一个节点发生故障的情况下，Couchbase 会自动将其失效以保证整体继续运行。 微服务的关键特征之一就是其松散的耦合，而这一特征则允许它们单独进行开发、部署、访问控制和扩展。 松散耦合要求底层数据库的基础设施支持隔离各个微服务的数据，可以通过为每个微服务单独运行各自的数据库实例，或者通过控制对数据相关部分的访问来达成这一点。 虽然传统的关系型数据库支持使用数据库模式（schema）进行隔离，但这一类型的数据库通常很难进行扩展。它们缺乏 JSON 数据模型的灵活性，并且在数据库基础设施中断的情况下将造成单点故障。在涉及微服务架构时，我们尤其需要注意这一点，中断将会对所有使用同一数据库的微服务造成非常严重的后果。 Couchbase 是为微服务设计的。它是一个高度可扩展且具有弹性的分布式数据库，提供极强的灵活性以及多层次的隔离机制，以支持在同一 Couchbase 集群中运行的多达一千的微服务。 Couchbase Server 7 引入了作用域以及集合的概念。 作用域和集合是在一个桶（bucket）中创建逻辑容器，用于数据的整理及隔离。桶作为一个关键空间，允许用户进行个人内存配额、磁盘和 I/O 优先级的配置，而这些设置也仅仅是提供了部分的资源隔离。桶、作用域以及集合在基于角色的访问控制、跨数据中心复制（XDCR），以及备份和恢复等所有层面上，提供了独立的部署和生命周期管理。 这些功能会为你的开发团队带来更高的灵活性，并允许多种模式的微服务存在。下面我们将更详细地为各位讲解四种最常见的模式。 通过一个专门的 Couchbase 集群，以物理隔离的方式提供独立的扩展，虽然可行，但如果要处理的是成百上千的微服务，这种方式可能就不太现实了。 对比起使用专有集群进行隔离的手段，桶可以通过内存分配、磁盘 I/O 以及复制提供部分的资源隔离。然而，每个 Couchbase 集群拥有的桶的数量是有限制的，这就导致每个集群中支持的微服务数量不能超过 30 个。 如果你对于隔离不同服务之间的数据没有严格的要求，或者还有其他用于确保每个微服务仅在自己的数据库中运行的手段，那么我们可以让多个微服务使用同一个桶。一般来说，桶的共享使用是通过识别文档中的密钥或额外类型属性来完成的。 在 Couchbase 7 中引入作用域和集合之前，这种模式就已经在被业界普遍使用了。 另一种更为强大的微服务部署方式是利用集合进行隔离。 虽然我们所使用的桶可以提供资源隔离，但集合可以在逻辑上隔离并控制微服务的访问，使得用户得以在一个 Couchbase 集群中运行多达一千的微服务。在下面的示意图中，每一个微服务都有各自的集合，Couchbase 基于角色的访问限制确保了每个微服务都只能在对应的集合中访问它们各自的数据库。 这一种微服务模式与模式 3 相类似，区别在于模式 3 是将所有的集合放进一个桶，而模式 4 则是将不同的集合分组到不同的桶中。 这种模式允许你根据桶内微服务或集合的特征分别配置桶，并以内存分配或复制数等方式达成单独桶和其内含的集合的物理隔离。 Coachbase 中并不存在构造与隔离数据的单一最佳解决方案，但通过使用桶作用域以及集合，你将拥有无穷尽的解决方案以轻松满足你对微服务架构的具体需求。 现如今的部署环境正在向微服务的方向转移，这一点是毋庸置疑的。而于此同时，业界内也在向通过 Kubernetes 和 OpenShift 管理的容器化部署发展。 有了 Couchbase，你的自主且完全管理的有状态数据库应用和你的微服务将在同一 Kubernetes 平台上运行，这种方式为你提供了完全的隔离，并通过自动故障转移，甚至是自动扩展集群为你减轻工作负担。 更多信息，请访问 Couchbase 自动 Operator。 原文链接： https://blog./microservices-architecture-in-couchbase -End- |
|
|
