背景

了解下双机房要考虑注意的事项，角度不一定完全
原有单机房的情况下，如果有网络问题或者极端情况造成服务瘫痪，双机房就能体现价值。
或者说A机房某服务挂掉了，但是B机房该服务还能work，需要A机房上游切量调用B机房下游服务

说明

角色

A_up:A机房上游服务
B_up:B机房同样的上游服务
A_down:A机房下游服务
B_down: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）中对应一个实例列表，会有下面最简单的结构

down.A:
ip1:port1
ip2:port2
...

down.B:
ipa:porta
ipb:portb
...

流量调度

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

服务标志 -> 下游标志 : 流量(备注)
A.up -> A.down: 99%(代表A.up有99%概率调用同机房下游)
A.up -> B.down: 1%(代表A.up有99%概率调用B机房下游)
B.up -> A.down: 0%
B.up -> B.down: 100%

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

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

其他

这里可以拓展上下游的概念，
上游可以拓展到lb，lb决定多少量打到A机房api，多少量打到B机房api

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

双机房redis集群中，缓存性要支持支持双删，双写，主从同步
存储型中，要保证主从同步以及最终一致性

双机房mysql中，也要保证机房之间的主从同步，写服务只能向特定机房写，读服务都能支持

kafka，同样单机房写，可以多机房可以消费

麻烦一点在于

双机房中，同样的服务要尽量保持容量一致，比如存储型redis

思考

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机房
（这下面涉及到网络模型等，暂时不是非常了解）