比如用户在打开百度首页时，浏览器会先请求DNS解析www.baidu.com域名，得到一个IP，然后与这个IP建立通信请求。机房的流量分配是DNS用户可能没有注意到解析过程。

DNS根据规则，将域名分析到其中一个机房IP。常用的规则有：

• 浙江省按地域规则引流，如，浙江省引流ZJ机房，上海市引流SH机房等等
• 根据运营商排水，国内特点：世界上最遥远的距离是你在电信，我在移动，根据用户运营商排水到运营商机房
• 根据权重规则，如机房A:机房B:机房C:机房D按照 1:1:2:1 随机排水的比例由四个机房承担 20%:40%: 流量

一些应用程序多域名优化技术，可以将路由选择推向 DNS 避免后层跨机房转发。比如百度域名就是www.baidu.com，当系统已知用户数据属于哪个单元时，跳转到一个单独的域名，直接分析到相应的数据中心，例如可以直接转发到www.baidur1.com。

具体接受服务请求IP请求发送到目标服务器后，接入服务请求处理。

接下来，让我们来看看下一个用户请求的整个访问和处理过程，如下图所示：

• 用户首次要求， DNSA机房可以分析VIP，经过LVS被发到“接入层”集群
• “接入层”分析请求，发现带 zone cookie 因此，请求随机分发给机房内的机器，如ServiceA
• ServiceA拦截器分析会话中的拦截器 uid，计算该 uid 应该在哪组 RZone 处理。若为本 zone 处理 uid 范围，继续业务处理逻辑；如果是非本zone，比如应为 RZ002 处理，再根据 A/B 权重比例，选择一个zone，转发请求RZ002的一台 ServiceA
• RZ002的一台ServiceA继续业务逻辑处理，如在本zone内部调用相应的交易创建服务，业务处理完成后返回结果
• RZ001的一台 ServiceA同时将请求返回用户并植入 Cookie：zone=RZ002
• 带上所有用户要求 Cookie zone=RZ002
• “接入层”发现有分析请求 zone cookie，直接代理到对应 Zone 的后端集群

请求用户进入web层后，进入业务处理环节，主要涉及各系统之间的服务呼叫、信息处理等。虽然绝大多数呼叫应该收敛在单元内，但跨单元呼叫是不可避免的。应调用哪个单元是业务数据 LDC 例如，规则决定GZone需要调用Rzone内部服务内部服务uid路由可以处理uid请求的Rzone。

RPC框架本身不理解业务逻辑。如果你想知道应该调整哪个单元的服务，信息只能来自业务参数。

解决方案是框架定义接口，由服务提供商提供实现类，描述如何从业务参数中获得两个 uid。服务提供商在接口上注明并告知框架实现路径。框架可以执行RPC调用时，根据注释的实现，从参数中截取分片ID。再结合 LDC 路由规则中 uid与逻辑单元的映射关系，就知道选择哪个单元的服务提供商了。

消息这层是LDC由于涉及到架构点，因为它涉及到broker但是在LDC本着信息通信的原则。

客户端只跟本 Zone 的 broker 建连，同城 broker 建连之间，跨城通过 跨城的borker 连接。

• 同 Zone 信息链接：发送方 -> broker -> 消费方
• 同城跨 Zone 消息链接是：发送方 -> 同城broker -> 同城broker -> 消费方
• 跨城消息的链路是：发送方 -> broker -> 跨城broker -> 跨城broker -> broker -> 消费方

数据访问层 uid 映射规则与应用层一致。正常情况下，业务请求访问的数据正好在同一个机房。数据访问层是最后的保证。即使前面所有的防线都失败了，一个请求也会进入错误的单元，访问数据库时会去正确的库表，最多需要更长的时间，但绝对不会访问错误的数据。

在LDC灰度发布是架构系统下最典型的应用场景。让我们来看看灰度发布的过程。

• Step1.发布前，将蓝流量调整到0%，将蓝的所有应用无序分为两组
• Step2. 1%观察蓝引流，如无异常，分流比例逐步提高至100%

• Step3. 恢复日常运行状态，蓝绿单元承担50%的线上业务流量

以后会整理成单独的文章。

流量调度是LDC架构中的一个关键设计主题包括技术DNS域名分析，接入层请求处理，Cookie路由标识设置、路由计算、数据层数据源访问范围约束等。正是因为LDC单元化部署架构下的流量控制、分配和要求路由处理能力，使灰度释放、容灾切换、快速容灾成为可能。