共计 6715 个字符，预计需要花费 17 分钟才能阅读完成。
一、为什么要做 Spring Cloud Tencent
Spring Boot + Spring Cloud 仍是 Java 生态最支流的框架
2014 年 4 月 Spring Boot 公布 1.0 版本，通过 8 年工夫的倒退，Spring Boot 未然成为 Java 开发框架的事实标准。在散布式微服务畛域，2016 年 1 月 Spring Cloud 公布 Angel.SR5 版本。Spring Cloud 延承了 Spring Boot 最外围的组件化、低配置疾速集成的核心思想，同时定义了一套规范的微服务 SPI。基于这套 SPI 呈现了 Spring Cloud Netfix 等优良的微服务解决方案实现套件。在近程服务调用框架方面，Feign 和 RestTemplate 基于普适的 HTTP 协定，在易用性、可观测性、跨语言等方面具备人造的劣势。所以 Spring Cloud 自 2016 年公布第一个版本之后蓬勃发展。
从行业状况看，Spring Boot + Spring Cloud 是目前 Java 应用最宽泛的开发框架之一。
2018 年开始以 Istio 为代表的 ServiceMesh 开始在社区中孵化，到 2022 年曾经有十分多的 ServiceMesh 产品。ServiceMesh 核心思想是下沉服务调用相干的根底能力到独立的 Sidecar 过程，通过流量代理的形式治理流量。任何一种计划都不是万能药，Sidecar 模式也存在一些问题。例如：高度依赖底层 Paas 能力治理 Sidecar（注入、版本治理、降级等）、Sidecar 须要额定占用肯定的资源、减少肯定的网络提早、减少排障难度等。所以国内真正可能落地 ServiceMesh 的企业并不多。
综上所述，咱们认为在将来很长一段时间内 Spring Boot + Spring Cloud 仍是 Java 支流的微服务解决方案，尽管它看上去没有像 Istio、Dapr 那样的先进。在满足企业业务倒退诉求的前提下，低成本、高效、稳固的架构计划才是最好的计划。
腾讯 2021 年开源的北极星（PolarisMesh）提供了一站式微服务解决方案
北极星是一款集注册核心、配置核心、服务治理核心为一体的一站式微服务解决方案，在腾讯外部已笼罩 90% 的业务，注册的实例节点数更是达到了 500 万的规模。在 21 年开源之后，在社区内也有内部公司生产落地。
公司外部的架构师常常会做一些技术选型，比方注册核心用 Zookeeper、Consul、Nacos 等，配置核心用 Apollo、Nacos，限流熔断用 Sentinel。多组件也意味着须要保护多套服务，占用更多的资源，用户体验上也难以做到一致性。
所以一站式微服务解决方案可能大大简化技术选型、运维、资源老本。当然也能够把北极星当做计划里的一部分，例如只用北极星的服务注册发现，配置核心依然选型 Apollo。毕竟还是那个情理，没有万能的计划，适宜企业业务本身诉求的计划才是最好的计划。
另外北极星在某些能力横向比照上也有肯定的劣势。例如齐全无状态的注册核心更加便于运维，弱小的服务路由能力反对简单的业务场景等。具体的产品性能在第二局部会更加具体的介绍。
小结
基于以上两点外围起因，把北极星作为 Spring Cloud 一个开箱即用的实现套件就牵强附会了。既能满足 Spring Cloud 的用户，又能满足北极星 Java 的用户。当然 Spring Cloud Tencent 目前只对接了北极星的能力，后续会反对更多腾讯开源的优良产品。
二、Spring Cloud Tencent 模块具体介绍
目前 Spring Cloud Tencent 次要提供了微服务畛域常见的服务注册与发现、配置核心、服务路由、限流熔断以及元数据链路透传能力。接下去会具体介绍每一部分的能力。
（图：Spring Cloud Tencent 能力大图）
2.1 服务注册与发现 (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 提供的这样一系列针对服务注册与发现的周边性能，欠缺了微服务架构的治理与管控能力。
2.2 配置核心 (Spring Cloud Tencent Polaris Config)
往年上半年北极星开始反对配置核心的能力。北极星配置核心外围配置三元组模型为：
Namespace
用于逻辑隔离集群的能力，例如罕用于隔离环境。
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 Cloud Tencent Polaris Config 集成时，咱们齐全沿用了这套原生的配置加载机制。也就是 Spring Cloud Tencent Polaris Config 在启动时，会主动加载利用文件组下的 application.yml 和 application-${activeProfile}.yml 文件到 Spring 容器里。用户在做迁徙时，只需把 resources 目录下所有的配置文件一成不变的上传到北极星即可。
2.3 服务路由 (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
2.4 服务限流（Spring Cloud Tencent Polaris Ratelimit）
随着业务倒退的日益壮大，网络申请量也越来越多，导致在某些场景下，业务利用的服务端会呈现爆发式的流量涌入，因而须要对服务提供方的给予一些爱护伎俩。通过服务限流性能，开发者能够通过管制 QPS 的形式，以防止被刹时的流量顶峰冲垮，从而保障系统的高可用性。服务限流次要有两个利用场景，过载爱护和业务防刷。过载爱护是爱护业务不被突发流量打垮，业务防刷是避免歹意用户发送过多流量影响其余失常用户。Spring Cloud Tencent 内置了针对 Spring Web 和 Spring WebFlux 场景的限流 Filter 帮忙业务疾速接入北极星的限流能力。
Spring Cloud Tencent 反对北极星提供的两种类型的服务限流能力，即单机限流与分布式限流。
单机限流
单机限流是针对单个被调实例的级别的限流，流量限额只针对以后被调实例失效，不共享，如下图所示。单机限流个别实用于爱护服务本身不被打垮，依照每个服务集群单机的容量来计算配额。
（图：单机限流示例图）
单机限流的成果分为 疾速失败 和匀速排队。疾速失败指的是当 QPS 达到限流规定指定的配额时，立即返回一个限流类型谬误响应给所有超过阈值的申请。而匀速排队是一种基于漏桶算法实现的削峰填谷限流形式，帮忙服务端可能在流量洪峰达到时，还能保障一个匀速解决的状态，让一部分申请在一段排队等待时间后还能被解决，而不是间接失败。对于匀速排队的具体介绍能够参考 Github 官网 Wiki。
分布式限流
分布式限流是针对服务下所有实例级别的限流，多个服务实例共享同一个全局流量限额，如下图所示。分布式限流个别实用于爱护第三方服务或者公共服务（比方爱护数据库）；或者是在网关层进行限流，对通过网关接入的后端服务进行爱护。
（图：分布式限流示例图）
Spring Cloud Tencent 提供了自定义限流规定能力，开发者能够依据本身的业务场景定制对应的限流规定。
（图：限流规定配置界面）
2.5 服务熔断（Spring Cloud Tencent Polaris Circuitbreaker）
在微服务架构的运维场景下，有时候会遇到单点服务实例故障的状况，如果不能及时剔除，那么仍旧会有申请转发到故障的服务实例上。Spring Cloud Tencent 提供了服务熔断的能力，通过上报每次服务间调用的后果，判断被调方服务是否呈现故障，进而将其屏蔽，并启动定时工作对熔断实例进行探活。在达到复原条件后对其进行半开复原。在半开复原后，开释大量申请去进行实在业务申请探测。并依据实在业务探测后果去判断是否完全恢复。这个性能能无效剔除异样的服务实例，为服务治理提供了重要的帮忙。
小结
以上只是简略介绍了 Spring Cloud Tencent 局部能力，想具体理解更多的能力请拜访咱们 Github 官方主页。
三、布局和愿景
文章结尾提到咱们为什么要做 Spring Cloud Tencent。咱们深信在 Java 畛域 Spring Cloud 在很长一段时间内仍是微服务的支流计划。咱们心愿联合北极星一站式微服务能力，升高微服务架构门槛，为宽广企业提供开箱即用的全套微服务解决方案。从而使企业更加聚焦本身业务的倒退，进步生产力。
一款好用的产品须要禁受丰盛的场景打磨稳定性、易用性，以及不断完善本身的产品力。以下是咱们目前想到的一些须要反对和欠缺的点。当然随着产品的倒退、应用的用户越来越多，会有更多的诉求，咱们会继续一直的迭代上来。
四、期待你的退出
- 如果你也是 Spring Cloud 的爱好者
- 如果你的公司正在应用 Spring Cloud 并且有一些好的实际
- 如果你的公司正在做微服务技术选型
- … …
请退出咱们，你的一个倡议、Issue、Pull Request 甚至只是一个小小的 Star 都是对咱们最大的反对，也是咱们继续迭代的能源。
Spring Cloud Tencent Github 地址：https://github.com/Tencent/sp…