简介：本篇是整个《如何构建流量无损的在线利用架构》系列的第一篇，这一系列共三篇，旨在应用最为奢侈的语言将影响在线利用流量稳定性的技术问题做一个归类，这些问题的解决方案有的只是一些代码层面的细节，有的须要工具进行配合，有的则须要低廉的解决方案，如果您的利用想在云上有一个【流量无损】的一站式体验，能够关注阿里云的《企业级分布式应用服务（EDAS）》这个云产品，EDAS 也将会继续向默认接入流量无损的方向演进。
作者 | 孤弋、十眠
前言
Github 因为软件降级已经导致过长达 6 个多小时的全球性服务中断 …Meta(原名：Facebook) 也刚刚经验一起因为配置推送谬误导致寰球 6 个多小时的零碎瘫痪 …
诸如此类的大型 IT 系统故障每隔一段时间都会进去一个。为企业搭建一个安全可靠的在线利用架构，是一个零碎架构师次要责任，他除了将业务零碎架构吃透以平安地应答以后的业务流量之外，还须要具备构建将来的能力，即所选取的架构须要能应答业务将来几年的业务增长。这种能力，和技术潮流无关，和所抉择的技术的人才市场容量无关，和企业本身业务状态和增长方向无关。
咱们先抛开 IT 零碎的基础设施和企业业务的具象，形象到在线利用的两个要害掂量指标中去：流量和容量。容量的指标还是为了满足流量的根本需要，而咱们一直优化的指标，就是始终在这个两个指标中找出一个能代表 ” 技术先进性 ” 的平衡点。这个平衡点意味着：高效且准确的将现有的资源（容量）服务于现有的，及其可预感的业务流量；高效意味着性能，准确则需无损。
这系列文章一共三篇，旨在让技术回归到零碎架构师们须要解决的实质问题：如何让在线利用最大化的流量无损。
问题定义
咱们先参考一个通用业务的部署架构图（阐明：因为笔者的技术背景是 Java，相熟的基础设施也次要是云服务为主，所以其中很多的例子是应用 Java 体系中的一些技术架来和云服务进行论述，一些细节点上可能不太具备其余编程语言的参考的意义。）
这张图是一个典型而且很简略的一个业务架构，这个业务会服务于来自寰球的用户，当用户的申请达到之后，通过负载平衡转入前面的微服务网关集群，微服务网关做完一些根底的流量荡涤、鉴权、审计等工作之后再依据业务状态路由到前面的微服务集群中；整个微服务集群最终会和不同的数据服务进行数据的替换（读 / 写）操作。
依据下面这一形容，咱们暂且将整个流量申请服务的过程分为：流量解析、流量接入、流量服务、数据交换四个次要阶段。在这四个阶段中，都有可能产生流量损耗的可能性，而且每一种可能产生之后咱们所采取的解决方案会是截然不同的，有的通过一些框架配置就能解决，而有的可能须要整体架构的重构。咱们会通过三篇系列文章对这四个阶段，一一进行分析，开篇次要讲的是流量解析和流量接入。
流量解析
解析的场景的实质还是通过一个服务名称获取一个服务的地址，这一过程是咱们惯例意义上的 DNS 解析。然而传统域名解析在目前各个服务商的管理策略影响下，常常会遇到域名缓存、域名转发、解析提早、跨服务商拜访等问题。尤其在面向寰球的互联网业务中，Web 服务通过传统 DNS 解析时，不会判断终端用户的起源，随机抉择其中一个 IP 地址返回给终端用户，这不仅会可能因为跨服务商解析而升高了解析效率，而且还会导致终端用户可能因为跨洋拜访而导致速度变慢。
下面的这些问题都有可能会间接导致咱们的流量受损。为应答上述的场景，罕用的解决方案有智能解析和 HTTP DNS 技术，别离论述如下：
1、智能解析
智能解析，一开始次要用来解决不同运营商之间跨网络解析而引起网络不通的问题，他次要是依据拜访端的地址，抉择对应网络下的接入点，从而达到解析正确的地址的目标。随着这一技术的继续迭代和演进，有的产品在此基础上退出了不同地区的网络品质监测节点，能够从一组机器中依据不同节点的服务质量，进行更智能的解析。目前阿里云上的智能解析依靠于云的基础设施，甚至能够以利用为单位动静扩缩节点池中的节点，最大化的在这一畛域施展了云上弹性的价值：
（图片来源于阿里云云解析文档）
2、HTTPDNS
HTTPDNS 顾名思义，就是应用 HTTP 协定代替 DNS 的发现协定；个别由服务商（或者自建）提供一个 HTTP 服务器，这个服务器提供一个极其简练的 HTTP 接口，客户端在发动拜访之前，由 HTTPDNS SDK 后行发动解析，解析失败再 Fallback 回原来的 LocalDNS 解析。HTTPDNS 在解决 DNS 劫持、域名缓存 等场景下特地无效，毛病就是大部分计划还须要客户端侵入 SDK；同时 Server 的建设老本会有点昂扬。不过在随着云厂商在这一畛域的继续迭代，曾经涌现进去了越来越多更加轻量的解决方案；这也会帮忙 HTTPDNS 这种技术成为今后 DNS 畛域演进的支流趋势之一。
流量接入
当 DNS 解析到正确的地址之后，便进入到了流量接入这个外围的入口，这个过程的配角是网关，一个网关通常意义上表演的角色重要有路由、鉴权、审计、协定转换、API 治理、以及平安防护等重要的性能。业界常见的 CP 是负载平衡和微服务网关的联合，然而这个两个组件配合起来往往有一些场景比拟容易疏忽，以下图为例，我列举三个容易疏忽的场景简略做一些介绍，别离是：流量平安、网关利用管控与流量路由。
1、流量平安
不平安的流量分为两类，第一类是攻打类型的流量；第二类是超过零碎容量的流量。攻打类型流量的防备次要以软硬件的防火墙为主。这一类解决方案颇为成熟，这里不再赘述。这里比拟难以甄别是超过零碎容量的非攻打流量，如何在这种场景下，最大限度的保障失常流量失去相应的服务，还能爱护极有可能雪崩的整个业务零碎是抉择的难点。
简略的尝试，是在网关这里依照申请 QPS、并发数、分钟申请数甚至接口参数等，做相似于 RateLimit 的流量管制。然而在此之前，是要求零碎架构师能对系统的容量成竹在胸。咱们举荐的做法是在做相似的平安防护之前，先要做到一个整体的容量评估，这里的评估不单单只是针对某些 API 做一次压力测试这么简略，是举荐针对生产环境做一次真正全链路的压测（第三篇中将有一节专门介绍），而后再针对性的作出安全策略的调整。
2、网关利用管控
网关归根结底还是一个利用，依照咱们目前接触到的客户线上零碎来看，一个齐全是微服务架构的业务零碎，这个利用会占用整个零碎 1/6 – 1/3 不等的机器资源，这曾经算得上是一个很大规模的利用了。既然是一个利用，它就会进行一些惯例的运维管控操作如启动、进行、部署、扩容等。然而因为网关是一个业务零碎的咽喉，他是不能做频繁的操作的，这意味着有几点准则要十分清晰的传导到开发团队外部：
配置与代码解耦：能力（协定转发、限流配置、安全策略、路由规定等）是必须可配置，且能够动静下发的。
不要夹杂业务逻辑：让网关回归到网关的实质，不要夹杂业务逻辑；一个本人不加戏的网关就是一个好网关！
除了上述两点开发侧的准则之外，在运维侧也有相应的准则。运维上除了惯例的监控和报警，还须要具备自适应的弹性能力。然而网关的弹性牵扯的点太多：比方须要配合后面的负载平衡一起操作（如：进行利用部署之前须要在负载平衡处将对应节点下线或降权，利用部署确保启动胜利之后再将节点上线）；同时弹性还须要和利用管控体系自动化的进行配合能力做到线上流量无损。
3、流量路由
通过网关的下一步，则是将利用路由到下一节点，互联网场景在有高可用多机房部署的状况下，为了服务质量，都会采取就近路由的准则。即如果网关入口在主机房，下一跳就心愿路由到同机房的节点，同样的情理，在一个微服务集群中的下下一跳，还是心愿能够路由到雷同的机房。否则，如果呈现了跨机房调用的申请时，RT 就会变的很长，最终因申请超时而导致流量有损，如下图：
要想做到同机房调用的成果，咱们须要对抉择的服务框架有很好的了解。外围的原理是对于下一跳的路由时，须要优先选择雷同机房的地址。而不同的框架和业务所在的部署环境，都须要作出一些针对性的定制开发能力做到严格意义上的同机房优先调用。
结语
本篇是整个《如何构建流量无损的在线利用架构》系列的第一篇，这一系列共三篇，旨在应用最为奢侈的语言将影响在线利用流量稳定性的技术问题做一个归类，这些问题的解决方案有的只是一些代码层面的细节，有的须要工具进行配合，有的则须要低廉的解决方案，如果您的利用想在云上有一个【流量无损】的一站式体验，能够关注阿里云的《企业级分布式应用服务（EDAS）》这个云产品，EDAS 也将会继续向默认接入流量无损的方向演进。下一篇，咱们将从在线利用公布与服务治理的角度带来不一样的干货，敬请期待。
原文链接
本文为阿里云原创内容，未经容许不得转载。