【云驻共创】微服务流量治理的总结与探索——字节跳动的流量治理体系

【云驻共创】微服务流量治理的总结与探索

——字节跳动的流量治理体系

一、引言

在一个公司在成长的过程中，会面临业务增长、团队成长，进而导致沟通成本的上升。对于小型服务，开发人员较少，我们可以很好的对业务进行沟通，达到更好的产品效果。但是当开发人员增多，不同team之间的沟通可能不那么顺畅时，就需要我们对架构进行拆解。接下来本文将从字节跳动的微服务流量治理体系来总结一下流量治理的方法。

二、分布式架构拆分

分布式架构主要分为单体架构、SOA架构和微服务架构。下面简单介绍一下三者的区别以及优缺点。

（1）单体架构

单体架构比较适合小项目，优点是：开发简单直接，集中式管理，基本不会重复开发，功能都在本地，没有分布式的管理开销和调用开销。

它的缺点也非常明显，特别是对于互联网公司来说。

开发效率低：所有的开发在一个项目改代码，递交代码相互等待，代码冲突不断。

代码维护难：代码功能耦合在一起，新人不知道何从下手。

部署不灵活：构建时间长，任何小修改必须重新构建整个项目，这个过程往往很长。

稳定性不高：一个微不足道的小问题，可以导致整个应用挂掉。

（2）

SOA架构

SOA架构是面向服务架构，是B/S模型、XMl/Web Service的技术延伸。现在，不少企业采用dubbo开发应用系统。Dubbo是简单有效的SOA架构，值得采用。

优点是：把模块拆分，使用接口通信，降低模块之间的耦合度，把项目拆分成若干个子项目，不同的团队负责不同的子项目，增加功能时只需要在增加一个子项目，调用其它系统的接口就可以。

缺点是：系统之间交互需要使用远程通信，接口开发增加工作量。

（3）微服务架构

微服务是系统架构上的一种设计风格，主旨是将一个原本独立的系统拆分成多个小型服务，这些小型服务都在各自独立的进程中运行，服务之间通过基于HTTP/HTTPS协议的RESTful API进行通信协作，也可以通过RPC协议进行通信协作。被拆分成的每一个小型服务都围绕着系统中一些耦合度较高的业务功能进行构建，并且每个服务都维护着自身的数据存储，业务开发，自动化测试案例以及独立部署机制。由于有了轻量级的通信协作基础，所以这些微服务可以使用不同的语言来编写。

相比较于单体应用架构和SOA架构，微服务架构的主要特点是组件化、松耦合、自治、去中心化。包括体现每个微服务粒度要小，而每个服务是针对一个单一职责的业务能力的封装，专注做好一件事情。独立部署运行和扩展。每个服务能够独立被部署并运行在一个进程内。这种运行和部署方式能够赋予系统灵活的代码组织方式和发布节奏，使得快速交付和应对变化成为可能。

在使用微服务的过程中，有很多难点，包括机房调度、过载处理、服务健康检查等等，需要我们去解决。所以需要我们使用流量治理来解决上述问题。

微服务难点

三、流量治理体系

在字节跳动，将流量治理体系分为四个方向，包括路由（Route）、安全（Secure）、控制（Control）和观测（Observe）这四个方向，接下来，对每个部分进行详细的介绍。

（1）路由

路由是指流量从一个服务实体出发，通过服务发现和规则调度，智能控制流量走向，最终达到目标服务实体的过程。

路由的几个能力，包括动态负载均衡、测试导流能力、泳道调度、区域集群调度、服务发现和负载均衡。其中服务发现和负载循环是路由的基本能力。动态负载均衡、测试导流能力是路由中的更高阶的能力，可以实现对流量的更好控制。

在服务发现方面，字节跳动有四个产品，可以实现不同程度的功能和能力。分别是Consul、Etcd、ZooKeeper和Eureka。

对于微服务体系中，我们需要一些负载均衡的策略。包括几种主要的算法，比如加权轮转调度、最小请求数、一致性哈希、随机调度、高度一致性哈希等等。

在泳道调度方面，主要应用于用户测试的方面。可以对服务在不同泳道之间进行调度，增加流量的控制和访问能力。

区域、集群调度能力一般都是对于大公司的体量较大的服务而言，多个机房之间可以进行转换和调度，其中一个机房下游服务出现问题时可以进行及时调整。

测试导流可以实现Mock服务、流量复制和重放、线下流量导入至开发机和蓝绿发布等等功能。

动态负载均衡可以实现对节点权重随着系统状态的变换而动态变化。其作用就是降低延迟和错误率，同时剔除故障实例和丰富监控大盘。

（2）安全

安全就是通过服务实体的身份认证、授权、流量的加密通信来完成对流量传输内容的安全保护。

身份认证就是对于服务请求时对其进行身份进行认证，其可以为微服务之间的RPC调用提供基本的保证，拒绝没有权限的请求方。但是身份是可以随意指定的，不具备真实有效性。为了确保授权效果，往往需要通过鉴定确保请求方身份的有效性。

授权就是对某些操作的权限进行赋予。对于有安全性要求的服务来说，授权和校验是必不可少的。完善的授权系统应该包括：细粒度划分，去覆盖微服务调用之间的各种授权需求；通配模式，减少配置负担；界面清晰，对于授权与否清晰明了；预线上模式，对未来即将拒绝的请求发起报警，便于服务运维者按需授权并观察效果。

加密是指公司服务间的RPC请求为了保证通信安全，防止内容被截获，需要开启mutualTLS双向认证机制。其作用就是提供可靠的身份认证、防止内容的泄露和篡改，同时防止流量重放攻击。

（3）控制

控制是通过多种治理途径，维护服务实体的正常运行和流量的最优处理，为流量源提供最优的可用性。在无法提供服务稳定性时，对服务进行一些降级来维持基本功能。包括控制、故障注入、熔断、丢弃流量、流量限制等，接下来对每个部分进行详细的介绍。

最简单控制就是超时控制，就是当微服务体系中一个缓解出现问题，不应该一直等下去，超过一定的时间就应该放弃调用这个服务，来保证服务的正常运行。比如头条中信息有获取和排序，如果排序服务出现问题，超过一定时间就应该放弃，这样用户得到的可能不是优先排序的新闻，但是至少保证了用户可以看到新闻。

控制还包括故障注入，故障注入简单来说就是人为加入故障来检测服务是否可以稳定运行。在复杂的分布式系统中，包含了大量的交互和依赖点，随时都可能出现各种异常和故障。处理不好就会导致系统性能低下，业务停滞或者是其他各种无法预期的异常行为。只靠人力是无法阻止这些故障的发生，所以我们应该致力于在这些异常行为被触发之前，尽可能的识别出会导致这些异常的、系统中脆弱的、易出故障的环节。进行有针对性的加固和防范。从而避免故障发生时带来的严重后果。

熔断是指当服务方可能因为处于过载状态，造成错误率上升。这时候如果还是维持原有的请求发送频率，很有可能造成雪崩。因此当出现这种情况时，我们可以调整请求的发送频率，将下游服务从雪崩临界点拯救回来，继续服务。具体来说就是当错误率达到阈值时，触发熔断机制，丢弃对下游的请求，以防止被下游拖挂；然后熔断器会逐步尝试恢复一些请求，并决定熔断器是保持生效的状态，还是逐步解除。

丢弃流量是指在服务发出实际需求大于稳定阈值时，丢弃部分流量作为维稳手段，通过牺牲一些能力的方式来保持一定的可用性，防止超出阈值后的雪崩。常见的方式有两种。分别是同等优先级和不同优先级下的。这一点很像河流上下游的水闸控制站。每一个站点都会根据上下游信息来进行实时调控，当下游水位过高时，上游进行一定的截留控制，来减小下游压力，保证整条河流的压力在允许范围之内。

最后是流量限制。是一种防止服务被打挂而进行的限流设置，一般对稳定性较高的服务器都会进行压力测试，来找到本服务单实例的最大请求数，然后再进行设置。

除此之外，我们还可以增加一些动态的控制，动态判断服务需要的时间，在达到阈值时进行对服务降级处理。

（4）观测

观测是对流量状态进行记录和追踪，尽可能实时地展示出流量运转状态，以便我们可以及时发现问题。主要分为三个方向，分布式追踪、日志收集和指标设定，这三个方向互有重叠也各有不同。

分布式追踪会把服务的详细信息进行记录，使用采样和染色，为后台开发的同学提供链路数据采集和展示、分析和统计，可以帮助大家快速分析和诊断分布式应用架构下的性能瓶颈，提高微服务时代下的开发诊断效率。

日志收集就是记录一些logs，包括几种方式，流式日志、错误日志聚合、日志流检索和调用链检索。流式日志就是对日志进行中央存储，日后可以对每个时间进行查看。错误日志聚合就是对所有日志中的错误信息进行整合，然后让开发人员只分析错误出现的地方。日志流检索和调用链检索就是日志和调用情况进行快速检索，已达到快速找到错误的能力。

指标是指建立一套指标系统，提供存储时序数据和对时序数据进行聚合查询的功能。包括一些报警阈值的设定等等。

四、总结

本文主要介绍了字节跳动中对微服务流量治理的几个方向和具体方法。其中包括四个大方向，分别是路由、安全、控制和观测。通过这四大方向对上下游服务进行实时调控和调整，已达到稳定整个微服务架构的效果。

本文整理自华为云社区内容共创活动第二期之【线下分享】字节跳动微服务流量治理体系简介。

查看活动详情：https://bbs.huaweicloud.com/forum/thread-111494-1-1.html

微服务

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。