【云原生】腾讯带着北极星（spring-cloud-tencent）也来卷云原生了，一起瞅瞅吧

北极星是腾讯开源的服务发现和治理中心，致力于解决分布式或者微服务架构中的服务可见、故障容错、流量控制和安全问题。虽然，业界已经有些组件可以解决其中一部分问题，但是缺少一个标准的、多语言的、框架无关的实现。 北极星在腾讯内部的服务注册数量超过百万，日接口调用量超过十万亿，通用性和稳定性都得到了大规模的验证。Spring Cloud Tencent 于6月14日正式对外开源，作为腾讯开源的一站式微服务框架，Spring Cloud Tencent 实现了 Spring Cloud 标准微服务 SPI ，开发者可以基于 Spring Cloud Tencent 快速开发 Spring Cloud 微服务架构应用。Spring Cloud Tencent 的核心依托腾讯开源的一站式服务发现与治理平台 Polarismesh ，实现各种分布式微服务场景。

北极星具备哪些功能

在这里插入图片描述

Spring Cloud Tencent有哪些功能

在分布式微服务领域，2016 年 1 月 Spring Cloud 发布 Angel.SR5 版本。Spring Cloud 延承了 Spring Boot 最核心的组件化、低配置快速集成的核心思想，同时定义了一套标准的微服务 SPI。基于这套 SPI 出现了 Spring Cloud Netfix 等优秀的微服务解决方案实现套件。在远程服务调用框架方面，Feign 和 RestTemplate 基于普适的 HTTP 协议，在易用性、可观测性、跨语言等方面具备天然的优势。2018 年开始以 Istio 为代表的 ServiceMesh 开始在社区中孵化，到 2022 年已经有非常多的 ServiceMesh 产品。ServiceMesh 核心思想是下沉服务调用相关的基础能力到独立的 Sidecar 进程，通过流量代理的方式治理流量。任何一种方案都不是万能药， Sidecar 模式也存在一些问题。例如：高度依赖底层 Paas 能力治理 Sidecar （注入、版本管理、升级等）、Sidecar 需要额外占用一定的资源、增加一定的网络延迟、增加排障难度等。所以国内真正能够落地 ServiceMesh 的企业并不多。 综上所述，我们认为在未来很长一段时间内 Spring Boot + Spring Cloud 仍是 Java 主流的微服务解决方案，虽然它看上去没有像 Istio、Dapr 那样的先进。在满足企业业务发展诉求的前提下，低成本、高效、稳定的架构方案才是最好的方案。 北极星作为 Spring Cloud 一个开箱即用的实现套件，既能满足 Spring Cloud 的用户，又能满足北极星 Java 的用户。Spring Cloud Tencent 目前只对接了北极星的能力，后续会支持更多腾讯开源的优秀产品。 Spring Cloud Tencent 主要提供了微服务领域常见的服务注册与发现、配置中心、服务路由、限流熔断以及元数据链路透传能力。

在这里插入图片描述

服务注册与发现 (Spring Cloud Tencent Polaris Discovery)

服务注册与发现是 Spring Cloud Tencent 最为核心的功能之一，通过实现 Spring Cloud 的服务注册与发现的标准接口，提供微服务应用快速接入北极星服务注册中心的能力。开发者通过简单的引入 Spring Cloud Tencent 服务注册与发现的依赖，即可使用北极星的服务注册与发现功能。接入服务注册与发现之后，还能按需使用北极星提供的强大服务治理能力，例如场景化的服务路由能力、服务熔断能力等。方便开发者针对微服务的实际生产场景作出个性化的服务治理配置。 北极星的服务模型包括命名空间、服务和服务实例。 命名空间：命名空间提供了一种在同一个注册中心下资源的逻辑隔离的机制，同一命名空间下的服务命名必须唯一，但是跨命名空间允许存在同名的服务。命名空间常用于区分不同的环境或者多个业务之间的服务隔离。 服务：服务也是逻辑的概念，提供一个特定业务领域的服务能力。例如订单服务，用户服务，转账服务等。 服务实例：服务实例是服务下的一个具体的物理节点

在这里插入图片描述

（图：服务实例详情） Spring Cloud Tencent 在基础的服务注册发现上，提供了一些拓展能力。首先，Spring Cloud Tencent 集成了北极星的一些路由插件，通过在北极星控制台页面更改服务实例的隔离状态或者权重值，都可以实现服务实例的动态上下线的特性，如上图所示。 Spring Cloud Tencent 还提供了多服务注册与发现的进阶功能。举个例子，公司内部多个部门或组织使用了不同的服务注册中心，当决策技术栈统一或是迁移到北极星注册中心时，需要使用平滑的方式进行业务改造，而非直接替换原有的 SDK 接入北极星注册中心。此时可以使用 Spring Cloud Tencent 的多服务注册与发现的能力，帮助开发者的微服务应用过渡技术栈转换的尴尬期。 Spring Cloud Tencent 提供的这样一系列针对服务注册与发现的周边功能，完善了微服务架构的治理与管控能力。

配置中心 (Spring Cloud Tencent Polaris Config)

今年上半年北极星开始支持配置中心的能力。北极星配置中心核心配置三元组模型为： Namespace：用于逻辑隔离集群的能力，例如常用于隔离环境（dev、test、prod等）。 FileGroup：配置文件组，一组配置文件的集合。在 Spring Cloud Tencent 里，我们推荐的最佳实践是一个应用为一个 FileGroup。对于框架类的配置，以框架名作为一个 FileGroup， 例如 dubbo。 File：配置文件，例如 properties 、yml 格式的配置文件。配置文件为最小管理单元，而不是配置文件里的配置项。 [Namespace, FileGroup, File] 唯一定位一份配置文件。我们在设计模型的时候，参考了业界主流的配置中心产品，我们认为配置文件、配置文件组的概念，是开发者广泛认知且理解成本最低的配置领域模型，例如本地磁盘的文件夹和文件的概念。 配置中心核心能力是配置管理能力以及动态实时推送能力。在配置管理方面，一个应用往往具有非常多的配置文件，如何清晰的管理配置文件是一个非常重要的能力。我们在管控台设计 UI 时，开创性的把文件名以 / 作为分隔符树状形式展示。如下图所示，可以按应用模块划分目录，通过目录方式能够清晰管理一个应用下杂乱的配置文件。

在这里插入图片描述

（图：配置文件管理页面）

另外在 Spring Cloud 集成方面，众所周知 Spring Boot 会自动加载应用 resources 目录下的 application.yml、application.properties 以及优先级更高的 application-

{activeProfile}.yml 文件到 Spring 容器里。用户在做迁移时，只需把 resources 目录下所有的配置文件原封不动的上传到北极星即可。

服务路由 (Spring Cloud Tencent Polaris Router)

在微服务领域，由于服务做了细粒度的拆分部署服务变的非常的轻量灵活。在结合 k8s 云原生极速弹性能力之后变的更加的强大。但是底层的 Paas 能力只是提供了基础弹性能力，真正发挥能力需要依赖上层的流量调配的能力。 放眼 Spring Cloud 生态，能够深度整合 Spring Cloud 提供场景化服务路由能力的组件套件并不多。这里解释一下场景化，服务调用框架根据一定的规则实现服务路由的能力我们称之为底层原子能力。原子能力是非常通用的能力，但是很多时候并不能直接用于具体的业务场景。例如常见的测试环境分组，就近路由，蓝绿发布等称之为场景。服务路由只有做了场景化之后，才能真正做到开箱即用服务于业务。 Spring Cloud Tencent Polaris Router 目前实现了两种场景化的路由能力以及一种非常灵活的规则路由的能力。

元数据路由

服务实例都会附属一组元数据，例如环境信息，机房信息等等。元数据路由简单的讲就是以元数据信息作为路由的依据进来路由。这样讲还是有些抽象，我们以一个测试环境例子来解释一下。

在这里插入图片描述

（图：开发环境示意图） 上图是非常经典的用于解决测试环境冲突的方案。一次迭代中 SvcA 需要和 SvcD 联调，当团队人数少的时候，可以直接把 stable 环境部署成开发分支代码然后进行联调。但是当多个开发任务并行的情况下就会出现环境争抢的情况。一种解决方式是每个开发任务独立部署一套全链路的环境，这种方式耗时耗力效果还很差。业界最主流的做法就是上图所示，每个开发任务子环境只需要部署联调的应用即可，链路上不在子环境里的服务都路由回 stable 稳定环境。 使用 Spring Cloud Tencent 为了达到以上的目的，只需要每个服务部署的时候，增加以下两个环境变量即可实现。

• SCT_METADATA_CONTENT_ENV=dev1
• SCT_METADATA_CONTENT_TRANSITIVE=ENV

Spring Cloud Tencent Polaris Router 组件会自动读取以上环境变量，并在每次服务调用时优先调用到跟当前实例 ENV 值一样的目标实例。 元数据路由使用的场景非常广泛，更多的细节请查阅 Github Wiki。

规则路由

元数据路由本质上是基于服务实例的元数据进行筛选，是为了支持具体特定的场景而内置的服务路由能力。无需下发任何路由规则，使用起来非常简单。 而实际业务场景非常复杂，例如以下几种典型的业务场景：

• 内部员工路由到一套生产灰度环境，外部普通用户则路由到生产正式环境
• VIP 客户路由到一套高保环境，普通客户路由到普通环境

以上两种业务场景，则无法通过元数据路由实现。因为涉及到业务请求参数，而不是系统维度的环境变量。规则路由就是用于满足复杂业务场景而实现的一套基于规则的服务路由实现。 一个典型的规则如下图所示：

在这里插入图片描述

（图：路由规则配置页面） 上图表达的含义是：HTTP Query Param 的 uid 参数值为 100 时，调用到 ENV=gray 的实例分组。通过路由规则能够描述出绝大多数复杂的业务场景。 为了便于使用， Spring Cloud Tencent 内置了一套表达式标签规则，自动从 HTTP 请求中解析标签值。目前支持的表达式规则有：

• ${http.query.xxx}
• ${http.header.xxx}
• ${http.cookie.xxx}
• ${http.method}
• ${http.uri}

规则路由相对比较复杂，更多的细节请查阅 Github Wiki。

就近路由

生产环境服务为了高可用、容灾等能力往往需要多机柜、多机房、多地域部署。

在这里插入图片描述

（图：部署模型图） 如上图所示，范围从小到大依次为: Campus < Zone < Region < All其中 Campus、Zone、Region 在服务注册发现领域模型里统一定义为元数据，是一种特殊的位置元数据（Location Metadata）。 就近路由顾名思义，服务调用时按照同 Campus、同 Zone、同 Region 的优先级从高到低依次选取目标服务实例。核心是减少服务调用因物理距离增加的网络耗时。本质上，就近路由是一种基于特定一组位置元数据的元数据路由。 通过 Spring Cloud Tencent 实现就近路由，只需要在服务实例上打上以下环境变量即可。

• SCT_METADATA_CAMPUS
• SCT_METADATA_ZONE
• SCT_METADATA_REGION

服务限流（Spring Cloud Tencent Polaris Ratelimit）

随着业务发展的日益壮大，网络请求量也越来越多，导致在某些场景下，业务应用的服务端会出现爆发式的流量涌入，因此需要对服务提供方的给予一些保护手段。通过服务限流功能，开发者可以通过控制 QPS 的方式，以避免被瞬时的流量高峰冲垮，从而保障系统的高可用性。服务限流主要有两个应用场景，过载保护和业务防刷。过载保护是保护业务不被突发流量打垮，业务防刷是防止恶意用户发送过多流量影响其他正常用户。Spring Cloud Tencent 内置了针对 Spring Web 和 Spring WebFlux 场景的限流 Filter 帮助业务快速接入北极星的限流能力。 Spring Cloud Tencent 支持北极星提供的两种类型的服务限流能力，即单机限流与分布式限流。

单机限流

单机限流是针对单个被调实例的级别的限流，流量限额只针对当前被调实例生效，不共享，如下图所示。单机限流一般适用于保护服务自身不被打垮，按照每个服务集群单机的容量来计算配额。

在这里插入图片描述

（图：单机限流示例图） 单机限流的效果分为快速失败和匀速排队。快速失败指的是当 QPS 到达限流规则指定的配额时，立刻返回一个限流类型错误响应给所有超过阈值的请求。而匀速排队是一种基于漏桶算法实现的削峰填谷限流方式，帮助服务端能够在流量洪峰到达时，还能保证一个匀速处理的状态，让一部分请求在一段排队等待时间后还能被处理，而不是直接失败。关于匀速排队的详细介绍可以参考 Github 官方 Wiki。

分布式限流

分布式限流是针对服务下所有实例级别的限流，多个服务实例共享同一个全局流量限额，如下图所示。分布式限流一般适用于保护第三方服务或者公共服务（比如保护数据库）；或者是在网关层进行限流，对通过网关接入的后端服务进行保护。

在这里插入图片描述

（图：分布式限流示例图） Spring Cloud Tencent 提供了自定义限流规则能力，开发者可以根据自身的业务场景定制对应的限流规则。

在这里插入图片描述

（图：限流规则配置界面）

服务熔断（Spring Cloud Tencent Polaris Circuitbreaker）

在微服务架构的运维场景下，有时候会遇到单点服务实例故障的情况，如果不能及时剔除，那么仍旧会有请求转发到故障的服务实例上。Spring Cloud Tencent 提供了服务熔断的能力，通过上报每次服务间调用的结果，判断被调方服务是否出现故障，进而将其屏蔽，并启动定时任务对熔断实例进行探活。在达到恢复条件后对其进行半开恢复。在半开恢复后，释放少量请求去进行真实业务请求探测。并根据真实业务探测结果去判断是否完全恢复。这个功能能有效剔除异常的服务实例，为服务治理提供了重要的帮助。

官方计划完善的内容

在这里插入图片描述

官方提供的体验环境

• 管控台地址： http://14.116.241.63:8080/
  • 账号：polaris
  • 密码：polaris
• 控制面地址： grpc://183.47.111.80:8091
• spring-cloud-tencent-example 下 example 地址都默认指向了体验服务地址（grpc://183.47.111.80:8091），如果您只是体验 Spring Cloud Tencent，可直接一键运行任何 example。

📌PS：Sidecar 是什么？ 将本属于应用程序的功能拆分成单独的进程，这个进程可以被理解为Sidecar。在微服务体系内，将集成在应用内的微服务功能剥离到了Sidecar内，Sidecar提供了微服务发现、注册，服务调用，应用认证，限速等功能。Sidecar降低应用程序代码和底层代码的耦合度，帮助异构服务通过Sidecar快速接入微服务体系。简单的可以把Sidecar理解成代理服务。

参考： https://github.com/Tencent/spring-cloud-tencent https://polarismesh.cn/ https://github.com/polarismesh/polaris

本文内容到此结束了， 如有收获欢迎点赞👍收藏💖关注✔️，您的鼓励是我最大的动力。 如有错误❌疑问💬欢迎各位大佬指出。 主页：共饮一杯无的博客汇总👨‍💻 保持热爱，奔赴下一场山海。🏃🏃🏃

在这里插入图片描述