东莞著名网站建设,移动网站的开发流程图,查询网站相关网址,网站开发美工绩效考核简介#xff1a; 服务框架就像铁路的铁轨一样#xff0c;是互通的基础#xff0c;只有解决了服务框架的互通#xff0c;才有可能完成更高层的业务互通#xff0c;所以用相同的标准统一#xff0c;合二为一并共建新一代的服务框架是必然趋势。Dubbo3.0 是 Dubbo2.0 与 HSF…简介 服务框架就像铁路的铁轨一样是互通的基础只有解决了服务框架的互通才有可能完成更高层的业务互通所以用相同的标准统一合二为一并共建新一代的服务框架是必然趋势。Dubbo3.0 是 Dubbo2.0 与 HSF 融合而来是阿里经济体面向内部业务、商业化、开源的唯一标准服务框架。
服务框架就像铁路的铁轨一样是互通的基础只有解决了服务框架的互通才有可能完成更高层的业务互通所以用相同的标准统一合二为一并共建新一代的服务框架是必然趋势。
Dubbo3.0 是 Dubbo2.0 与 HSF 融合而来是阿里经济体面向内部业务、商业化、开源的唯一标准服务框架。
阿里巴巴服务框架的选择与实践
Dubbo 和 HSF 在阿里巴巴的实践
Dubbo 和 HSF 都是阿里巴巴目前在使用的微服务 RPC 框架。
Dubbo 则在 2011 年开源后迅速成为业界广受欢迎的微服务框架产品在国内外均有着广泛应用。Dubbo 项目诞生于 2008 年起初只在一个阿里内部的系统使用2011 年阿里 B2B 决定将整个项目开源仅用了一年时间就收获了来自不同行业的大批用户2014 年由于内部团队调整Dubbo 暂停更新2017 年 9 月Dubbo 3.0 重启开源在 2019 年 5 月由 Apache 孵化毕业成为第二个由阿里巴巴捐献至 Apache 毕业的项目。 HSF 在阿里巴巴使用更多承接了内部从单体应用到微服务的架构演进支撑了阿里历年双十一的平稳运行自 2008 年 5 月发布第一个版本 1.1 后经历数年迭代HSF 从一个基础的 RPC 框架逐渐演变成为日支撑十万亿级别调用的易于扩展的微服务框架。内部场景中用户既可以选择少量配置轻松接入微服务体系获取高性能的稳定服务调用。也可以按照自身业务需求对 HSF 进行扩展获取整条链路的能力增强。
对于集团内的需求而言稳定和性能是核心因此当时选型了在电商这种高并发场景久经考验的 HSF 做为新一代服务框架核心。随后HSF 推出了 2.0 的版本并针对 HSF 之前版本的主要问题进行重构改造降低了维护成本进一步提高了稳定性和性能。HSF2.0 解决了通讯协议支持不透明序列化协议支持不透明等框架扩展性问题。基于 HSF2.0 的 Java 版本集团内也演进出了 CPP/NodeJs/PHP 等多语言的客户端。由于 HSF 还兼容了 Dubbo 的协议原有的 Dubbo 用户可以平滑地迁移到新版本上所以 HSF 推出后很快就在集团全面铺开部署的 server 数量达到数十万基本完成了阿里巴巴内部微服务框架的统一并经历了多年双十一零点流量洪峰的验证。
下一代微服务的挑战和机遇
然而业务的发展和框架自身的迭代使得两个框架从协议层的简单兼容已经无法满足需要。随着云计算的不断发展和云原生理念的广泛传播微服务的发展有着以下趋势
K8s 成为资源调度的事实标准Service Mesh 从提出到发展至今已经逐渐被越来越多用户所接受。屏蔽底层基础设施成为软件架构的一个核心演进目标无论是阿里巴巴还是其他企业用户所面临的问题都已经从是否上云变为如何平滑稳定地低成本迁移上云。由于上云路径的多样以及由现有架构迁移至云原生架构的过渡态存在部署应用的设施灵活异变云上的微服务也呈现出多元化的趋势。跨语言、跨厂商、跨环境的调用必然会催生基于开放标准的统一协议和框架以满足互通需求。端上对后台服务的访问呈爆炸性的趋势增长应用的规模和整个微服务体系的规模都随之增长。
这些趋势也给 HSF 和 Dubbo 带来了新的挑战。
HSF 和 Dubbo 面临的挑战
微服务框架是基础组件大部分公司在早期选型或业务发展到一定规模的时候都需要确定使用某一个框架。而一个稳定高效的自研框架通常需要较长时间的迭代来打磨优化。所以大部分公司初期都会倾向于使用开源组件。对阿里云而言这就带来了一个问题内部使用的是 HSF 框架而云上的用户大部分都是使用的开源 Dubbo 框架两种框架在协议、内部模块抽象、编程接口和功能支持上都存在差异。
如何能让使用了 HSF 的阿里集团内部组件的最优实践和前沿技术更简单直接地输出到云上这是每一个做技术商业化的同学都会遇到和必须解决的问题。其实我们也有过一些探索云上微服务最早推的是 HSF 框架闭源组件在云上输出的时候对于许多用户而言遇到问题后无从排查整个服务框架对于他们来说是一个黑盒的组件。我们发现这并不是一个很好的产品化方向在云上输出的时候我们必须选择拥抱开源的方式主推 Dubbo 与 Spring Cloud 框架。
同时在集团内也因为同时存在 HSF 与 Dubbo 框架而导致的不少问题。原有部门或公司的技术栈如何更快地融入到现有技术体系是一个绕不开的问题。一个典型的例子就是 2019 年加入阿里巴巴的考拉。考拉之前一直使用 Dubbo 作为微服务框架基于 Dubbo 构建了大规模的微服务应用迁移的成本高风险也大。需要集团和考拉的基础架构部门耗费较长的时间进行迁移前调研、方案设计确保基本可行后再开始改动。从分批灰度上线再到最终全量上线。这种换血式的改动不仅需要耗费大量人力时间跨度也很长会影响到业务的发展和稳定性。同时由于历史原因集团内部始终存在着一定数量的 Dubbo 用户。为了更好的服务这部分用户HSF 框架对 Dubbo 进行了协议层和 API 层的兼容。但这种兼容仅限于互通随着 Dubbo 开源社区的多年发展这种基础的兼容在容灾、性能和可迭代性方面都有着较大的劣势同时很难对齐 Dubbo 的服务治理体系。在稳定性方面也存在风险更无法享受到集团技术发展和 Dubbo 社区演进的技术红利。
产生这些问题的根本原因是闭源的 HSF 无法直接用于广大云上用户和外部其他用户而开源产品对闭源产品的挑战会随着开源和云的不断发展愈演愈烈。越早解决这个问题阿里巴巴和外部企业用户的云原生迁移成本越低产生的价值也就越大。
因此HSF 和 Dubbo 的融合是大势所趋。为了能更好的服务内外用户也为了两个框架更好发展Dubbo3.0 和以 Dubbo3.0 为内核适配集团内基础架构生态的 HSF3.0 应运而生。
三位一体战略下服务框架的最终选择 Dubbo3.0
Dubbo3.0 在原有功能集与 API 完全兼容的前提下同时具备了以下几大面临云原生挑战下的新特性
Dubbo 3.0 支持全新的服务发现模型Dubbo 3.0 尝试从应用模型入手优化存储结构对齐云原生主流设计模型避免在模型上带来的互通问题。新模型在数据组织上高度压缩能有效提高性能和集群的可伸缩性。Dubbo 3.0 提出了下一代 RPC 协议 —— Triple。这是一个基于 HTTP/2 设计的完全兼容 gRPC 协议的开放性新协议由于是基于 HTTP/2 设计的具有极高的网关友好型和穿透性完全兼容 gRPC 协议是的天然在多语言互通方面上具有优势。Dubbo 3.0 面向云原生流量治理提出了一套能够覆盖传统 SDK 部署、Service Mesh 化部署、VM 虚拟机部署、Container 容器部署等场景的统一治理规则支持一份规则治理大部分场景大大降低流量治理治理成本使得异构体系下全局流量治理变得可能。Dubbo 3.0 将提供接入 Service Mesh 的解决方案面向 Mesh 场景Dubbo 3.0 提出了两种接入方式一种是 Thin SDK 模式部署模型和当前 Service Mesh 主流部署场景完全一样而 Dubbo 将进行瘦身屏蔽掉与 Mesh 相同的治理功能仅保留核心的 RPC 能力第二种是 Proxyless 模式Dubbo 将接替 Sidecar 的工作职责主动与控制面进行通信基于 Dubbo 3.0 的统一治理规则应用云原生流量治理功能。服务框架在阿里云商业化方向上的演进思路
对于微服务框架来说由于关联到客户的业务代码要做商业化还是有非常大的挑战的。
首先迁移成本上来说希望把降低迁移成本为 0最开始我们在云上售卖的是 HSF EDAS Container 这一套的架构因此客户在上云的时候不得不对自己的业务代码进行改造另外由于代码不开源排查问题也是一个非常头疼的问题后来我们发现客户大多数的微服务框架都会选择开源的 Dubbo/Spring Cloud但是客户有自建的注册中心如果要上云还需要把自己的注册中心迁移到 MSE 注册中心上这个过程需要用户对代码做改造才行一般来说会采用双注册的方案在云上我们发现推动客户做代码改造包括 SDK 的升级是一件非常难的事情很多客户的 Dubbo 版本还停留在 4-5 年的版本不仅需要研发、测试、运维都来关注还需要排期支持这个动作会耗费大量的人力资源同时面临许多稳定性的挑战。光是这一步就会阻挡住许多的客户了为了解决客户 SDK 升级的问题我们在想能不能不要迁移注册中心呢最好是代码一行也不用改部署到云上来但我们又需要提供同等的服务治理能力因此我们提出了基于 Java Agent 字节码增强的技术帮助用户不改一行代码使用云产品对客户做到了随时可上可下没有绑定让客户比较放心的上云产品同时我们还提供了能力更强的面运维的托管的注册中心。
对于商业化中微服务框架的选择我们选择的态度一直是拥抱开源。
我们还需要在开源微服务框架的基础上提供差异化的服务治理能力传统开源微服务框架在 K8s 上的问题在上云的过程中逐步暴露出来。通过一系列和客户的交流我们总结出了客户的云原生下进行微服务治理的几大痛点主要包括微服务发布过程中的无损上下线标签路由服务鉴权离群实例摘除全链路灰度等等我们通过 Java Agent 技术实现了在用户不改代码的情况下解决了上述问题通过客户交流收集需求落到产品给客户 demo 验证这个模式跑通了正向的循环功能不断丰富中。除了Java Agent对于多语言的场景我们使用 Service Mesh、WASM 等技术同样支持客户无需修改一行代码就具备于 Java 应用一致的服务治理能力与体验。
同时在Java Agent 的选择上我们也有过一些尝试跟选择一开始我们使用闭源开发的 Java Agent每个云产品都有一个对应的 Java Agent这样会导致 Java Agent 过多以及Agent冲突等问题同时由于我们自己维护的 Java Agent 又是闭源的。踩过一些坑后我们决定使用 Arthas One Agent 重构服务治理体系的 Agent将治理相关的 Agent 合成一个同时我们底座的 Java Agent 也使用拥抱开源的策略我们使用开源的 Arthas One Agent。 Dubbo3.0 顺应了这个方向通过 Dubbo3.0 Java Agent 将集团技术发展和 Dubbo 社区演进、以及商业化实践的技术红利不断且持续地输出给云上的客户。
服务治理无缝支持 Dubbo3.0 阿里云上微服务治理相关的三种解决方案MSE(微服务引擎提供微服务治理的能力)、EDAS(全生命周期托管的应用平台)、SAE(具备弹性伸缩能力的Serverless 应用平台)EDAS 与 SAE 均深度集成了 MSE 服务治理能力其中 MSE 所有的服务治理能力都是开箱即用支持近五年来市面上所有开源 Dubbo、Spring Cloud 框架包括 Dubbo 3.0 您无需修改一行代码与配置您只需将您的 Dubbo 3.0 的应用接入 EDAS/MSE/SAE。包括微服务发布过程中的无损上下线能力对齐了微服务与 K8S POD 的生命周期标签路由能力弱化了对 IP 的绑定依赖服务鉴权离群实例摘除全链路灰度服务 Mock、服务监控、服务契约等等。
如何将一个 HSF 应用无缝升级成 Dubbo 3.0 应用
三位一体是阿里巴巴“自研”、“开源”、“商业化”采用统一技术体系在此技术方向下Dubbo3.0 的设计与落地实现了 HSF/Dubbo 的技术统一在集团内也正在快速推广落地中。同时 EDAS Container 4.x版本正是 Dubbo3.0 的商业化输出形式之一。
如果您的应用在 EDAS 或者 SAE 上使用的是 HSF EDAS Container 这一套的架构用户只需升级容器版本至 4.x 就可以便捷的将 HSF 应用升级为 Dubbo 3.0 应用。升级之后HSF 应用可沿用原有开发方式还可以使用 EDAS/SAE 为 Dubbo 应用提供的更加完善的服务治理功能。同时您的HSF应用也将会具备 Dubbo 3.0 的各种新特性、应用级服务发现、Triple 协议等。
Java 微服务 Proxyless Mesh 架构
在异构微服务场景下随着 ServiceMesh 方案的普及原先微服务应用如何在 Service Mesh 微服务架构中与其他 Mesh 节点进行互通以及治理能力对齐成了困扰用户的问题。开源 Spring Cloud / Dubbo 框架在MSE微服务引擎上无需增加 Envoy同时也无需修改任何一行代码就可以与 Mesh 架构互通。
Dubbo3.0 的大规模生产实践案例
Dubbo3.0 在落地的过程中我们具备许多大规模的实践考拉、钉钉等。
下面以钉钉为例介绍
背景
为了拥抱容器化、享受云上的福利钉钉文档在 2020 年启动了上云战役。目前已有 50% 的流量跑在公有云集群。
业务挑战
文档的上云分成了两个阶段。
第一阶段弹内即阿里集团内网络和云上各有一个文档集群弹内集群承接存量业务云上集群承接增量业务。弹内集群同时起了代理的功能对弹内的上游服务来说弹内集群代理了对文档云上集群的调用对云上集群来说弹内服务代理了集团内下游的依赖。 第一阶段弹内、云上各有一个集群
第二阶段存量数据迁移到了云上只保留云上集群。上游服务、下游依赖都是通过 triple 协议直接调用。 第二阶段只有一个云上集群
目前我们处于第一阶段。
在第一阶段我们有几个诉求
1、希望使用一套代码跑在弹内、云上两个集群
2、希望弹内集群继续使用 HSF 协议
3、希望云上使用开源的 RPC 协议
4、希望云上、弹内集群可以互通。
而 Dubbo 3.0完美的契合我们的需求。
落地方案
1、双集群 文档目前有两个集群。弹内集群暴露了 triple、hsf 双协议云上集群仅暴露 triple 协议。
弹内的版本号保持 1.0.0 不变云上使用 1.0.0.ZJK 的版本号。
对上游服务来说只有弹内一个集群所有流量都是打到弹内集群。这样上游业务无需做任何改造。
2、单元化路由
弹内服务对到来的 HSF 请求进行拦截。如果解析出需要将请求路由到云上则对云上服务发起一次 triple 调用。否则继续将请求交给弹内的服务。
3、下游依赖 文档有一些对弹内服务的依赖去除不掉。目前的做法是文档自己把下游服务做一次封装暴露出 triple 协议供云上调用。
4、服务治理
服务互通完成了之后就是开始看如何进行服务治理了。包括服务查询、服务测试、服务压测、服务限流、服务监控等。
4.1 MSE
服务查询、服务测试、服务路由等都是通过接入 MSE 完成的。这里要特别提一下 MSE 的服务测试。业务同学最开始是在本机 curl hsf 的 http 端口进行测试非常麻烦但是在接入 MSE 服务治理之后就可以直接用 MSE 平台的服务测试功能。服务测试即为用户提供一个云上私网 Postman 让用户能够轻松调用自己的服务。用户无需感知云上复杂的网络拓扑结构无需关系服务的协议无需自建测试工具只需要通过控制台即可实现服务调用。支持 Dubbo 3.0 框架以及 Dubbo 3.0 主流的 Triple 协议。
4.2 其他 由于云上使用了标准的 Dubbo 协议Ahas、Arms 等中间件都可以无缝的接入。
总结
钉钉文档借助三位一体的红利实现三个月内快速上云通过云产品方式产品化标准化地解决了上云过程中遇到的问题借助 Dubbo3.0 的云原生特性以及 MSE 服务治理能力的快速接入与支持快速完成服务框架从互通到治理的落地。
尾
自研、商用、开源的“三位一体”使得我们在 双11 中沉淀的核心技术可以直接给到客户使用省略了经过云上沉淀再输出的过程降低了客户获取 “双11 同款技术引擎” 的门槛和成本可帮助客户快速迈入数字原生时代。Dubbo3.0 正是在这个战略下的选择Dubbo3.0 和基于 Dubbo3.0 内核的 HSF 正在外部和内部齐头并进为阿里云上、集团内、以及开源的用户提供最佳的用户体验一起参与来打造最稳定的服务框架在云原生时代下引领微服务的发展。
原文链接 本文为阿里云原创内容未经允许不得转载。
