万字长文分享腾讯云原生微服务治理实践及企业落地建议_云原生_侯诗军

HarmonyOS开发者限时福利来啦！最高10w+现金激励等你拿~ 了解详情 



 写点什么

前言

云原生时代，越来越多的企业借助于微服务与容器化，来提升业务弹性与研发协作效率。Dubbo、Spring Cloud、Istio、Dapr 等各类微服务生态组件百家争鸣。从腾讯内部的 CL5 到 ONS、Taf 等，我们也在服务治理的道路上不断的研究探索，吸取各家之所长打磨了北极星产品。目前腾讯内部的社交、支付、游戏、视频等 90% 以上业务已深度使用北极星进行服务治理，在线节点达 1500+ 万，日均服务调用量超过 65 万亿。

在前不久举办的全球开源技术峰会上，腾讯云产品资深架构师侯诗军发表了《腾讯海量云原生微服务架构建设之路》的主题演讲，本次分享以腾讯微服务架构建设为主，介绍了 TSF、北极星（PolarisMesh）和微服务治理方面的实践经验，并和各行业内人士一起交流了企业实际开展云原生微服务架构转型的落地心得与建议。

架构演化趋势

在分享云原生微服务治理实践之前，我们先来简单看看业内 IT 系统架构的演化路径。早期企业一般都采用单体式的架构，单体式应用程序（Monolithic application）内部包含了所有需要的服务功能，也比较简单方便。刚开始写代码的时候，我们写的 Helloworld 程序其实就是一个典型的单体式应用程序。虽然单体式应用程序简单，但是其各个服务功能模块有很强的耦合性，也就是相互依赖彼此，所以很难扩展。例如，当里面有个业务模块负载过高时，必须扩展整个应用程序，这就导致了额外的资源浪费。同时，由于服务之间的耦合度过高，这就导致了测试、升级都比较困难。随着企业内各种不同的 IT 系统相继建设起来，企业中出现了许多这样的单体式应用程序，久而久之就形成了越来越多的系统孤岛。

在这个时期，企业开始引入 ESB 企业服务总线，试图来解决系统孤岛与服务的治理问题。ESB 实现了不同系统之间不同接口的调用，服务调用者与服务提供者通过 ESB 企业服务总线相连接。虽然这个体系结构比较原来的架构有了改进，但也仍然存在诸多问题：

局限性问题：‌ESB 的中心化架构依赖可能导致其成为性能瓶颈，‌同时较重的架构在应对微服务时可能显得力不从心；
可靠性问题：‌‌虽然 ESB 提供了集中式的服务管理平台，‌有助于保障业务运行，‌但同时也可能存在安全风险，任何模块的一个 Bug 可能拖垮整个应用；
单维扩展：‌ESB 的扩展性主要是单维的，‌即通过运行更多的服务器进行扩展，‌而不同的应用服务对资源的需求不同，‌这限制了其扩展的灵活性；
拆分粒度大：‌ESB 的存在并没有根本解决单体巨石应用的一些问题，‌如服务拆分粒度较大，‌更多的是为了复用而非解决单体应用的缺陷；
不可持续发展：‌引入新的框架或语言需要重构所有业务模块，‌往往需要在初期就选定技术栈，‌这限制了系统的可持续发展。

随着业务规模的增长，ESB 的局限性问题也会愈加明显。业务的快速迭代、弹性伸缩、系统平滑演进、能力沉淀复用、可扩展性等需求对 IT 系统架构提出新的挑战。危险与机遇总是结伴而行，新的挑战对于企业来说是危险，更是提升企业内在核心竞争力的新机遇。在这样的背景酝酿之下，云原生微服务架构也逐渐的应运而生。云原生微服务架构采用分而治之的方式，通过将大型应用拆分成小的、‌独立的服务，‌每个服务都运行在自己的进程中，‌并使用轻量级通信机制进行通信，而容器相对于物理机来说则是更适合这种微服务生长发育的优良土壤。这种新型的架构使得应用更加易于开发、‌测试和部署，‌同时也提高了应用的可伸缩性和可维护性。‌每个微服务可以独立部署，‌无需影响整个系统，‌这种独立性使得技术栈比较灵活。由于可以独立扩展单个微服务，‌无需影响整个系统，‌这样也提高了系统的可扩展性。

从 IDC、Gartner 等权威机构数据可以看出，云原生微服务架构的应用趋势是在逐年递增的。Gartner 预测未来全球三分之二的企业将成为软件生产商，超过 90% 的应用程序为云原生应用。Google Trends 数据显示，Kubernetes 和新型微服务治理软件代表 Istio 的曲线图也是呈上升趋势。

我们从趋势图也可以看出，时至今日 Istio 与传统微服务治理软件代表 Spring Cloud 并驾齐驱，这也是当下企业中两种主流微服务治理方式的真实写照。

服务拆分与容器化

云原生微服务趋势的车轮之所以滚滚向前，很大程度上来说其的确为我们解决了许多生产中的问题。“千里之行，始于足下”。腾讯从早期的单体式架构一路演进过来，也遇到了很多问题，也有着自己的架构演进路线。把时钟拨回到 20 年前，以 QQ 空间为例，早期的时候为了快速上线业务，一些应用往往采用单体式架构。单体式架构有很多优点，比如架构简单，开发与部署方便。但是好景不长，2006 年 QQ 空间推出用户可以根据自己的需求装扮空间的功能，同年年底在线用户数突破 100 万，第二年月活跃用户突破 1 亿。2007 年我们发布了手 Q、超级 QQ、QQ 浏览器、以及数十款手机 QQ 游戏应用，用户规模与产品规模爆发，各种问题也接踵而至：

故障扩散：如果某些功能模块发生异常，可能影响其他的功能模块的可用性；
迭代效率低：不同功能无法独立迭代，任何改动都影响整个应用，增加开发、测试和发布成本；
不利于技术创新：全部功能只能采用相同的技术栈开发，引入新技术和升级新版本的难度太大；
扩展性差：只能扩展整个应用，不能单独扩展某些热点功能，存在资源浪费，系统也无法自动化弹性扩展；
IT 成本高：大量的模块重复开发，各类 IT 资源浪费。

这个时候我们不得不考虑架构优化，进行业务的服务化拆分，以便于适应业务快速发展。例如我们将 QQ 空间按照相册、说说、账号、音乐等领域维度进行拆分，同时调研配套的服务治理组件。

拆分的本质是为了将复杂的问题简单化，通过服务化拆分一方面实现隔离，另一方面实现解耦。服务化拆分的过程可以参考业务能力和通用能力两个维度来进行，同时结合微服务拆分的相关原则。下面分享一些参考原则：

高内聚低耦合：微服务内部业务功能高度内聚，与其他服务之间耦合度低，便于分布式部署和独立开发、维护；
服务自治原则：每个微服务应具备自我管理、独立部署、独立伸缩、独立运维的能力，不与其他服务强依赖；
单一职责原则：每个微服务应有明确的职责范围，只负责自己的一部分业务功能，不涉及其他职责；
服务粒度原则：微服务应按照业务功能划分，而不是按照技术、数据结构等因素划分，保持服务规模适度，避免服务爆裂；
分层单向依赖：分层单向依赖要求每个层次都只能调用下层的接口, 需要对接口设计进行规范化和优化。

“工欲善其事，必先利其器”。服务化拆分如何落地，当然也离不开配套的服务治理相关工具。当时腾讯内部各个部门相继调研或自研了 CL5、ONS、Taf、织云 L5 等各类服务治理组件，一时间在内部百花齐放。以 2008 年我们自研的第一代服务治理中心 CL5 为例，由于早期都是物理机和虚拟机，CL5 在每个机器上会部署一个 L5Agent，用于处理机器上应用的治理问题，同时与管理中心的 L5Server 进行通信，L5Server 负责进行控制指令的下发。应用可以通过 CL5 注册发现其他的应用服务以及后段数据库服务等。CL5 提供了最小单位服务为粒度的注册发现、故障容错及过载保护能力，支撑了当时公司的业务发展。

2011 年 1 月微信正式上线，到 2016 年月活跃用户达到 8.06 亿以上，用户覆盖 200 多个国家和地区，超过 20 多种语言。随着 QQ、微信、视频以及游戏等多个业务增长，流量大规模爆发。由于前期我们已经进行了部分服务化拆分，为解决业务快速弹性问题，所以开启了内部的全面容器化之旅。在 Mesos、Docker Swarm、Kubernetes 等多种容器编排调度系统中最终选择了 Kubernetes，事实上这个方向选择是对的。尽管如此，从虚拟机往容器化演进过渡的过程也并非是一个 Kubernetes 就能解决的。我们的业务服务可能部署在物理机、虚拟机、容器上，各种语言技术栈也不统一，微服务框架体系和 ServiceMesh 体系应用混合存在，也难以进行统一的治理等。

大家期望最终理想的微服务部署形态应该是应用容器化，并采用统一的治理平台管理服务，带来一致的用户体验。然而实际情况往往事与愿违，在企业中一般会有多种部署形态并存。将部分虚拟机应用先试点进行容器化，未计划改造的应用仍虚拟机部署，后续逐步进行容器化。这样一来，就涉及微服务治理中心和容器基础设施层等层面的方案选择适配。

首先在容器网络选择这块，我们根据不同的业务场景选择了不同的 CNI 插件和网络模式。例如，对于规模较大和性能要求较高的场景，我们采用了 BGP 的 Underlay 网络模式，所有的 k8s-node 与接入层交换机之间建立 BGP 关系，容器、虚拟机、物理机网络打通，数据类业务可以无缝的在不同形态中迁移。k8s-node 运行在一个单独的 AS、核心交换网是另一个 AS、不同的 AS 之间走 EBGP。交换机到 k8s-node 通过 ECMP 进行路由级别的负载均衡，在 k8s-node 上有我们自研的 L4/L7 负载均衡和基于 eBPF 的网络插件，进一步提升网络性能。

Kubernetes Service 用于实现集群中业务之间的互相调用和负载均衡，目前社区的实现主要有 Userspace、Iptables 和 IPVS 三种模式。虽然 IPVS 模式的性能最好，但依旧有优化的空间。该模式利用 IPVS 内核模块实现 DNAT，基于 nf_conntrack/iptables 实现 SNAT。nf_conntrack 是为通用目的而设计的，其内部的状态和流程都比较复杂，带来很大的性能损耗。我们自研了新的 IPVS-BPF 模式，完全绕过 nf_conntrack 的处理逻辑，使用 eBPF 完成 SNAT 功能。对最常用的 Pod 访问 Service 场景，p99 时延降低 31%，短连接性能提升 40% 以上。

在应用容器化方面，首先我们是考虑对无状态的应用进行容器化，利用 Kubernetes 的优势进行资源的调度管理。无状态应用可以比较方便地进行横向扩容，宕机甚至可以随时随地被删除，对服务本身不会有影响，这样就能提供高并发的服务能力和更高的容灾能力。对于有状态的应用，也是尽量地往无状态的方向进行改造优化。通常有一些方式，例如多个实例可以互相同步数据，这样任何一个实例异常都是对等的，就可以容忍实例的任意删除和扩容；实现数据集中存储的方式，将状态信息转变为存储，实例只需从集中存储拉取数据到本地缓存即可；在 Pod 底层所依赖的存储这块，尽量的充分的利用好本地存储。

无论是 Kubernetes 自带的 local 和 hostPath，还是 emptyDir 都不能很好的支撑有状态数据。我们自研了 TCS Local PV，支持生命周期单独管理，实现工作负载被删除后，数据不会丢失；支持调度强绑定，可以绑定工作负载调度的工作节点，防止调度到没有数据的工作节点上，满足工作负载在节点本地存储的使用需求。另外我们还专门给有状态 Pod 做了很多优化，我们在 StatefulSet 基础上增强了 StatefulSetPlus Workload。除了完全兼容 StatefulSet 特性外，还支持分批灰度、一键回滚、HPA、原地重启与升级等。

对于短期内难以容器化的应用或不太适合容器化的场景，我们也保留了虚拟机和物理机的形态，自研了 VStation 计算调度器，支持虚拟机、黑石物理计算、异构计算的调度管理。将多级算力融合也是云原生和传统虚拟化的最佳组合，通过融合打通逐步进行架构迭代演进。

在各种异构的环境中，如何通过 YAML 声明式的配置，做到“一次定义、随处运行”，提升业务的部署效率。我们借助于 TAD（Tencent Application Definition）扩展云原生应用描述语言，用以取代传统 IaaS 的以虚拟化资源为视角的模式，帮助业务快速部署上线。TAD 从应用视角出发编排管理平台资源，支持可视化定义应用组件及服务依赖，通过应用市场一键式快速部署应用。

在业务进行大规模容器化的过程中，老的 CL5 服务治理中心也开始面临着新的问题。从架构维度来说，老的微服务治理中心无法单元化隔离，可用性、扩展性等难以适应业务海量访问趋势。从开发维度来说，云原生技术栈和框架的兼容性问题。从部署维度来说，难以支撑物理机、虚拟机到容器化的过渡。从运维维度来说，缺乏监控故障分析与问题定位困难，不利于运维管理。因此，这就催生了新一代微服务治理中心的需求：需要为腾讯内部不同业务、不同技术栈提供统一的服务发现和治理能力。同时兼容物理机、虚拟机、容器，支持 Java、C++、Go、Node.js 等多语言环境，向新的云原生声明式范式演进。

我们也调研了几种当时主流的微服务治理技术方案：

Dubbo：在早期的微服务框架中，很多用户会选择 Dubbo，国内成熟案例也很多。然而 Dubbo 自身的服务治理能力是很弱的，需要自行整合多种服务治理插件；
Spring Cloud：尽管 Spring Cloud 全家桶功能多可以全套搞定，社区也活跃，文档也丰富，但是 Spring Cloud 最大的问题是 Java 语言绑定和业务侵入性强；
Istio：新型的服务网格代表 Istio 巧妙地解决了 Dubbo 和 Spring Cloud 的缺点问题，它通过 Sidecar 来进行流量的劫持代理，做到了无侵入和语言无关。但正是因为这种代理模式，导致了其流量性能损耗问题，同时也缺乏了内部 SDK 支持与精细化的方法级治理。

由此可见，上述的几种方案各有千秋，也有其各自适应的场景。“夫尺有所短，寸有所长，物有所不足，智有所不明也”。在企业实际生产中，也往往是相互关联融合，通过各类组合来满足不同的业务需求。

北极星治理中心

面临着腾讯内部的 CL5、织云 L5、ONS、Taf 等五花八门的微服务组件，如何统一融合也成为难题。公司“930 变革”是一个比较好的契机，PCG 由原先三个事业部合并，大量类似的技术服务亟待整合，而上述这些微服务组件中就有三分之一都在 PCG。2019 年 5 月，腾讯北极星 Oteam 团队成立，旨在打造公司标准化的服务发现与治理方案。

北极星 Oteam 团队首先找到了 PCG，提出统一全公司服务治理中心的方案，经过四轮激烈的讨论与多次修改，方案最终得到双方认可。有了 PCG 的成功案例，再进一步普及到 CSIG 等更多的事业部。通过内部北极星服务治理中心的抽象和整合，解决原有平台存在的问题，并且支持无缝迁移，实现公司微服务的互联互通与统一治理，帮助业务提升研发效率和运营质量。经过了一年多的迭代演进，到 2020 年 9 月底，北极星产品已更新至第 12 个版本，内部共 110 个部门、140 万节点接入了北极星。曾经的 CL5 也完成了历史使命，于当年 10 月 20 日正式下线！

截止 2024 年 7 月底，内部北极星产品在线节点超过 1500 万，日均服务调用量超过 65 万亿，接口调用成功率超过 99.999%，覆盖了内部 90% 以上的业务，包括 QQ、微信、视频、游戏、支付等各类业务。“不积跬步，无以至千里”。通过不断打磨的北极星产品，可以提供面向多语言、异构架构的统一服务治理管控、注册发现、动态配置以及全方位的运维可观测能力，满足企业微服务的开发、测试、运维等多个阶段场景的治理需求。

北极星服务治理中心由控制台、控制面、数据面组成：

控制台提供可视化的管理控制台 UI 界面，同时也支持用户基于 OpenAPI 来开发自己企业的控制台界面；
控制面主要是进行配置、流控、治理等管控指令的下发，其中 Polaris-controller 组件专门用于兼容 Kubernetes 服务同步与 Sidecar 方式注册接入；
数据面提供多语言 SDK、开发框架、Java Agent 和网格代理多种形态的实现，满足不同的业务场景和开发模式，支持异构服务的互联互通和统一治理。

北极星服务治理中心提供了微服务的注册发现能力。相比 Eureka、Nacos、Consul 等传统注册中心来说，北极星采用计算与存储分离的架构：

控制面做到完全无状态，可以随着接入节点的增加横向弹性扩展，轻松的支持百万级节点；
在控制面保留一层缓存，通过增量加载进行数据实时变更，即使存储层故障也不影响存量数据的现网服务。在提高性能的同时，增强了系统的可用性；
支持数据分片，数据 Hash 存储至后端 TDSQL，方便更好的进行扩展，同时 TDSQL 也有强大的跨中心分布式扩展与数据同步能力。

北极星服务治理中心提供了微服务的鉴权、路由、限流、熔断、降级、故障隔离等丰富的服务治理能力，支持如分布式限流、实例隔离、FailOver、FailFast、FallBack、Forking 等。

流量调度：北极星提供动态路由和负载均衡两种类型的流量调度功能。动态路由根据请求标签、实例标签和标签匹配规则，可以实现按地域就近、单元化隔离和金丝雀发布等多种路由策略。负载均衡将请求均衡地分配给不同的被调方实例，支持权重随机、最小负载和权重一致性 Hash 等多种均衡算法。
熔断降级：北极星支持实例、接口和服务三种粒度的熔断策略。如果被调方的部分实例发生熔断，将请求分配给其他实例。如果被调方的某个接口或者服务发生熔断，根据降级策略直接返回。网络抖动、机器故障和程序缺陷等因素都可能导致实例、接口或者服务出现异常，熔断降级可以提高业务的请求成功率。
访问控制：北极星提供鉴权和限流两种访问控制功能。被调方可以设置鉴权规则，允许哪些主调方访问自己，不允许哪些主调方访问自己。被调方也可以设置单机或者分布式限流规则，一方面防止突发流量压垮自己，导致自己完全不可用，一方面防止部分主调方的请求量过多，消耗大量资源，影响其他主调方。
服务网格：对于上述服务发现和治理功能，北极星提供统一的控制面和数据面。数据面功能采用配置化的实现方式，控制面可以下发服务数据和治理规则到数据面，动态调整数据面的执行策略。数据面支持多语言 SDK 和 Sidecar 等模式。

北极星服务治理中心可以与我们的 TSF 微服务框架、云原生网关等组件结合，实现一站式企业级微服务平台，无论微服务的语言是 Java、Go、Node.js 还是其它语言，无论是 Spring Cloud 框架还是 ServiceMesh 方式接入，可以提供微服务全生命周期管理、服务观测、配置管理、服务治理及业务容灾架构能力，帮助业务实现无代码改造迁移、快速部署、多维度治理、简化复杂运维操作等。

各种场景治理实践

在代码的开发测试阶段，我们内部有大量的产品线要测试。以某业务来举例，当时该业务在研发全流程中（开发、联调、测试、体验）混用环境，导致各个环境运行不稳定。链路长的服务经常会不可用，阻塞测试工作的开展。由于该业务业务调用链路涉及几十到上百个服务，为每个分支部署特定环境，会导致成本非常高。我们将环境信息在 Deployment 部署时候，作为 Env 参数注入到 Pod 的环境变量里面，使用 Spring Cloud Tencent 直接通过环境变量将环境信息作为标签注册到北极星服务治理中心。Spring Cloud Tencent 提供元数据透传的能力，结合北极星服务治理中心元数据路由能力，解决特性环境隔离及基线环境的共享。通过北极星服务治理中心的标签路由进行流量染色，实现用户侧无感，将多环境组件复用，从而节约环境部署资源。

在应用的发布阶段，为了考虑到业务系统版本上线的灰度平滑与用户体验。例如业务服务有 v1 和 v2 两个版本，将 80% 的流量转发到 v1，将 20% 的流量转发到 v2。我们基于北极星服务治理中心实现金丝雀、滚动发布、蓝绿发布，满足多种业务灰度场景。

金丝雀发布：对于本次发布的服务，先升级一个实例，如果没有问题，再升级剩余实例；
滚动发布：对于本次发布的服务，先升级一个 / 批实例，再分批升级剩余实例；
蓝绿发布：旧版本实例保持不变，部署好新版本实例，然后将流量切到新的版本。

在业务的运行阶段，就有更多需要考虑的场景了。比如我们的游戏类业务进行全球开服，就需要解决跨地域容灾访问，同时要兼顾性能。北极星服务治理中心支持用户为服务实例打上自定义标签、定向分配流量，支持同城或者跨城多中心部署，实现跨地域的全局服务发现和流量调度：

北极星服务治理中心支持在服务实例上添加标签，例如：地域、城市和园区用于标记地理位置；
服务路由提供配置目标服务优先级的能力，支持在某可用区或某地域目标服务发生故障后，将请求路由至次优先级的实例分组上；
客户端服务发现模块，可以根据路由规则实现就近访问与容灾切换。

另外，游戏类业务还会举行一些相关的运营活动，比如优惠券领用等，往往会导致大流量的产生。还有视频类业务，例如我们的某视频业务在遇到热点事件的时候，也会导致突发的大流量冲击问题。为了防止后段服务被各种突发流量冲垮，我们借助于云原生网关和北极星服务治理中心设置了多级流量管控策略，比如接入层服务流量限流、服务间调用限流、基于接口和标签的热点限流等，从而保障了运营活动的顺利进行。

服务限流主要是为了防止瞬时流量过大造成服务和数据崩溃，导致服务不可用。当资源成为瓶颈时，我们可以对请求做限流，启动流控保护机制。例如给某个服务设置 1000QPS 的限流阈值，超过该阈值的请求被拒绝。北极星服务治理中心限流方案采用了动态配额分配机制，根据实例的历史流量记录动态计算预测下一时刻该实例的流量，若所有实例的流量预测值都小于额定平均值（总配额 / 在线实例数），则以该平均值作为所有实例分配的配额；否则按预测流量的比例分配，且提供兜底的最小值。

在应对大流量的时候，限流固然是个办法。而分布式架构中，一个服务通常会与多个外部服务进行交互，这些外部服务可能是 RPC 接口、数据库、第三方 API 接口等。例如，查询某个商品的价格，可能需要同时调用营销活动接口查询优惠信息。当我们依赖的外部服务出现不稳定的情况时，可能会导致服务自身调用外部服务的响应时间也变长，甚者形成级联效应。这样一来，服务自身的线程可能会积压，最终耗尽业务自身的线程池，导致服务本身变得不可用。除了自身服务的稳定性外，服务所依赖的外部服务稳定性也会影响自身服务的用户体验，所以一味的限流也不能很好地应对级联效应问题。

当下游的服务因为某种原因突然变得不可用或响应过慢，为了保证整体服务的可用性，我们一般通过服务熔断让上游服务不再继续调用目标服务，而是直接返回，这样可以快速释放资源。如果目标服务情况好转则恢复调用。例如，上文说的商品查询服务，在调用营销活动服务的失败率较高时，就可以触发熔断器开关，从而避免雪崩效应。北极星服务治理中心除了支持标准的熔断器能力外，还支持打开主动探测能力，在业务请求的同时加上主动探测的请求；在没有业务请求时，也能及时的了解业务运行状态，及时的进行异常分析与预警。

在生产实践中，服务的熔断又通常与服务的降级相互配合使用。在服务发生熔断后，我们会让业务请求调用事先配置好降级逻辑的处理方法。服务降级是一种兜底的服务策略，当服务提供者故障触发调用者服务的熔断机制，服务调用者就不再调用远程服务方法，而是调用本地的 FallBack 方法，返回值也一般是设置的默认值或者来自缓存。因此在流量特别大、系统过载或资源不足等场景，建议通过降级或放弃一些非核心业务功能，有针对性地降低系统的部分功能质量，以保证核心业务和关键服务仍能继续正常运行。

事实上，要确保一个服务可用性达到 100% 是比较困难的。万一某个服务真的挂掉了，我们要尽量的减小其故障爆炸半径，将它所波及影响的范围尽可能地降到最低。在微服务治理场景中，当服务提供者的某些实例出现异常时，我们要尽量避免服务消费者访问到异常实例，同时保留异常现场，便于后续的问题排查。例如服务 1 调用服务 2，当服务 2 的实例 A 发生异常时，会导致服务 1 的部分调用失败，北极星服务治理中心可以将实例 A 隔离，同时通知服务 1。服务 1 更新访问服务 2 的列表，从而确保服务调用成功。

当应用微服务化之后，各种错综复杂的调用关系、各类故障问题也是比较头疼的事情。在后期的运维阶段，建议在事前及时的做好监控观测，事中快速定位与快速恢复业务，以及事后的复盘总结。我们将腾讯内部海量运维和诊断经验，沉淀到 TSF 微服务框架和北极星服务治理中心系统中，为微服务提供了全场景下的系统分析洞察能力，让微服务的运维更加得心应手。

服务的接入方式

为了满足用户多语言和异构环境的接入需求，北极星服务治理中心兼容了 SDK、各类框架、Java Agent、主流注册中心、Sidecar 等多种接入方式。

以 Spring Cloud 为例，只需要两步操作即可将 Spring Cloud 应用接入北极星服务治理中心。

第一步修改 pom.xml 引入依赖：

第二步修改 bootstrap.yml 添加地址依赖：

将北极星 SDK 作为插件注入到服务框架原生的扩展接口之上，从而接入北极星服务治理中心。北极星服务治理中心也支持代码无侵入的方式，非常方便业务快速接入与治理。例如通过 Java Agent 方式无需修改 pom.xml，只需要在启动 Java 程序时，加入 javaagent 的 JVM 启动参数就可以。除了 Java Agent 之外，北极星服务治理中心也支持 ServiceMesh 模式，用户程序无需做任何改动，即可实现自动往 Pod 中注入 Envoy，数据面可以直接接入北极星服务治理中心控制面实现服务发现和治理。

此外，我们还提供了公有云版本的北极星（PolarisMesh）服务、企业级的私有化 TCS 云原生 PaaS 服务、以及 TCE 企业专有云服务，由专业的腾讯云技术服务团队提供咨询对接。

以 TCS 云原生 PaaS 为例，TCS 将北极星（PolarisMesh）、TSF 微服务框架、网关、消息中间件与容器云进行整合，其向下兼容第三方异构 IaaS，对外提供全栈的企业级中间件能力，目前已在金融、政企、交通、互联网等多个行业领域落地。

企业落地案例

在前期测试环境或规模小的时候，企业往往会自建微服务治理系统。但是随着业务的发展，企业需要大量研发投入与资源损耗等。微服务领域的技术复杂，企业自建微服务中心的研发周期长、研发成本高、上线落地风险较大，也会面临着后期的部署运维、故障定位、升级维护等问题。因此，我们建议在一定的规模之后，应该基于商业化成熟的微服务套件产品进行分阶段的项目建设。例如腾讯商业化成熟的微服务治理中心，经过内外部大规模打磨，可以支持企业低成本迁移与平滑过渡，持续提供专业的技术支持兜底服务，支撑业务的稳健发展。

前不久刚刚落下帷幕的巴黎奥运会非常精彩。腾讯视频和腾讯云也是央视频的重要合作伙伴，我们为央视频提供了覆盖客户端、前台、中台和底座的数十个应用系统。央视频的业务同时在我们的专有云和公有云上，通过腾讯云北极星（PolarisMesh）很好地解决了跨混合云 Kubernetes 集群的服务注册发现与治理等问题，为观众提供更流畅的视听体验！

近年来，云原生微服务架构在金融行业的也应用非常广泛，包括银行、保险、证券等。尤其是一些国有银行、股份制银行以及城商行等都走在架构优化的前列。在金融创新业务，如手机银行、网络支付、互联网理财等方面落地云原生微服务架构。而不同的金融企业规模和发展阶段也有差异，例如某头部金融企业本身已经具备较大的规模，亟需解决跨地域的扩展与容灾问题。这家头部金融企业通过市场上各类产品的分析对比，最终选择了腾讯 TCS 云原生 PaaS 平台，集成了 TSF 微服务框架、北极星（PolarisMesh）和云原生网关等微服务套件组合，充分利用服务实例自定义标签、跨地域的全局服务发现和流量调度、接入层与应用层的多活容灾与就近访问等特性，大致方案如下：

网关单独集群部署与业务应用资源隔离，网关运行在全局命名空间，可转发流量至任意单元；
无法拆分单元的全局性服务，运行在全局命名空间，并在异地数据中心部署冷备；
业务应用基于命名空间实现逻辑隔离，组成独立可闭环业务的单元；
按组织架构，业务属性等因素将应用分配到不同的集群进行资源隔离；
每个单元分别在同城地域部署，数据库层配置强同步复制；
每个单元在异地进行灾备，数据异步复制。

通过方案的落地，很好的解决了企业异地容灾和单元化扩展问题，支撑了多种业务灰度与单元隔离场景，提高了整体的金融业务连续性。

我们再来看某跨境物流平台的案例，这家跨境物流平台是业务和服务遍布全球的国际物流 ToB SaaS 公司，主要以货代操作系统和国际物流数据服务平台作为服务底座，形成了以可视化、电子单证发送、SaaS 货代操作系统、跨境业务系统、获客和 IM 工具为主的 SaaS 产品矩阵，并提供在线报关、线上代订舱（E-BOOKING）等公共物流服务。随着更多新的产品发布，及其产品之间的依赖越来越多，在微服务治理上也面临着很大的挑战。通过引入腾讯云北极星（PolarisMesh）解决版本管理、灰度、弹性、流量控制、配置管理、故障容错、服务发现、服务治理等一系列问题，整体微服务运维成本降低 80% 以上。

另外一个案例是互联网行业的，某 AI 教育平台通过引入腾讯云北极星（PolarisMesh）、TSE 云原生网关等产品，解决了用户南北向流量管控和东西向服务注册发现与治理等问题。其中比较值得一提的是新老业务平滑迁移方面，当时平台有上万个在线服务节点，都是基于开源的 Eureka 实现服务发现。一方面新版的 Eureka 也已经闭源，后期的演进存疑；而另一方面由于架构的局限，Eureka 难以实现快速扩展，在上万个服务节点注册和上报心跳的情况下，经常出现高负载，导致服务节点状态异常，续约请求处理不过来导致实例被异常下线，影响业务正常调用。

腾讯云北极星（PolarisMesh）采用计算存储分离架构，可随着接入节点的增加水平扩展，轻松支持百万级节点。同时，腾讯云北极星（PolarisMesh）对 Eureka 接口进行了全兼容，用户业务可以把腾讯云北极星（PolarisMesh）集群作为一个 Eureka 节点，加入到原来的 Eureka 集群中，基于 Eureka 原生同步协议进行新老注册中心的服务数据双向同步。新的应用只需要修改一下注册中心地址，即可实现迁移，无需任何代码修改。业务可以按自己的节奏将服务从 Eureka 注册中心迁移到北极星，中途发现问题可随时回滚。

基于这个方案，用户实现了业务不停机的情况下，将服务注册中心无缝迁移至腾讯云北极星（PolarisMesh）。并发注册服务数与吞吐量得到了 10 倍的提升，并解决了业务规模激增场景下开源注册中心可靠性问题，有效避免线上再次故障。借助于腾讯云北极星（PolarisMesh）的存算分离特性，方便高效的快速扩展，很好地支撑了在线业务的快速发展。

关于开源

北极星（PolarisMesh）是在满足腾讯业务需求的过程中，不断演进和发展起来的，经过了内部大规模服务治理经验积累，以及外部各类企业级场景的沉淀。本着回馈社区与开源精神，我们也将内部好的产品逐步面向外界开源与输出，目前北极星（PolarisMesh）已正式对外开源。建设以微服务为核心的开源生态，希望能帮助业界更好地进行云原生微服务架构的转型。