Github 因为软件升级曾经导致过长达 6 个多小时的全球性服务中断 ...
Meta(原名：Facebook) 刚刚经历一起因为配置推送错误导致全球 6 半个多小时的系统瘫痪 ...
诸如此类的大型 IT 系统故障每隔一段时间都会出来一个。为企业搭建一个安全可靠的在线应用架构，是一个系统架构师主要责任，他除了将业务系统架构吃透以安全地应对当前的业务流量之外，还需要具备构建未来的能力，即所选取的架构需要能应对业务未来几年的业务增长。这种能力，和技术潮流无关，和所选择的技术的人才市场容量有关，和企业自身业务形态和增长方向有关。
我们先抛开 IT 系统的基础设施和企业业务的具象，抽象到在线应用的两个关键衡量指标中去：流量和容量。容量的目标还是为了满足流量的基本需求，而我们不断优化的目标，就是一直在这个两个指标中找出一个能代表"技术先进性"的平衡点。这个平衡点意味着：高效且精确地将现有的资源（容量）服务于现有的，及其可预见的业务流量；高效意味着性能，精确则无损。
这系列文章一共三篇，旨在让技术回归到系统架构师们需要解决的本质问题：如何让在线应用最大化的流量无损。
02
问题定义
Aliware
我们先参考一个通用业务的部署架构图（说明：由于笔者的技术背景是 Java，熟悉的基础设施也主要是云服务为主，所以其中很多的例子是使用 Java 体系中的一些技术架构和云服务进行阐述，一些细节点上可能不太具备其他编程语言的参考的意义。）：
这张图是一个典型而且很简单的一个业务架构，这个业务会服务于来自全球的用户，当用户的请求到达之后，经过负载均衡转入后面的微服务网关集群，微服务网关做完一些基础的流量清洗、鉴权、审计等工作之后再根据业务形态路由到后面的微服务集群中；整个微服务集群最终会和不同的数据服务进行数据的交换（读/写）操作。
根据上面这一描述，我们暂且将整个流量请求服务的过程分为：流量解析、流量接入、流量服务、数据交换四个主要阶段。在这四个阶段中，都有可能发生流量损耗的可能性，而且每一种可能发生之后我们所采取的解决方案会是截然不同的，有的通过一些框架配置就能解决，而有的可能需要整体架构的重构。我们会通过三篇系列文章对这四个阶段，一一进行剖析，开篇主要讲的是流量解析和流量接入。
03
流量解析
Aliware
解析的场景的本质还是通过一个服务名称获取一个服务的地址，这一过程是我们常规意义上的 DNS 解析。但是传统域名解析在目前各个服务商的管理策略影响下，经常会遇到域名缓存、域名转发、解析延迟、跨服务商访问等问题。尤其在面向全球的互联网业务中，Web 服务通过传统 DNS 解析时，不会判断终端用户的来源，随机选择其中一个 IP 地址返回给终端用户，这不仅会可能由于跨服务商解析而降低了解析效率，而且还会导致终端用户可能因为跨洋访问而导致速度变慢。
上面的这些问题都有可能会直接导致我们的流量受损。为应对上述的场景，常用的解决方案有智能解析和 HTTP DNS 技术，分别阐述如下：
01
智能解析
智能解析，一开始主要用来解决不同运营商之间跨网络解析而引起网络不通的问题，他主要是根据访问端的地址，选择对应网络下的接入点，从而达到解析正确的地址的目的。随着这一技术的持续迭代和演进，有的产品在此基础上加入了不同地域的网络质量监测节点，可以从一组机器中根据不同节点的服务质量，进行更智能的解析。目前阿里云上的智能解析依托于云的基础设施，甚至可以以应用为单位动态扩缩节点池中的节点，最大化的在这一领域发挥了云上弹性的价值：
021
HTTPDNS
HTTPDNS 顾名思义，就是使用 HTTP 协议代替 DNS 的发现协议；一般由服务商（或者自建）提供一个 HTTP 服务器，这个服务器提供一个极其简练的 HTTP 接口，客户端在发起访问之前，由 HTTPDNS SDK 先行发起解析，解析失败再 Fallback 回原来的 LocalDNS 解析。HTTPDNS 在解决 DNS 劫持、域名缓存 等场景下特别有效，缺点就是大部分方案还需要客户端侵入 SDK；同时 Server 的建设成本会有点高昂。不过随着云厂商在这一领域的持续迭代，已经涌现出来了越来越多更加轻量的解决方案；这也会帮助 HTTPDNS 这种技术成为今后 DNS 领域演进的主流趋势之一。
04
流量接入
Aliware
当 DNS 解析到正确的地址之后，便进入到了流量接入这个核心的入口，这个过程的主角是网关，一个网关通常意义上扮演的角色重要有路由、鉴权、审计、协议转换、API 管理、以及安全防护等重要的功能。业界常见的CP是负载均衡和微服务网关的结合，但是这个两个组件配合起来往往有一些场景比较容易忽略，以下图为例，我列举三个容易忽略的场景简单做一些介绍，分别是：流量安全、网关应用管控与流量路由。
01
流量安全
不安全的流量分为两类，第一类是攻击类型的流量；第二类是超过系统容量的流量。攻击类型流量的防范主要以软硬件的防火墙为主。这一类解决方案颇为成熟，在这里不再赘述。这里比较难以甄别是超过系统容量的非攻击流量，如何在这种场景下，最大限度地保证正常流量得到相应的服务，还能保护极有可能雪崩的整个业务系统是抉择的难点。
简单的尝试，是在网关这里按照请求 QPS、并发数、分钟请求数甚至接口参数等，做类似于 RateLimit 的流量控制。但是在此之前，是要求系统架构师能对系统的容量心中有数。我们推荐的做法是在做类似的安全防护之前，先要做到一个整体的容量评估，这里的评估不单单只是针对某些 API 做一次压力测试这么简单，是推荐针对生产环境做一次真正全链路的压测（第三篇中将有一节专门介绍），然后再针对性的作出安全策略的调整。
02
网关应用管控
网关归根结底还是一个应用，按照我们目前接触到的客户线上系统来看，一个完全是微服务架构的业务系统，这个应用会占用整个系统 1/6 - 1/3 不等的机器资源，这已经算得上是一个很大规模的应用了。既然是一个应用，它就会进行一些常规的运维管控操作如启动、停止、部署、扩容等。但是由于网关是一个业务系统的咽喉，他是不能做频繁的操作的，这意味着有几点原则要非常清晰地传导到开发团队内部：
配置与代码解耦：能力（协议转发、限流配置、安全策略、路由规则等）是必须可配置，且可以动态下发的。
不要夹杂业务逻辑：让网关回归到网关的本质，不要夹杂业务逻辑；一个自己不加戏的网关就是一个好网关！
除了上述两点开发侧的原则之外，在运维侧也有相应的原则。运维上除了常规的监控和报警，还需要具备自适应的弹性能力。但是网关的弹性牵扯的点太多：比如需要配合前面的负载均衡一起操作（如：进行应用部署之前需要在负载均衡处将对应节点下线或降权，应用部署确保启动成功之后再将节点上线）；同时弹性还需要和应用管控体系自动化地进行配合才能做到线上流量无损。
03
流量路由
经过网关的下一步，则是将应用路由到下一节点，互联网场景在有高可用多机房部署的情况下，为了提高服务质量，都会采取就近路由的原则。即如果网关入口在主机房，下一跳就希望路由到同机房的节点，同样的道理，在一个微服务集群中的下下一跳，还是希望可以路由到相同的机房。否则，如果出现了跨机房调用的请求时，RT 就会变得很长，最终因请求超时而导致流量有损失，如下图：
要想做到同机房调用的效果，我们需要对选择的服务框架有很好的理解。核心的原理是对于下一跳的路由时，需要优先选择相同机房的地址。而不同的框架和业务所在的部署环境，都需要作出一些针对性的定制开发才能做到严格意义上的同机房优先调用。
原文链接：https://www.toutiao.com/a7042528290594390558/?log_from=d23882c40b927_1640682412938
