双机房架构中服务负载均衡及思考

了解下双机房要考虑注意的事项，角度不一定完全

原有单机房的情况下，如果有网络问题或者极端情况造成服务瘫痪，双机房就能体现价值。

或者说A机房某服务挂掉了，但是B机房该服务还能work，需要A机房上游切量调用B机房下游服务

正常情况下:A_up调用A_down,B_up调用B_down

双机房情况下，支持自定义流量百分比，确认多少流量A_up打到B_down

服务发现中，实例可以加上机房标识符，比如上游叫做up.A,up.B,

下游叫做down.A,down.B

这样上游服务可以知道下游服务中，有down.A,down.B两组标识

上面说的每个标识，在服务发现（如zk，consul）中对应一个实例列表，会有下面最简单的结构

支持上游按照百分比指定调用下游量

比如

这样A.up调用下游down服务时，random一下，就能决定是调用A.down还是B.down

同样，如果决定了A.down,那么再在ip1:port1，ip2:port2，...中随机一下即可

这里可以拓展上下游的概念，

上游可以拓展到lb，lb决定多少量打到A机房api，多少量打到B机房api

下游也可以拓展到基础服务如redis，mysql，kafka，但是会涉及到主从同步问题

麻烦一点在于

1.双机房的注意事项

读写的分离，比如A机房为master，负责所有的写包括mysql，redis等，B机房能承担读的职责，如果A挂了，那么只能保证主要的读功能是work的

容量的配比，基本上要求是1：1，不然A完全挂的时候，B扛不住。

正常的时候，A+B的流量才是1，但是A+B能够处理的总容量得是2

延迟：跨机房调用毕竟有延迟，能同机房rpc尽量同机房rpc，同机房下游服务出问题了采取调用对端机房服务

2.api层A机房断了怎么办

lb层全部打到B机房去？

怎么保证请求会到b机房的lb层？

用类似域名下发的服务提供给客户端，客户端访问的时候都去访问B机房

（这下面涉及到网络模型等，暂时不是非常了解）

为了提供比单可用区实例更高的可用性。为了提供比单可用区实例更高的可用性，RDS支持多可用区实例（也叫做同城双机房或者同城容灾实例）。多可用区实例将物理服务器部署在不同的可用区，当一个可用区（A）出现故障时流量可以在短时间内切换到另一个可用区（B）。整个切换过程对用户透明，应用代码无需变更。容灾切换时应用连接可能会断开，因此需要确保有重连机制。

---