TSF微服务治理实战系列（一）——治理蓝图

导语

随着对微服务架构的不断深入探索，越来越多的企业加入到了微服务架构中，体验微服务架构在开发、运维、测试等方面带来的优势。同时，随着企业中落地微服务架构的案例越来越多，管理的服务、实例数量越来越大，微服务架构的一些问题也随之而来。本系列文章将通过对服务治理这一专题的蓝图描绘和单独介绍，与读者一起探讨微服务治理能力在诸多场景中的实战应用。

作者简介

崔凯

腾讯云 CSIG 微服务产品中心产品架构师

多年分布式、高并发电子商务系统的研发、系统架构设计经验，擅长主流微服务架构技术平台的落地和实施目前专注于微服务架构相关中间件的研究推广和最佳实践的沉淀，致力于帮助企业完成数字化转型。

微服务和服务治理

微服务架构大约在2011年威尼斯的一个软件架构会议上被提出，到2014年由Martin Fowler、James Lewis共同发表文章《Microservices:a definition of this new architectural term》让微服务红极一时，到今天已10年有余。

在这段发展进程中，微服务从被人质疑到成为当前云原生趋势中不可或缺的角色，从一个概念到拥有相对完善的落地体系和方法论，其中都包含着对微服务架构不断的探索和坚持。

那么，在微服务架构于企业中落地越来越多的当下，微服务架构的规模越来越大、服务和实例数量越来越多，也相应的产生了更高阶的服务治理需求。所以，服务治理逐渐成为了新的关注重点和研究对象。

TSF和服务治理

TSF作为腾讯云针对微服务架构管理而设计的平台型产品，服务治理是平台建设的核心价值点之一。

本实战系列主要讨论范围包括TSF平台中服务路由、服务鉴权、服务限流、服务熔断容错、服务可观测性、服务配置等服务治理核心能力（如下图“微服务框架”中所示）。

通过针对上述内容的介绍，可以系统性的帮助读者了解TSF在服务治理方面的核心能力，及针对企业自身场景应如何选择匹配的场景和动作。如针对电商大促的场景如何进行限流、针对灰度版本如何进行全链路灰度发布等，帮助TSF平台使用者实际解决服务治理相关的流量管控、链路排障、配置管理等一系列问题。

准备动作和落地思路

在详细了解TSF服务治理各项能力之前，有几个问题需要“扪心自问”。

现在是否是引入服务治理的好时机？

服务治理并不是银弹，服务规模和流量都比较小的初创企业，适用服务治理的场景并不多。而对于一些中大型企业，服务及实例的数量、并发数及流量、DB数据量等都开始爆发性增长，服务治理才有其存在的必要性。另外，系统要基本完成微服务架构的转型，这个转型包括面向团队、管理、中间件平台等的转变，最好也已完成容器化，这样可以借助容器平台来提高治理效率。

引入服务治理前需要做什么准备？

开发针对服务指定治理规则之前，还有几项工作要提前准备，包括但不限于系统调研、确定立项、组织分工。

系统调研

在开展服务治理工作之前，要对系统的必要信息充分了解，需要从一线最了解的同学那里汇总，如下表示例所示：

调研事项	调研内容
业务简介	简单介绍业务的功能和业务逻辑
应用架构	通过应用架构图阐述代码、模块间关系及服务间依赖等，使用的开发框架、语言等
物理架构	展示物理部署图、调用关系图
数据量及并发	描述当前数据量及并发量的峰值、均值及如何发展
当前治理方式	描述当前已经使用了哪些服务治理框架、工具
中间件	限流、路由等一些治理能力需要兼容MQ、Redis等一些中间件
支撑平台	DevOps、容器平台、监控告警平台等
现存问题	描述在流量控制、配置管理等服务治理方面现存的客户痛点问题

确定立项

管理者与研发团队完成对服务治理目标、面对的挑战和成本等方面的讨论，确定服务治理项目组并立项。其中，服务治理目标的确定应尽量务实，以是否解决实际问题入手，而不是“把这些高大上的治理能力都用上”。对于服务治理的成本预估，除了选型的沉没成本、学习成本、开发成本，还有关键的上线成本，一定关注开发的review和测试的准入准出，避免开发人员和测试人员对非功能性需求“不自觉的松懈”。

组织分工

细化服务治理工作，从项目管理条线和技术开发条线分别规划。项目管理条线需要依次确认服务治理阶段及阶段目标，将服务治理划分为各专项小组并确立接口人和汇报方式，制定从开发、测试、投产保障、运维监控到培训赋能的服务治理落地计划，确保服务治理的功能真正能在企业中用起来。技术条线除了完成服务治理上线所需的代码改动和发布，还需要逐步完善《服务治理FAQ》《服务治理规范手册》等一系列知识沉淀，与《服务治理待办清单》共同形成迭代闭环，使得服务治理建设可持续优化。

TSF服务治理蓝图

在完成了前期的准备工作之后，需要先简单介绍一下TSF服务治理的蓝图，以便能对服务治理有个大致全面的概览。虽然TSF服务治理涉及到很多方面，但总体来说，小编将它概括为 “三心两意”。

三心：所有的服务治理能力都是基于标签化管控、语言框架兼容、屏蔽底层差异三个核心来设计的。

1：标签化管控

指针对TSF服务治理各项能力针对不同的管控场景，提供了粗粒度的系统标签和细粒度的自定义标签两种管控粒度。系统标签根据TSF自身设计原语划分，如部署组、服务、应用、版本等；自定义标签根据用户自身业务属性划分，将控制粒度细化到每一个请求上，如用户ID、时间、地域、用户类别等。通过不同的管控粒度，平衡治理的成本和收益。

2：语言框架兼容

由于使用了不同的语言、开发框架、通讯协议，就需要不同版本的SDK、不同形态的框架对接代码、不同的调用方式，这种凌乱的形式给整个研发团队带来了巨大的负担。比如SDK升级，首先要针对不同语言开发SDK，其次要针对不同开发框架做兼容，最后在升级的时候还要协调各个团队的升级时机，挑战非常巨大。TSF通过统一的管控平台，同时兼容Spring Cloud、Service Mesh及Dubbo框架，兼容HTTP、gRPC等多种协议，拉平了语言、框架、协议方面的差异，让用户专注于业务本身。

3：屏蔽底层差异

TSF作为一套通用的微服务技术平台，在各行各业都有不少落地案例。这就要求TSF必须具备适配客户各类硬件资源、操作系统及已有架构，才能帮助客户完成快速落地的目标。TSF可以适配目前主流的虚拟机、容器平台，甚至某些场景下的物理机，国产及腾讯云自研操作系统，以及一些旧有的架构体系。通过屏蔽这些差异，避免曾经在各种平台间切来切去的烦恼，让用户体验“同一套平台，同一种感受”。

两意：我们把服务治理分解为 “治”和“理”两部分，以治作为配置手段，以理作为监管手段。通过主动的治和被动的理的配合，形成治理规则不断优化和监控效果不断提高的正向循环，让服务治理能力融入企业的研发流程中。

1：治

治是主动的管理动作，包括针对安全的服务鉴权，针对流量的服务限流、服务路由、服务熔断，针对可用性的服务容错，针对配置的应用配置、日志配置等。

2：理

理是被动的监控分析，包括对已运行服务指标的监控、服务间的依赖拓扑关系、拓扑链路与业务日志的联动、业务日志搜索及监控、API统一管理、各类事件的汇总及告警等。

TSF-SDK通讯机制

TSF-SDK各项服务治理能力总体上依赖了同一套架构，下图以Spring Cloud应用为示例。整个通讯过程主要包括租户端的TSF-SDK，管控端的consul接入层、服务治理组件、浏览器。TSF-SDK通过pom引用内嵌在JAVA应用中，consul接入层负责与租户端各服务的TSF-SDK连通，服务治理组件为提供各项服务治理逻辑的无状态组件，浏览器主要供管理员通过控制台页面创建各类服务治理规则和配置。

TSF-SDK服务治理规则、分布式配置、网关规则等配置的实时更新，依赖TSF-SDK定时发起的长轮训机制。

TSF-SDK的整个监听过程分为两种情况：阻塞时有内容更新、阻塞时无内容更新。在服务（应用）完成注册发现之后，TSF-SDK向Consul接入层发起一个长轮询请求，以便应用侧可以实时上报数据，同时实时接收管控端下发的规则、应用配置等数据。当在长轮询请求有效期内发生了治理规则推送，那么长轮询请求立刻返回被更新的内容给TSF-SDK；当长轮询请求持续等待直到超过了最大等待时间，请求也会返回，同时发起下次长轮询请求，以避免连接无限期等待带来的风险。

当TSF-SDK拿到治理规则或配置后，实时更新本地内容，并根据SDK内逻辑进行服务路由、服务鉴权、服务限流等一系列操作。整体流程基本相似，只是下发内容和SDK处理逻辑不同。

结语

服务治理并不适用于所有场景，尤其不同的业务场景需要对应的治理规则和参数配置，用的不好反而会成为业务的累赘。本实战系列的目的也在于此，通过深入TSF各项服务治理能力和落地场景，让读者朋友了解TSF服务治理的正确打开方式，实现构建完整的服务治理体系的目标，通过治理手段提高业务可用性，帮助企业降本增效。

One more thing

近日，Spring Cloud Tencent 于6月14日正式对外开源，作为腾讯开源的一站式微服务框架，Spring Cloud Tencent 实现了 Spring Cloud 标准微服务 SPI ，开发者可以基于 Spring Cloud Tencent 快速开发 Spring Cloud 微服务架构应用。Spring Cloud Tencent 的核心依托腾讯开源的一站式服务发现与治理平台 Polarismesh ，实现各种分布式微服务场景。