NextArch 基金会旗下微服务标准化方案已开源:支持不同开发语言和技术框架

本文涉及的产品
任务调度 XXL-JOB 版免费试用,400 元额度,开发版规格
云原生网关 MSE Higress,422元/月
注册配置 MSE Nacos/ZooKeeper,118元/月
简介: 今年,腾讯、字节跳动、快手、BIGO、好未来、七牛云、中国移动、蓝色光标等多达 10 家企业和 go-zero/CloudWeGo/GoFrame/TARS 开源社区的技术专家,在 Linux 下一代架构基金会下成立了微服务技术组 SIG(Special Interest Group),共同探讨微服务治理标准化的解决方案,并向 NextArch 基金会提交了首个落地方案。

今年,腾讯、字节跳动、快手、BIGO、好未来、七牛云、中国移动、蓝色光标等多达 10 家企业和 go-zero/CloudWeGo/GoFrame/TARS 开源社区的技术专家,在 Linux 下一代架构基金会下成立了微服务技术组 SIG(Special Interest Group),共同探讨微服务治理标准化的解决方案,并向 NextArch 基金会提交了首个落地方案。

微服务技术发展至今,业界涌现出了一大批微服务开发框架,比如 PolarisMesh、TARS、go-zero、GoFrame、CloudWeGo 和 Spring Cloud Tencent ,技术和实践的多样化是不可避免的,但是微服务架构里面所涉及的服务治理体系却可以做到统一和规范化。SIG 旨在提供统一服务治理体系,解决共性问题,将促进微服务框架和技术的进一步演进和发展。InfoQ 采访了部分专家,以了解项目背景、进展和规划。

嘉宾简介:

王洪智:腾讯云微服务产品技术总监,微服务引擎 TSE、开源项目 PolarisMesh 负责人。在腾讯长期从事云原生中间件的研发工作,先后负责过注册配置中心、服务治理框架和 Serverless 应用平台等多个项目。

单家骏:腾讯技术专家,PolarisMesh 社区联合发起人,具备 10 年以上中间件研发经验,目前在腾讯负责微服务引擎 TSE 研发工作,以及北极星开源社区项目的技术规划、代码开发和社区运营等工作。曾是 Qcon、掘金开发者大会、CIF 研发效能大会的分享讲师。

张乐:腾讯云技术专家,开源项目 Spring Cloud Tencent 负责人,配置中心 Apollo PMC。长期从事微服务中间件研发工作,目前在腾讯负责微服务引擎 TSE 的研发工作。

微服务治理标准化,需要解决什么问题

微服务和业务紧密相关,很多互联网企业无论大小都会在实际落地时结合当前业务场景、技术沉淀来打造自己的框架。同时,微服务又离不开配套的微服务治理,如治理平台、监控、链路跟踪、注册发现、配置中心、服务网格等。这些服务治理体系经过了一个三阶段的演进历程:

第一阶段是在 2014 年之前,是微服务和服务治理萌芽期,在这个阶段,移动互联网应用呈现了爆发式增长,为了处理海量的用户请求,大型互联网企业开始采用分布式架构。业务系统按照业务域拆分为多个高内聚的分布式模块,不同的模块之间通过 RPC 方式进行通信,从而提升系统的并发量和可扩展性。开发者需要额外解决流量调度、故障容错、异常分析等由于引入分布式架构带来的问题,这些问题都属于服务治理的范畴。

第二阶段是 2014 到 2016 年,在这个阶段业界正式提出微服务的概念,开始涌现出一批优秀的微服务框架,例如广为人知 Pivotal 开源的 Spring Cloud 框架。Spring Cloud 框架为 Java 微服务开发者提供服务发现、负载均衡、熔断降级和调用链跟踪等一站式开箱即用的服务治理能力。随着 Spring Cloud 框架的普及,开发者对服务治理的概念和作用有了初步的认识。

第三阶段是 2017 年至今,微服务和服务治理爆发期。基于微服务框架的服务治理体系持续发展,微服务也开始往多语言、多技术栈、异构基础设施的方向发展。基于此背景下,腾讯开源了支持多语言的微服务框架 TARS,阿里也宣布重新维护 Dubbo 开发框架。但是当前服务治理体系都是围绕某个开发框架构建,服务治理功能高度耦合在开发框架中,不同开发框架对服务治理的理解和实现都不一致。以 Istio 为代表的服务网格提出采用流量代理的方式,解决不同开发框架的统一服务治理问题。这种方式本质上就是把服务治理从服务框架中剥离出来,这样就能够做到统一的服务治理。不得不说,Istio 提供了一种很好的思路来解决多服务框架带来的异构问题。但是 Istio 这种流量代理的方式带来了额外性能和资源损耗,增加了业务架构和运维的复杂性。

从上述阶段的历程可以看出,服务框架发展得已经相对成熟,但也还存在一些多样性的问题。大型企业在实际实践中通常存在多种开发语言和框架,一个复杂业务系统可以使用不同的技术栈开发,例如:腾讯的开发语言以 Go 和 C++ 为主,Java、Nodejs、Python 等其他语言也有不少业务使用,还存在 tRPC、TARS 和 SPP 等几种开发框架。同时,企业的基础设施的演进是渐进式的,往往在很长一段时间会同时出现两种或者多种基础设施并存的情况(比如容器和虚拟机共存),这里涉及的场景就包含跨虚拟机和容器、跨应用部署平台和混合云等多种场景。

因此,微服务治理标准化需要解决以下两个问题:

支持多种语言和框架:如果业务开发采用 Proxyless 模式,标准化实现需要提供不同语言的标准化的服务治理 SDK,服务治理 SDK 不和开发框架绑定,方便不同的开发框架集成。如果业务开发采用 Proxy 模式,除了更加轻量级的服务治理 SDK,还需要支持不同通信协议的流量代理。

支持异构基础设施:微服务治理标准化的模型不与具体的部署架构、网络及存储架构绑定,实现上不绑定具体的基础设施,支持容器、虚拟机、多云等场景下都可以无缝对接并互通。

业界微服务治理实践经验

目前,业界的服务治理分为微服务框架和服务网格两种类型的方案,这两种类型的方案也称为 Proxyless 和 Proxy 服务治理模式。

虽然服务治理涉及的功能非常多,但是单个功能的实现并不是特别复杂。难点在于服务治理功能的完整性和灵活性,使能够同时满足应用场景、研发模式和基础设施的多样性诉求。目前,不同的微服务框架和服务网格对服务治理功能的理解和实现不一致,没有形成统一的标准和最佳实践,这个是非常大的痛点。开发者需要在自身基础设施的基础上,选择适当的工具,才可以解决微服务落地过程中的各种问题。

但 Proxyless 和 Proxy 两种治理模式是可以共存于同一个系统的。

腾讯于 2019 年发起了北极星项目,面向多语言、多框架和异构基础设施,提供统一的服务发现和治理组件。经过几年的发展,在公司内部覆盖了 90% 的业务部门,基本上形成统一。北极星可以同时支持 Proxyless 和 Proxy 两种服务治理模式。

Proxyless 模式:北极星的 Proxyless 服务治理模式和业界有很大的区别,北极星的 Porxyless 服务治理实现和开发框架解耦,采用独立的轻量级的多语言 SDK 实现,SDK 提供了一批标准化的服务治理接口。公司内部不同的开发框架基于标准化服务治理接口快速集成,从而达到不同的开发框架具备语义相同的服务治理能力。

Proxy 模式:北极星的 Proxy 服务治理模式主要是和社区主流的 ServiceMesh 数据面集成,例如 Istio 的 Envoy 数据面。

Proxyless 和 Proxy 模式可以采用统一的服务治理平面。这也是标准化服务治理的好处。腾讯内部绝大部分的业务采用 Proxyless 模式,因为 Proxyless 模式具备更高的性能,没有额外的资源消耗,对业务的流量没有侵入性,不需要运维 Sidecar。同时,北极星的 SDK 集成在开发框架中,业务开发不需要直接使用北极星的 SDK,对终端开发者透明。

SIG 项目的使命和愿景

当前社区的多个开源框架和组件都提供服务治理的能力:

CloudWeGo:提供 RPC 框架 Kitex,在框架之上提供可扩展的服务治理能力, 可以快速搭建一套完善的微服务体系。

go-zero:提供 RPC 框架 zRPC,内建级联超时控制、限流、自适应熔断、自适应降载等微服务治理能力,无需配置和额外代码即可使用。

GoFrame:提供模块化、高性能的企业级应用开发框架,在服务治理上通过扩展的能力提供服务注册发现、配置管理等能力。

PolarisMesh:提供可视化控制面和数据面,提供框架无关、平台无关的服务发现和治理能力,满足多技术栈、异步基础设施的服务治理诉求。

Spring Cloud Tencent:基于 Spring Cloud 框架,提供高度的可扩展性,与社区成熟的开源组件结合,便于 Spring Cloud 技术栈的用户快速构建微服务应用。

多个框架和组件的服务治理语义不仅相同,因此假如一个企业使用了多个框架和组件进行引用开发,则存在互通性的问题。而且目前又没有开箱即用的解决方案,大家必须在不同的基础设施和适当的工具之间做出抉择。SIG 微服务技术组的成立,就是致力解决这些问题。

王洪智认为,现在推动服务治理规范建设是一个比较好的时间点,主要有以下两个方面的考虑:

首先,微服务和服务治理概念已经普及。随着各行各业开始数字化转型,越来越多企业开始采用微服务架构,经历了微服务框架的大规模使用以及服务网格的推广,企业和开发者对服务治理已经有了比较深入的了解。

其次,不同的微服务框架和服务网格对服务治理功能的理解不一致,但在完善度和易用性参差不齐。而且服务框架开发者聚焦于服务治理的底层技术功能的重复建设,缺少面向真实业务场景的最佳实践,用户可能无法将某个功能和生产实践中遇到的问题对应起来。不利于微服务技术的进一步发展。

业内 PolarisMesh/polaris、go-zero、CloudWeGo/Kitex 等开源框架已经实现了服务治理的部分功能,SIG 微服务技术组在这个基础之上,希望构建一个标准化的微服务解决方案,建立统一的语义,为企业提供多框架、多语言服务的统一管理。

标准化方案现状及后续计划

服务治理标准化的解决方案包含两个部分,一部分是服务治理的标准化功能定义和最佳实践,一部分是服务治理面和数据面的标准化协议和接口。

image.png

一方面,标准化项目会提供实现。标准化实现包含三个部分:

第一部分是服务治理控制平面:治理平面面向用户,通过提供可视化界面支持服务治理功能的管控(包括规则的编辑、治理效果的监控等),并下发规则到数据平面。

第二部分是数据平面:数据平面主要面向框架或应用,提供 API 接口进行功能的暴露。过程中会接受治理平面下发的规则进行,并执行具体的服务治理逻辑处理。

第三部分是开发框架:数据平面可以单独使用,更常见的是集成在开发框架中,通过扩展开发框架的拦截器或接口,实现标准化实现与框架的集成。

北极星(PolarisMesh)会在现有的基础上支持服务治理标准化控制面和数据面,go-zero、GoFrame、CloudWeGo 和 Spring Cloud Tencent 等多个开源社区也会提供标准化开发框架实现,为各个社区的用户提供开箱即用的实现。这些开源项目都经过了企业内外部用户的验证,在性能和稳定性上都有保障,可以加速标准化的落地。

另一方面,标准化解决方案分为以下几个部分:

标准化 Spec 建设:各个企业和社区在下一代架构基金会微服务技术组的组织下,融合当前的服务治理实践经验,共同制定服务治理标准化规范,通过文档及协议的方式对用户呈现。

控制面支持:当前 PolarisMesh(北极星)已经提供了可视化的服务治理控制台及可观测性能力,计划会接入中立的服务治理 Spec 的语义,将规则通过标准协议接口暴露出去,便于数据面及社区开发框架进行统一接入。

数据面支持:如前所述,当前 PolarisMesh(北极星)已支持 proxyless 和 proxy 的数据面接入方式,提供了多语言的 SDK,高性能无侵入的 Sidecar,以及基于字节码机制的 Java Agent,计划会接入中立的服务治理 Spec 的语义,通过统一的治理语义对接社区标准的控制面。

开发框架支持:开发框架保持自身服务治理能力的基础上,对标准化 Spec 进行实现,从而增强自身服务治理能力,实现互联互通的目标。计划会通过以下开发框架进行对标准化 Spec 进行支持:

go-zero:内建级联超时控制、限流、自适应熔断、自适应降载等微服务治理能力,未来也会通过中间件能力开放的方式对微服务治理标准化进行实现。

CloudWeGo/Kitex:当前已支持服务注册发现、负载均衡、熔断限流、可观测性等服务治理能力,具备高可扩展性,未来会实现服务治理 Spec。

GoFrame:当前模块化、高性能的企业级应用开发框架,未来会提供基于服务治理标准化的服务注册发现、配置管理等能力。

Spring Cloud Tencent:基于服务治理标准化语义对 Spring Cloud 框架进行扩展,便于 Spring Cloud 技术栈的用户快速接入并构建微服务应用。

目前项目的路线已有了明确的规划,并在稳步推进中:

image.png

相关项目地址

服务治理标准化 Spec:https://github.com/nextarch/SIG-Microservice

PolarisMesh/polaris:https://github.com/polarismesh

go-zero:https://github.com/zeromicro/go-zero

CloudWeGo/Kitex:https://github.com/cloudwego/kitex

GoFrame:https://github.com/gogf/gf

Spring Cloud Tencent:https://github.com/Tencent/spring-cloud-tencent

目录
相关文章
|
1月前
|
Kubernetes Cloud Native 微服务
探索云原生技术:容器化与微服务架构的融合之旅
本文将带领读者深入了解云原生技术的核心概念,特别是容器化和微服务架构如何相辅相成,共同构建现代软件系统。我们将通过实际代码示例,探讨如何在云平台上部署和管理微服务,以及如何使用容器编排工具来自动化这一过程。文章旨在为开发者和技术决策者提供实用的指导,帮助他们在云原生时代中更好地设计、部署和维护应用。
|
2月前
|
消息中间件 API 持续交付
后端开发中的微服务架构实践####
【10月更文挑战第21天】 本文深入探讨了微服务架构在后端开发中的应用,从基本概念出发,详细阐述了微服务的核心优势、设计原则及关键技术。通过实际案例分析,揭示了微服务如何助力企业应对复杂业务需求,提升系统的可扩展性、灵活性与可靠性。同时,也指出了实施微服务过程中可能面临的挑战,并提供了相应的解决方案和最佳实践。 ####
41 3
|
13天前
|
监控 JavaScript 数据可视化
建筑施工一体化信息管理平台源码,支持微服务架构,采用Java、Spring Cloud、Vue等技术开发。
智慧工地云平台是专为建筑施工领域打造的一体化信息管理平台,利用大数据、云计算、物联网等技术,实现施工区域各系统数据汇总与可视化管理。平台涵盖人员、设备、物料、环境等关键因素的实时监控与数据分析,提供远程指挥、决策支持等功能,提升工作效率,促进产业信息化发展。系统由PC端、APP移动端及项目、监管、数据屏三大平台组成,支持微服务架构,采用Java、Spring Cloud、Vue等技术开发。
|
2月前
|
消息中间件 监控 持续交付
后端开发中的微服务架构设计与实践####
在当今快速发展的软件开发领域,微服务架构已成为构建高效、可扩展和易于维护应用的关键策略。本文将深入探讨微服务架构的核心概念、设计原则与实战技巧,通过实例解析如何在后端开发中有效实施微服务,以应对复杂业务需求和技术挑战。我们将从微服务的拆分策略、通信机制、数据管理到持续集成/持续部署(CI/CD)流程,全面剖析其背后的技术细节与最佳实践,为读者提供一份详尽的微服务架构设计与实践指南。 ####
104 31
|
1月前
|
运维 监控 Java
后端开发中的微服务架构实践与挑战####
在数字化转型加速的今天,微服务架构凭借其高度的灵活性、可扩展性和可维护性,成为众多企业后端系统构建的首选方案。本文深入探讨了微服务架构的核心概念、实施步骤、关键技术考量以及面临的主要挑战,旨在为开发者提供一份实用的实践指南。通过案例分析,揭示微服务在实际项目中的应用效果,并针对常见问题提出解决策略,帮助读者更好地理解和应对微服务架构带来的复杂性与机遇。 ####
|
1月前
|
消息中间件 运维 安全
后端开发中的微服务架构实践与挑战####
在数字化转型的浪潮中,微服务架构凭借其高度的灵活性和可扩展性,成为众多企业重构后端系统的首选方案。本文将深入探讨微服务的核心概念、设计原则、关键技术选型及在实际项目实施过程中面临的挑战与解决方案,旨在为开发者提供一套实用的微服务架构落地指南。我们将从理论框架出发,逐步深入至技术细节,最终通过案例分析,揭示如何在复杂业务场景下有效应用微服务,提升系统的整体性能与稳定性。 ####
50 1
|
1月前
|
消息中间件 运维 API
后端开发中的微服务架构实践####
本文深入探讨了微服务架构在后端开发中的应用,从其定义、优势到实际案例分析,全面解析了如何有效实施微服务以提升系统的可维护性、扩展性和灵活性。不同于传统摘要的概述性质,本摘要旨在激发读者对微服务架构深度探索的兴趣,通过提出问题而非直接给出答案的方式,引导读者深入
49 1
|
1月前
|
负载均衡 监控 API
后端开发中的微服务架构实践与挑战
本文深入探讨了微服务架构在后端开发中的应用,分析了其优势和面临的挑战,并通过案例分析提出了相应的解决策略。微服务架构以其高度的可扩展性和灵活性,成为现代软件开发的重要趋势。然而,它同时也带来了服务间通信、数据一致性等问题。通过实际案例的剖析,本文旨在为开发者提供有效的微服务实施指导,以优化系统性能和用户体验。
|
2月前
|
Kubernetes Java 微服务
微服务上下线动态感知实现的技术解析
随着微服务架构的广泛应用,服务的动态管理和监控变得尤为重要。在微服务架构中,服务的上下线是一个常见的操作,如何实时感知这些变化,确保系统的稳定性和可靠性,成为了一个关键技术挑战。本文将深入探讨微服务上下线动态感知的实现方式,从技术基础、场景案例、解决思路和底层原理等多个维度进行阐述,并分别使用Java和Python进行演示介绍。
80 4
|
2月前
|
运维 Kubernetes Docker
深入理解容器化技术及其在微服务架构中的应用
深入理解容器化技术及其在微服务架构中的应用
79 1