逻辑机房(LDC)是什么

什么是逻辑机房

随着互联网发展，服务器后端架构在分布式这条道路越走越远，途中诞生了逻辑机房的概念。逻辑机房本质上是将物理机房进行逻辑拆分，将一个或多个较大的物理机房假象为更多个较小的机房。其可以解决分布式场景下高可用、高性能等问题。

分布式面临的问题

我们通过分布式面临的各种问题，逐步引导出逻辑机房在解决这类问题时做出的贡献。

数据库负载过大（Rzone）

数据库负载过大是企业在前中期就会遇到的问题，分为数据量过大和连接数过多两种情况，一般采用垂直拆分、水平拆分分散数据和连接。

我们都知道数据库拆分后，数据自然就拆分开来，但是数据库连接又如何拆分呢？其实我们耳熟能详的微服务就拥有拆分连接的能力，对于垂直拆分的数据库，我们一般采用拆分上层应用的方式来减少单库连接；而对于水平拆分的数据库，我们需要使用逻辑机房，如下图：

上图使用到逻辑机房拆分 zone 的部署方式，每个单独 zone 内的集群只连一个库，以前需要多库查询的事务改为跨 zone 应用间事务。zone的拆分规则和数据库水平拆分相同，zone 之间也可以添加相互路由的功能。

数据不利于查询（Gzone）

如果我们根据 zone 进行数据和应用拆分，虽然解决了数据集中和访问压力的问题，但是跨 zone 数据查询却变得更加困难，此时我们将使用另一种逻辑机房（Gzone）来解决问题。

Gzone 是没有对数据进行 zone 拆分的逻辑机房，Gzone 中所有应用实例可以访问每一个库，其用来存储需要被广泛使用的全局数据，如：应用配置、降级策略、限流策略、商家基础信息、商家信用等等。

一般的 Gzone 集群可以承接所有的读写请求，如果是基于 Rzone 高水平拆分后的应用，也可以用 Gzone 来存储需要提供外部使用的公共数据，此时 Gzone 只处理读请求。如下图：

大家应该会发现，如果采用上图的架构方案，那么Gzone将会冗余一份全量数据。在实际使用场景中，我们对上图进行了部分改造：

1. 对于符合Rzone拆分的业务，只从Rzone中读写数据，所有读写请求通过路由层进行分发。
2. 对于不能拆分的业务，抽离出来后单独部署于 Gzone 中。

经过改造后，Gzone 中将不会存在 Rzone 的数据，减少了数据冗余以及数据同步造成的网络开销。

跨机房跨城市延迟（Czone）

通过 Rzone 和 Gzone 解决了负载问题后，服务间调用延时开始成为性能瓶颈。为了减小跨机房延时的影响，我们用了诸多手段，其一：服务间调用优先 zone 内调用，减少跨zone的请求；其二 ：跨 zone 调用优先请求同一物理机房；其三：Rzone 调用 Gzone 情况下，无法避免跨机房访问，则在每个物理机房添加一个 Czone 用来同步 Gzone的数据，提供给同一机房内其他 zone 调用。

总体架构如下图：

上图流程中机房4中的 Gzone 也可以去除，直接通过 Rzone 同步给各 CZone。

微服务基础组件如何灰度

当我们微服务达到一定规模后，基础组件也会多样化，组件的可用性可能影响生态内所有应用的可用性，那么我们如何保证组件的可用性呢？

业内通常使用的方式为组件冗余，即同时在多个机房部署多套基础组件，这样即使某台组件宕机也不会影响整个集群的使用。该方案确实解决了组件的单机问题，但是面临内部逻辑问题导致服务异常时将无能为力（例如访问正常，但是响应内容错误）。

那么如何是好？既然我们将物理机房分为若干个 zone，那为何不以 zone 为单位隔离这些组件呢？我们可以在每个 zone 中独立部署几乎全套的组件，如果组件因为宕机或迭代造成不可正常使用时，只会影响本 zone 内部的可用性。由于应用是多 zone 部署的，部分 zone 不可用最多只会影响少部分用户使用。另一个好处在于我们可以方便的建立单独的 zone 来进行灰度发布和验证，确保每次发布的影响是可控的。

总结：

通过学习逻辑机房的运用，我们可以根据其思想灵活的解决分布式场景下各个业务场景面临的架构问题。分布式需要解决的问题还有很多，希望大家阅读本文后能够举一反三，结合自身实际业务做出合理的选择:)。