腾云忆想技术干货|TSF微服务治理实战系列（一）——治理蓝图

导语

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

作者简介

崔凯

腾云忆想产品架构师

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

微服务和服务治理

微服务架构大约在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服务治理的正确打开方式，实现构建完整的服务治理体系的目标，通过治理手段提高业务可用性，帮助企业降本增效。

本系列技术文章将持续更新，欢迎关注，阅读更多技术内容！