首次揭秘阿里巴巴中间件在-Serverless-技术领域的探索

Serverless 话题涉及范围极广,几乎包含了代码管理、测试、发布、运维和扩容等与应用生命周期关联的所有环节。AWS Lambda 是 Serverless 领域的标志性产品,但如果将其应用于核心业务,可能会遇到以下难题:(仅代表作者个人观点)首度揭秘:  要求用户以 Function 为单位进行开发,全新的开发框架,云厂商强绑定,社区主流技术栈迁移成本高;Function 启动速度要足够快,毫秒级或者秒级,这个限制对适用场景有很强的约束;Function 之间的调用通过 API Gateway,响应时间更长。本文将介绍阿里云中间件团队在探索 Serverless 过程中的思考以及正在做的事,目的是尽可能让开发者少改代码,甚至不改代码,就能具备 AWS Lambda 的技术优势。 Cloud Service Engine 云服务引擎(以下简称CSE),是阿里云中间件团队开发的面向通用 Serverless 计算的中间件产品,目的是具备 AWS Lambda 的各种优势,同时可以解决用户在使用 AWS Lambda 时遇到的难题。 什么是 ServerlessAWS 对 Serverless 定义是:(摘自 AWS 官网) AWS 无服务器平台提供的功能:(摘自 AWS 官网) AWS 的整套 Serverless 方案非常完善,但是没有解决存量应用如何迁移到 Serverless 架构的问题。仅仅是针对新开发的应用,建议用户使用 FaaS 方式开发,才有机会转向 Serverless 架构。笔者认为,要将 Serverless 架构大规模推广,必须要能有针对存量业务的解决方案。 Serverless 对云计算的价值云计算,归根结底是一种 IT 服务提供模式,不论是公共云还是专有云(以IT设备的归属不同分类),其本质都是帮助 IT 的最终使用者随时随地,并且简便快速地,获取 IT 服务,目前,IaaS、PaaS都已经做到了按需付费,PaaS 甚至做到了按请求付费,如DB,CACHE,MQ等,但是 IaaS 的付费粒度仍然是时间维度,最快按照小时付费,以分钟来交付。 因此,当下的云计算场景,应用的开发维护方式相比传统 IDC 时代的开发维护,差别还不是很大。但 AWS Lambda 提供了一种全新的开发维护方式,用户只需要写好业务代码,提交到云上,所有和机器容量、可用性、机器为单位的运维工作可以全部交给了云平台,这种模式极大的释放了云的弹性价值,真正做到了按需付费。 ...

May 24, 2019 · 2 min · jiezi

如何利用 Webshell 诊断 EDAS Serverless 应用

本文主要介绍 Serverless 应用的网络环境以及 Serverless 应用容器内的环境,了解背景知识以及基本的运维知识后可以利用 Webshell 完成基本的运维需求。Webshell 简介用户可以通过阿里云控制台直接获取 ECS 的 Shell,从而完成自己的运维需求。如果 ECS 内开启了 SSH 服务,且 ECS 存在弹性公网 IP,那么用户也可以在本地通过 SSH 服务获取 ECS 的 Shell 完成运维需求。由于 EDAS Serverless 特殊的架构以及网络环境,用户暂时无法直接从本地通过 SSH 服务获取应用容器的 Shell。在 Serverless 场景中,容器是一个暂态的、供应用运行的环境,一般来说不需要进入运维。为了方便用户进行线上问题定位排查,EDAS 在控制台提供了一个简单的Webshell,供用户查看调试自己的容器。EDAS 默认给出的 Jar War 类型应用的容器基础镜像主要是面向应用运行时,不带有冗余的排查工具,因此对运维人员可能不够友好。对于用户自身的镜像,不需要镜像中启动 SSH 服务,只需要带有可执行的/bin/bash即可。用户自己的镜像可以带上必须的运维工具方便排查。目前 Webshell 不支持 Windows 镜像。EDAS 应用节点的网络环境EDAS 应用节点处于用户自己购买的阿里云 VPC 内。在 EDAS 中,还额外提供了一层中间件服务调用隔离的手段:EDAS 命名空间。EDAS 命名空间与 VPC 内的 VSWITCH 是绑定关系,一个 EDAS 命名空间对应一个 VSWITCH,一个 VSWITCH 可以对应多个EDAS命名空间。VPC 的原理以及基本的产品情况可以在阿里云VPC官方文档了解。简单来讲,VPC 内的 IP 地址为局域网地址,不同 VPC 内的2层以上数据包无法路由到目的地。EDAS 命名空间主要做中间件逻辑隔离,不同命名空间内的应用在中间件层面是隔离的,如服务发现以及配置下发等。由于 VPC 的产品特性以及当前的 EDAS Serverless 的产品特性,容器无法直接触达 VPC 外的服务(阿里云产品除外,如 OSS、镜像服务等)。在没有额外配置的情况下,你的容器运行在网络“孤岛”环境。了解了基本的网络情况,现在可以明白为什么用户无法直接触达自己的容器了。容器内需要访问公网服务,可以通过购买 NAT,并配置 VPC 内 VSWITCH 的SNAT规则即可,详见阿里云Serverless文档。SNAT规则可以让VPC内地址访问公网地址,从而使用公网暴露的服务,获取到公网的资源。EDAS 构建的镜像的方案基于阿里云容器镜像服务,EDAS 集成了为用户构建以及管理镜像的功能。用于构建的基础镜像为centos:7,在此基础上为用户配置好了时区、语言与编码方式、Open JDK 运行环境。容器存在的目的是为了让应用运行起来,EDAS 不可能以占用所有用户运行时资源为代价,集成过多的工具,对于容器内工具有需求的用户,建议自行构建镜像,或者按需从 OSS 拉取。常见的分析手段线上容器的运维一般是不必要的。如果你确定需要进入容器进行运维,请务必了解你的操作对线上业务的风险:对于单点应用,你的行为可能导致容器 OOM,从而导致分钟级别的业务中断,而对于多点部署的业务,上述现象可能造成业务秒级中断。诊断 EDAS 应用一般从这几个方面入手:常规检查,上传搜集的日志。常规检查常规检查的方法比较多,以 Java 应用为例,一般是检查进程、线程以及 JVM 的健康状态。首先执行命令ps -ef | grep java检查你的 Java 进程是否还存在。这里必须特别说明的是,容器内一般需要使用主进程启动你的应用,这样一旦你的应用被kill掉,容器也会退出,EDAS 会将退出的容器重新启动,防止业务中断。如果进程不见了,可以执行命令dmesg | grep -i kill查看OOM相关日志。如果存在日志,那么说明你的应用进程被 kill 掉了,接着检查工作目录下hs_err_pid{PID}.log日志文件,定位具体的原因。Java 类型应用的在线分析可以使用阿里巴巴开源软件 Arthas 解决,建议在测试镜像中集成Arthas工具进行常规诊断。Arthas可以很方便地实时查看类加载情况,观察方法出入参,环境变量等。# 接入arthas,需求打通公网wget https://alibaba.github.io/arthas/arthas-boot.jarjava -jar arthas-boot.jar对于网络层的诊断,在了解上述EDAS应用节点网络情况的前提下,一般可以通过curl -v {host/ip} {port}检查域名解析以及连通性,通过tcpdump抓包观察分析网络调用情况。日志上传解决方案受限于容器内工具的匮乏,比较推荐的方案是将容器内搜集到的日志上传到云端,然后下载到本地进行分析。目前,EDAS 暂时没有提供容器内日志的下载功能,这里给出一种基于阿里云 OSS 服务的解决方案。OSS 打通了阿里云生态几乎所有的网络环境,你几乎可以在任何网络环境下上传以及下载 OSS 上的文件。首先在容器内部安装OSS命令行工具。以64位centos系统,root下没有打通公网的情况下可以选择在本地下载,然后将这个文件上传到oss,然后取oss的vpc内地址进行下载wget http://gosspublic.alicdn.com/...chmod 755 ossutil64* 然后配置你的 OSS 命令行工具,附上当前 region VPC 内的endpoint(VPC内的上传不要求打通公网,也不消耗公网带宽流量,更加经济),填写用于接收上传文件的账号的AK/SK,然后查看已经创建的Bucket,来检查你的OSS服务是否可用。请先确保账号(不必是当前账号,任意开通阿里云oss服务的账号均可)已开通 OSS 服务按照提示配置你的 AK SK endpoint信息,ststoken 不需要填写./ossutil64 config检查账号是否可用,如果报错则配置错误,如果没有bucket,则建议前往oss控制台创建,命令行工具也支持创建./ossutil64 ls这里创建一个模拟的日志文件,用于上传echo “Hello” > edas-app.log./ossutil64 cp edas-app.log {bucket-address,例如:oss://test-bucket,可以从上述命令"./ossutil64 ls"中查看}* 从 OSS 控制台或其他工具中找到你的日志文件,下载到本地,并使用你熟悉的工具进行分析。本文作者:落语(阿里云智能中间件技术开发工程师,负责分布式应用服务 EDAS 的开发和维护。)<hr>本文作者:中间件小哥阅读原文 ...

March 27, 2019 · 1 min · jiezi

阿里巴巴的微服务开源之路

侠之大者,为国为民。在金庸小说中,郭靖和黄蓉是“侠之大者,为国为民”的典范,他们以布衣之身帮助宋军守护襄阳十余年。技术的世界里,并无大小之分。但当一群程序员由服务公司内部转变为社会的程序员,将技术以开源的方式与社区的开发者一同协作、改进和使用时,他们便被赋予了更大的责任和期待。阿里云智能中间件的程序员们正和社区的开发者们一起,用键盘敲下国内微服务开源项目的过去和未来。国内首个非 Hadoop 生态体系的 Apache 社区顶级项目2016年的那届双11,RocketMQ 团队首次将低延迟存储解决方案应用于双11的支撑,经受住了流量的大考,整个大促期间,99.996%的延迟落在了10ms以内,完成了保障交易稳定的既定目标。对于读写比例几乎均衡的分布式消息引擎来说,这一技术上的突破,即便是放在全球范围内,也绝对是值得称赞的。另一边,在历时3个月的开源重塑后,RocketMQ 团队启动了向 Apache 软件基金会的捐赠之路,但迈出这一步并不容易。“当时国内的开源氛围还没有现在那么活跃,开源之后,很多设计文档、代码质量,以及社区建设还不够理想。我们一直期待,国内的开源项目和开源社区也可以在世界的开源舞台上发挥让人瞩目的价值,希望更多“中国智造”的开源项目成为世界级的开源项目。”阿里云智能高级技术专家冯嘉回忆道。经过近一年的努力,在2017年9月25日,Apache软件基金会官方宣布,阿里巴巴捐赠给 Apache 社区的开源项目 RocketMQ 从 Apache社区正式毕业,成为 Apache 顶级项目(TLP),这是国内首个非 Hadoop 生态体系的 Apache 社区顶级项目。值得一提的是,根据项目毕业前的统计,RocketMQ 有百分八十的新特性与生态集成来自于社区的贡献。毕业一年多后,RocketMQ 已经覆盖互联网金融等领域60%以上的消息场景,并被应用到金融、电力、物流、游戏、电子商务、共享出行等十几个行业。然而,随着云计算、大数据、人工智能等技术在全球范围的深入推进,催生出了如IoT、区块链、AI、边缘计算等新的应用场景,架构上如何进一步演进以更好的适应新的场景,服务好下一个十年,这是即将到来的 RocketMQ 5.0 要解决的问题。消息领域的里程碑事件RocketMQ 从 Apache 社区正式毕业的同时,消息领域出现了另一件里程碑事件,分布式消息领域的国际标准 OpenMessaging 开源项目正式入驻Linux基金会,这是国内首个在全球范围发起的分布式计算领域的国际标准。消息通信已经成为现代数据驱动架构的关键环节,但在全球范围内,消息领域仍然存在两大问题:一是,缺乏供应商中立的行业标准,导致各种消息中间件的高复杂性和不兼容性,相应地造成了公司的产品低效、混乱和供应商锁定等问题。二是,目前已有的方案框架并不能很好地适配云架构,即非云原生架构,因此无法有效地对大数据、流计算和物联网等新兴业务需求提供技术支持。这也是 RocketMQ 开源过程中,开发者和合作伙伴经常会提到的问题:“在消息领域,市场上出现了各类不同的开源解决方案,这导致了用户更高的接入和维护成本,为了确保各个消息引擎间能正常通信,还要投入大量的精力去做兼容。”这时候,建立一套供应商中立,和语言无关的消息领域的事实标准,成为各社区成员共同的诉求。此后,阿里巴巴发起 OpenMessaging 项目,并邀请了雅虎、滴滴出行、Streamlio 共同参与,一年后,参与OpenMessaging 开源标准社区的企业达20家之多,包括阿里巴巴、Datapipeline、滴滴出行、浩鲸科技、京东商城、科大讯飞、青云QingCloud、Streamlio、VIPKID、微众银行、Yahoo、中国移动苏州研发中心等(按首字母排序),此外,还获得了 Apache RocketMQ、Apache Pulsar 等顶级消息开源厂商的支持。相比于开源一个分布式消息项目,一套开源标准能被各家厂商所接受,对整个国内开源领域而言,是更具有里程碑意义的事件。从微服务框架到微服务生态Dubbo 是阿里巴巴于2012年开源的分布式服务治理框架,是国内影响力最大、使用最广泛的开源服务框架之一。在2016年、2017、2018年开源中国发起的最受欢迎的中国开源软件评选中,连续三年进入 Top10 名单。2019年2月 Dubbo 发布了2.7.0,这一版本将用于 Apache 基金会的正式毕业。(已进入 Near Graduation 阶段)从 Apache 孵化器毕业,除了有个名誉,对项目之后的维护、发展有什么影响?“从孵化器毕业是一种荣誉,但这并不是结束,而是另一种开始。这有点像求学,毕业并不意味着学习上的中断,而是发挥更大社会价值的开始。毕业也更像是一个成人礼,意味着Dubbo 团队已经符合Apache对一个成熟开源项目的要求,并开始具备独立发展的能力。”阿里云智能高级技术专家北纬在接受媒体采访时回答道。截至目前,Dubbo 已收获 2.5w+ star,在 GitHub 所有 Java 项目中排名前十,并有越来也多的企业用户选择 Dubbo 作为自己的微服务治理框架。但是,随着微服务化的逐渐深入,Dubbo 提供的能力逐渐无法满足微服务各个方面的需求。阿里云智能技术专家望陶在一次直播中分享道:“Dubbo 是一个微服务框架,帮助开发者快速构建高性能的微服务应用。但在 API Gateway,熔断限流,分布式监控,分布式事务等方面,缺乏一套比较完整的围绕 Dubbo 的解决方案,基本上是各个公司自研,或者需要调研外面开源的各种框架进行调研选型,花费了比较大的时间和精力在这上面,却无法形成一套体系化的方案。”因此,我们做了进一步的演进,即从微服务框架演进到微服务生态。通过和成熟的开源方案做集成,形成一个完整的微服务生态,组成 Dubbo Ecosystem,开发者无需为现有的系统做出过多的修改,就能快速开发微服务应用。Dubbo Ecosystem 的概念得以提出,离不开 2018 年夏天开源的两大微服务组件。技术人的仲夏之夜2018年夏天,国内开源领域,迎来了两位新成员。作为微服务和云原生生态下的两款重要开源组件,Nacos 主打云原生应用中的动态服务发现、配置和服务管理,Sentinel 则是聚焦在限流和降级两个方面。Nacos 和 Sentinel 均是在阿里近10年的核心业务场景下沉淀所产生的,他们的开源是对微服务和元原生领域开源技术方案的有效补充,同时也非常强调融入开源生态,除了兼容 Dubbo,也支持 SpringCloud 和 Kubenetes 等生态,以增强自身的生命力。“阿里巴巴早在 2007 年进行从 IOE 集中式应用架构升级为互联网分布式服务化架构的时候,就意识到在分布式环境中,诸如分布式服务治理,数据源容灾切换、异地多活、预案和限流规则等场景下的配置变更难题,因为在一个大型的分布式系统中,你没有办法把整个分布式系统停下来,去做一个软件、硬件或者系统的升级。”阿里云智能高级技术专家坤宇在 QCon 的现场分享道。相比其他服务配置中心开源方案,Nacos 的起步虽然晚了点,但除了配置中心,他还提供了动态服务发现、服务共享与管理的功能,在大规模场景下具备更优秀的性能,在易用性上更便捷,分布式部署上更灵活。Nacos 支持多种启动模式,用户可以根据业务场景自由选择,将各个功能模块,如注册中心和配置中心,分开部署或者合并部署,从而能够完整支持小型创业公司成长到大型企业,微服务全生命周期的演进。截止到目前,已经有40多家企业将 Nacos 部署到生产环境中,例如 虎牙直播 就是最早一批将 Nacos 大规模引入到生产环境的典型用户。“虎牙关注 Nacos 是从v0.2 开始的,我们也参与了社区的建设,可以说是比较早期的企业用户。引入Nacos前,我们也对比了Spring Cloud Config Server、ZooKeeper 和 ectd ,总体评估下来,基于我们微服务体系现状以及业务场景,决定使用 Nacos 作为服务化改造中服务注册和服务发现的方案。使用过程中,我们发现,随着社区版本的不断更新和虎牙的深入实践,Nacos 的优势远比调研过程中发现的多。”虎牙基础保障部中间件团队负责人张波在一次开发者活动上分享道。巧的是,一边是 Nacos宣布开源,并被列入 CNCF 云原生全景图,另一边是 Spring Cloud 生态下的服务注册和发现组件 Netflix Eureka 宣布停止开源投入,勇敢者的游戏充满了变数,但在 Nacos 团队看来,这场游戏自己可以走到最后,因为我们并不是一个人在战斗,Nacos 只是阿里众多开源项目中的一员,随后还会有更多的开源项目反哺给社区,形成生态,例如轻量级限流降级组件 Sentinel。2018年7月29日,AliwareOpen Source•深圳站现场,只能容纳400人的场地,来了700多位开发者。阿里云智能高级技术专家子矜在现场宣布了轻量级限流降级组件 Sentinel 的开源。Sentinel 经历了10年双11的考验,覆盖了阿里的所有核心场景,也因此积累了大量的流量归整场景以及生产实践。Sentinel 的出现,离不开阿里历届高可用架构团队的共同努力。“在双11备战中,容量规划是最重要也是最具挑战的环节之一。从第一年开始,双11的0点时刻就代表了我们的历史最高业务访问量,它通常是日常流量的几十倍甚至上百倍。因此,如何让一个技术和业务持续复杂的分布式站点去更平稳支撑好这突如其来的流量冲击,是我们这10年来一直在解的题。”阿里云智能高可用架构团队资深技术专家游骥在一次双11备战结束后分享道。这10年,容量规划经历了人工估算、线下压测、线上压测、全链路压测、全链路压测和隔离环境、弹性伸缩相结合的5个阶段。2013年双11结束后,全链路压测的诞生解决了容量的确定性问题。作为一项划时代的技术,全链路压测的实现,对整个集团而言,都是一件里程碑事件。![2014年,高可用架构团队获得集团 CTO 大奖](https://upload-images.jianshu…随后,基于全链路压测为核心,打造了一系列容量规划相关的配套生态,提升能力的同时,降低了整个环节的成本、提升效率。随着容量规划技术的不断演进,2018年起,高可用架构团队希望可以把这些年在生成环境下的实践,贡献给社区,之后便有了 Sentinel 的开源。Sentinel 开源后仅两个月,便被列入云原生全景图谱,位于编排和管理模块象限中,同时被列入云原生全景图谱的还有提供应用架构自动探测、故障注入式高可用能力演练和一键应用限流降级等功能的应用高可用服务 AHAS。近期,Sentinel 贡献的spring-cloud-circuitbreaker-sentinel模块正式被社区合并至Spring Cloud Circuit Breaker,由此,Sentinel 也加入了 Spring Cloud Circuit Breaker 俱乐部,成为 Spring Cloud 官方的主流推荐选择之一。Spring Cloud 官方推荐的微服务方案不止 Sentinel 一个,还有 Spring Cloud Alibaba.2018年,中国的 Java 圈发生了一件大事。Spring Cloud 联合创始人 Spencer Gibb 在 Spring 官网的博客页面宣布:阿里巴巴开源 Spring Cloud Alibaba,并发布了首个预览版本。随后,Spring Cloud 官方 Twitter 也发布了此消息。可能是受到 Spring Cloud Netflix 减少开源投入的影响,Spring Cloud Alibaba 开源后的热度超出了阿里巴巴高级技术专家姬望的预期。在接受开源中国采访的过程中,姬望认为“Spring Cloud Alibaba 是中国 Java 开发者的福音,弥补了 Spring Cloud 原生实现在大规模集群场景上的局限性。Spring Cloud 规范的实现目前有很多,比如 Netflix 有自己的一整套体系,Consul 支持服务注册和配置管理,ZooKeeper 支持服务注册等。但每套实现或多或少都有各自的优缺点,或许大多数 Spring Cloud 用户很难体会到 Netflix OSS 等实现的局限性,无论是服务发现、分布式配置,还是服务调用和熔断都不太适合大规模集群场景,比如我们内部也遇到 Eureka 性能问题。因此,我们将自身的超大规模集群经验与强大的 SpringCloud 生态整合,实现强强联合,希望能对业界会产生一些积极的化学变化。”夏天过后,开源的热度仍在延续效率的好处在于,我们可以把自己的注意力和时间聚焦在更需要创造力的事情上,做更有成就感的事情。对于工作在工程领域的开发者们而言,他们的效率意识更强。2018年9月,阿里将内部广泛使用的 Java 线上诊断工具进行开源,取名 Arthas (阿尔萨斯)。也许是击中了开发者线上排查问题的痛点,Arthas 在距离开源后的第一个 Release 版发布仅 147 天,就获得了超过 1w 的 star 数,并有40多位 Contributors 参与开源贡献。从中,我们不仅看到 Arthas 在开发者群体中的受欢迎程度,也发现越来越多的国内开发者开始擅于使用开源技术加速业务发展,更是不禁畅想起将来会有更多国内的优质开源项目获得全球开发者的关注和喜爱。技术领域,一切 里程碑 的达成,都源于一份技术情怀。阿里云智能技术专家断岭回忆到:“Arthas 在阿里巴巴内部起源于2015年,当时微服务方兴未艾,我们团队一方面专注 Spring Boot 的落地,提高开发效率。另外一方面,希望可以提高技术团队线上排查问题的能力和效率。当时,我们经过选型讨论,选择基于 Greys (Greys 是阿里巴巴杜琨@oldmanpushcart 开发的),一款 Java 开源在线问题诊断工具来开发,以提供更好的应用诊断体验。”我们在用户体验上做了大量的改进:彩色UI、Web Console 和内网一键诊断等。慢慢的,Arthas 成为阿里巴巴很多技术同事线上诊断问题的必备工具。尽管 Arthas 在阿里内部广受好评,但只是一个自用的工具。取之开源,用之开源,因此我们在2018年9月28日,正式开源了 Arthas,希望可以帮助 Java 开发人员提升诊断效率。随着越来越多的开发者开始使用 Arthas,众多开发者效率工具将 Arthas 内置到自己的产品中,丰富了 Arthas 的接入和打开方式,例如 IDE 插件 Cloud Toolkit。时间来到2019年。阿里云智能高级开发工程师煊檍在内网分享到:分布式事式问题一直是应用开发过程中的技术痒点。不敢说是痛点,因为长久以来,大家普遍对分布式事务问题的应对策略还是:能不用就不用,尽量绕开。但在微服务架构普遍落地的今天,分布式事务问题越来越绕不开,解决方案不是没有,但要么性能差,要么侵入性高,不容易落地。总之,是有点“不爽”。而这种“不爽”集中反映在了分布式事务开源中间件 Fescar 上。当阿里云智能高级开发工程师清铭在2019年1月 RocketMQ Meetup 上宣布分布式事务中间件 Fescar 正式开源后的一周内,Fescar 便收获了3000+ star,社区讨论的 issue 达58个。随后,Fescar 项目组整理并回答了开发者们集中关心的13个问题,例如 Fescar 的诞生背景、适用场景,和其他开源分布式事务方案之间的差别等。阿里巴巴中间件团队于2014年发布 TXC(Taobao Transaction Constructor),开始为集团内应用提供分布式事务服务。2016年,TXC 经过产品化改造,以 GTS(Global TransactionService)的身份上线阿里云,成为当时业界唯一一款云上分布式事务产品,以阿里云公有云和专有云解决方案的形式,交付给众多外部客户,并得到了客户的一致认可。2019 年,基于 TXC 和 GTS 的技术积累,中间件团队发起了开源项目 Fescar(Fast & EaSy Commit And Rollback, FESCAR),和社区一起共建分布式事务解决方案。TXC/GTS/Fescar 一脉相承,为解决微服务架构下的分布式事务问题交出了一份与众不同的答卷。而Fescar 的愿景是让分布式事务的使用像本地事务的使用一样简单和高效。最终的目标是希望可以让 Fescar 适用于所有的分布式事务场景。阿里巴巴的开源之路仍在延续。恰逢其时,阿里云峰会·北京的开发者专场现场,阿里云智能资深技术专家李三红宣布,阿里开源 Open JDK 长期支持版本 Alibaba Dragonwell,作为 JCP 最高执行委员会唯一的中国企业,将更主动的参与到 Java 生态的维护工作中。Dragonwell 意为龙井,象征着中国的茶文化。本文作者:中间件小哥阅读原文本文为云栖社区原创内容,未经允许不得转载。 ...

March 25, 2019 · 2 min · jiezi

揭秘:蚂蚁金服bPaaS究竟是什么?

摘要: 分布式金融核心套件,蚂蚁金服bPaaS究竟是什么东东?去年9月,蚂蚁金服在杭州云栖ATEC发布了分布式金融核心套件bPaaS( Business Platform As a Service ),对外开放自身沉淀的“产品合约”、“资产交换”、“资产核心”、“会计核算”、“计价” 等金融核心组件,而这款号称源自于蚂蚁金服十余年业务和技术积累的bPaaS,也被视为是2018年初蚂蚁金服决定将分布式金融核心能力对外输出后,蚂蚁金服推出的第一款重量级的产品。今年3月,蚂蚁金服与南京润和软件联合推出基于分布式金融核心套件bPaaS能力的“新一代分布式金融业务核心平台”。这也意味着蚂蚁金服科技开放进入新阶段,不仅有自主研发的技术输出,也推出了生态互集成模式的新型产品。那么,这款据称能够最快在3个月内复制蚂蚁金服核心技术能力的分布式核心金融套件bPaaS到底都有何神奇之处?它又能给金融行业带来哪些改变?对于蚂蚁金服又意味着什么?这些恐怕还都得从bPaaS的初衷说起。为什么会有bPaaS?蚂蚁金服高级技术专家李玄表示,bPaaS的初衷是为了加速金融行业客户的数字化转型,如果没有bPaaS,金融行业客户要从零开始摸索和开发自己的分布式业务系统,通常会是一个漫长的过程,因为其中要涉及很多分布式的关键技术,以及金融业务模型的抽象等数字化转型中的问题和痛点,非常的复杂和具有挑战性。而bPaaS则重新定义了金融业务领域模型,尽可能规避了分布式技术在核心业务中的落地复杂度,集成了分布式应用场景下的一系列支撑性能力,如全链路核对,业务监控信息标准,全链路压测等,最终形成一个打包方案,开放给金融行业的客户使用。更为重要的是,bPaaS中整合的是蚂蚁金服在十几年的金融业务实践中经过无数次的实际应用验证和检验的切实可行的技术和解决方案,说是“复制蚂蚁金服的核心技术能力”,其实并不夸张。简言之,不同金融机构存在着差异和特色,一套“通用”产品已经不能满足金融行业用户不同的业务需求。而bPaaS能够提供可复用、可运营的共享金融业务处理能力。在保持银行传统核心稳定的前提下,可以根据不同银行差异化的业务场景快速定制新业务场景,支撑银行业务快速发展,敏捷创新。bPaaS的本质说起bPaaS,实际上可以先从bPaaS在软件分层中所处的位置看起,bPaaS实际上是处于SaaS层和PaaS层之间的一个服务,它集成了资产、客户、产品、支付、账务等多个金融业务领域核心引擎组件,整合了金融业务核心领域服务能力,形成一个高度聚合的金融核心能力引擎,赋予了金融行业用户将业务能力引擎与分布式架构平台融于一体,向下能屏蔽分布式事务、底层数据库、中间件等分布式架构平台技术复杂性,向上能支撑银行客户运营和服务创新需求,标准化、可重用的金融核心领域服务能力。李玄表示,bPaaS本质上是一种为用户赋能的服务模式。其核心是将业务中公共的、通用的业务功能沉淀出来形成能力,避免功能的重复建设和维护,更合理地利用技术资源。实际上,bPaaS的精髓就在于,以非常强大的可编排、可组合、可配置、可扩展的技术服务能力,来支撑业务的快速敏捷和灵活多变。为什么要用bPaaS?在谈及为何要使用bPaaS时,李玄认为,金融行业数字化转型的敏捷诉求,是促使金融行业采用分布式金融核心套件的最主要驱动力,而bPaaS具备的三大特点,恰恰能够满足金融行业用户加速数字化转型的需求。首先,bPaaS可以为用户提供业务敏捷能力,所谓业务敏捷能力是指,bPaaS可以非常快速的支撑对业务的创新,它将底层的业务能力进行了抽象和组合编排,并且对于上层的产品是透明的,这使得用户的业务创新可以更加快速敏捷。其次,bPaaS整合了蚂蚁金服的大数据能力。众所周知,蚂蚁金服的众多业务都需要大数据进行赋能,也有众多的业务系统需要用到实时计算和离线计算等大数据技术,而蚂蚁金服将这套业务应用与大数据完美结合的技术预置到了bPaaS之中。此外,bPaaS屏蔽了整个分布式服务的复杂性。例如,蚂蚁金融云上有很多PaaS组件、中间件,单独使用并没有太高门槛,但如果想要把它们整合,去构建一个高效、敏捷、灵活的业务应用最佳实践的话,还是具有相当的难度的。而bPaaS则屏蔽了这样的复杂度,还携带了一些技术风险工具在其中,并内置了蚂蚁金服的各种规范标准,业务监控、技术监控的分析识别,基本上企业用户可以达成“拿来即用”,而如果没有bPaaS,用户可能需要走很多弯路。基于这些特点,金融行业用户通过bPaaS搭建新的新一代分布式金融核心系统,花费时间将可从过去的三年甚至更长时间缩短至3到6个月,并快速配齐弹性伸缩、敏捷开发、秒级容灾等云原生分布式能力,从而大大加速金融行业用户的数字化转型。bPaaS,金融科技开放承载者蚂蚁金服副总裁刘伟光曾如此阐述实行金融科技开放战略的初衷,“我们希望蚂蚁金服的技术开放能够和金融机构的顶层战略相结合,将我们的技术应用到客户最重要或者更创新的场景当中,让科技真正推动业务的腾飞,加速金融机构数字化转型的进程。”而作为承载蚂蚁金服金融科技开放战略的一款拳头产品,bPaaS的意义远非仅仅是一款产品那样简单,也不仅仅是蚂蚁金服金融科技开放战略的实际成果,它更大程度上展示的是蚂蚁金服要长期坚决执行金融科技开放战略的意志和决心,而此次与南京润和的合作也是蚂蚁金服将金融科技开放战略继续深入推进、共建金融行业生态的标志。“这次合作只是一个开始,我们将通过合作与更多生态伙伴一起,共同探索百花齐放、有竞争力的金融科技产品与服务。”刘伟光说。关于蚂蚁金服bPaaS:https://tech.antfin.com/products/DFAS?chInfo=zx一站式开发者服务,海量学习资源0元起!阿里热门开源项目、机器学习干货、开发者课程/工具、小微项目、移动研发等海量资源;更有开发者福利Kindle、技术图书幸运抽奖,100%中–》https://www.aliyun.com/acts/product-section-2019/developer?utm_content=g_1000047140本文作者:华蒙阅读原文本文为云栖社区原创内容,未经允许不得转载。

March 19, 2019 · 1 min · jiezi

探秘 Dubbo 的度量统计基础设施 - Dubbo Metrics

对服务进行实时监控,了解服务当前的运行指标和健康状态,是微服务体系中不可或缺的环节。Metrics 作为微服务的重要组件,为服务的监控提供了全面的数据基础。近日,Dubbo Metrics 发布了2.0.1版本,本文将为您探秘 Dubbo Metrics 的起源,及 7 大改进。Dubbo Metrics 的起源Dubbo Metrics(原Alibaba Metrics)是阿里巴巴集团内部广泛使用的度量埋点基础类库,有 Java 和 Node.js 两个版本,目前开源的是 Java 版本。内部版本诞生于2016年,经历过近三年的发展和双十一的考验,已经成为阿里巴巴集团内部微服务监控度量的事实标准,覆盖了从系统、JVM、中间件到应用各层的度量,并且在命名规则、数据格式、埋点方式和计算规则等方面,形成了一套统一的规范。Dubbo Metrics 的代码是基于 Dropwizard Metrics 衍生而来,版本号是3.1.0,当时决定 fork 到内部进行定制化开发的主要原因有两个。一是社区的发展非常缓慢,3.1.0之后的第3年才更新了下一个版本,我们担心社区无法及时响应业务需求;另一个更重要的原因是当时的3.1.0还不支持多维度的 Tag,只能基于 a.b.c 这样传统的指标命名方法,这就意味着 Dropwizard Metrics 只能在单维度进行度量。然后,在实际的业务过程中,很多维度并不能事先确定,而且在大规模分布式系统下,数据统计好以后,需要按照各种业务维度进行聚合,例如按机房、分组进行聚合,当时的 Dropwizard 也无法满足,种种原因使得我们做了一个决定,内部fork一个分支进行发展。Dubbo Metrics 做了哪些改进相对于 Dropwizard Metrics ,Dubbo Metrics 做的改进主要有以下几个方面:一、引入基于 Tag 的命名规范如前文所描述,多维度 Tag 在动态埋点,数据聚合等方面相对于传统的 metric 命名方法具有天然的优势,这里举一个例子,要统计一个 Dubbo 服务 DemoService 调用次数和 RT,假设这个服务叫做 DemoService,那么按照传统的命名方式,通常会命名为dubbo.provider.DemoService.qps和dubbo.provider.DemoService.rt。如果只有1个服务的话,这种方法并无太大的问题,但是如果一个微服务应用同时提供了多个 Dubbo 的 Service,那么要聚合统计所有Service 的 QPS 和 RT 就比较困难了。由于 metric 数据具有天然的时间序列属性,因此数据非常适合存储到时间序列数据库当中,要统计所有的 Dubbo 服务的 QPS,那么就需要查找所有名称为dubbo.provider..qps的指标,然后对他们进行求和。由于涉及到模糊搜索,这对于绝大部分数据库的实现都是比较费时的。如果要统计更加详细的 Dubbo 方法级别的 QPS 和 RT,那么实现上就会更加复杂了。Metric Key:用英文点号分隔的字符串,来表征这个指标的含义Metric Tag:定义了这个指标的不同切分维度,可以是单个,也可以是多个;tag key:用于描述维度的名称;tag value:用于描述维度的值;同时,考虑到一个公司所有微服务产生的所有指标,都会统一汇总到同一个平台进行处理,因此Metric Key 的命名方式为应当遵循同一套规范,避免发生命名冲突,其格式为appname.category[.subcategory].suffixappname: 应用名;category: 这个指标在该应用下的分类,多个单词用’‘连接,字母采用小写;subcategory: 这个指标在该应用下的某个分类下的子分类,多个单词用’‘连接,字母采用小写;suffix: 这个关键的后缀描述了这个指标所度量的具体类型,可以是计数,速率,或者是分布;在上述例子中,同样的指标可以命名为dubbo.provider.service.qps{service=“DemoService”},其中前面部分的名称是固定的,不会变化,括号里面的Tag,可以动态变化,甚至增加更多的维度,例如增加 method 维度dubbo.provider.service.qps{service=“DemoService”,method=“sayHello”},也可以是机器的 IP、机房信息等。这样的数据存储是时间序列数据库亲和的,基于这些数据可以轻松实现任意维度的聚合,筛选等操作。P.s. 2017年12月底,Dropwizard Metrics4.0 开始支持 Tag,Dubbo Metrics 中 ag 的实现参考了Dropwizard。spring-boot 2.0中提供的 MicroMeter 和 Prometheus 也均已引入了 Tag 的概念。二、添加精准统计功能Dubbo Metrics 的精准统计是和 Dropwizard,或者其他开源项目埋点统计库实现不太一样的地方。下面分别通过时间窗口的选择和吞吐率统计方式这两个纬度进行阐述。在统计吞吐率(如 QPS)的时候,Dropwizard的实现方式是滑动窗口+指数加权移动平均,也就是所谓的EWMA,在时间窗口上只提供1分钟、5分钟、15分钟的选择。固定窗口 vs 滑动窗口在数据统计的时候,我们需要事先定义好统计的时间窗口,通常有两种确立时间窗口的方法,分别是固定窗口和滑动窗口。固定时间窗口指的是以绝对时间为参考坐标系,在一个绝对时间窗口内进行统计,无论何时访问统计数据,时间窗口不变;而滑动窗口则是以当前时间为参考系,从当前时间往前推一个指定的窗口大小进行统计,窗口随着时间,数据的变化而发生变化。固定窗口的优点在于:一是窗口不需要移动,实现相对简单;二是由于不同的机器都是基于相同的时间窗口,集群聚合起来比较容易,只需按照相同的时间窗口聚合即可。其缺点是:如果窗口较大,实时性会受到影响,无法立即得到当前窗口的统计信息。例如,如果窗口为1分钟,则必须等到当前1分钟结束,才能得到这1分钟内的统计信息。滑动窗口的优点在于实时性更好,在任意时刻,能都看到当前时刻往前推演一个时间窗口内统计好的信息。相对而言,由于不同机器的采集时刻不同,要把不同机器上的数据聚合到一起,则需要通过所谓的 Down-Sampling 来实现。即按照固定时间窗口把窗口内收集到的数据应用到某一个聚合函数上。举个例子来说,假设集群有5台机器,按照15秒的频率按照平均值进行 Down-Sampling,若在00:00~00:15的时间窗口内,在00:01,00:03,00:06,00:09,00:11各收集到一个指标数据,则把这5个点的加权平均认为是00:00这个点的经过 Down- Sampling 之后的平均值。但在我们的实践过程中,滑动窗口仍会遇到了以下问题:很多业务场景都要求精确的时间窗口的数据,比如在双11的时候,想知道双11当天0点第1秒创建了多少订单,这种时候 Dropwizard 的滑动窗口很明显就不适用了。Dropwizard 提供的窗口仅仅是分钟级,双11的场景下需要精确到秒级。集群数据聚合的问题,每台机器上的滑动时间窗口可能都不一样,数据采集的时间也有间隔,导致聚合的结果并不准确。为了解决这些问题,Dubbo Metrics 提供了 BucketCounter 度量器,可以精确统计整分整秒的数据,时间窗口可以精确到1秒。只要每台机器上的时间是同步的,那么就能保证集群聚合后的结果是准确的。同时也支持基于滑动窗口的统计。瞬时速率(Rate) vs 指数移动加权平均(EWMA)经过多年的实践,我们逐渐发现,用户在观察监控的时候,首先关注的其实是集群数据,然后才是单机数据。然而单机上的吞吐率其实并没有太大意义。怎么理解呢?比如有一个微服务,共有2台机器,某个方法在某一段时间内产生了5次调用,所花的时间分别是机器1上的[5,17],机器2上的[6,8,8](假设单位为毫秒)。如果要统计集群范围内的平均 RT,一种方法可以先统计单机上的平均 RT,然后统计整体的平均 RT,按照这种方法,机器1上平均 RT 为11ms,机器2的平均 RT 为7.33ms,两者再次平均后,得到集群平均 RT 为9.17ms,但实际的结果是这样吗?如果我们把机器1和机器2上的数据整体拉到一起整体计算的话,会发现实际的平均 RT 为(5+17+6+8+8)/5=8.8ms,两者相差很明显。而且考虑到计算浮点数的精度丢失,以及集群规模扩大,这一误差会愈加明显。因此,我们得出一个结论:单机上的吞吐率对于集群吞吐率的计算没有意义,仅在在单机维度上看才是有意义的。而 Dropwizard 提供的指数加权移动平均其实也是一种平均,同时考虑了时间的因素,认为距离当前时间越近,则数据的权重越高,在时间拉的足够长的情况下,例如15分钟,这种方式是有意义的。而通过观察发现,其实在较短的时间窗口内,例如1s、5s,考虑时间维度的权重并没有太大的意义。因此在内部改造的过程中,Dubbo Metrics 做了如下改进:提供瞬时速率计算,反应单机维度的情况,同时去掉了加权平均,采用简单平均的方式计算;为了集群聚合需要,提供了时间窗口内的总次数和总 RT 的统计,方便精确计算集群维度的吞吐率;三、极致性能优化在大促场景下,如何提升统计性能,对于 Dubbo Metrics 来说是一个重要话题。在阿里的业务场景下,某个统计接口的 QPS 可能达到数万,例如访问 Cache 的场景,因此这种情况下 metrics 的统计逻辑很可能成为热点,我们做了一些针对性的优化:高并发场景下,数据累加表现最好的就是java.util.concurrent.atomic.LongAdder,因此几乎所有的操作最好都会归结到对这个类的操作上。避免调用 LongAdder#reset当数据过期之后,需要对数据进行清理,之前的实现里面为了重用对象,使用了LongAdder#reset进行清空,但实测发现LongAdder#reset其实是一个相当耗费cpu的操作,因此选择了用内存换 CPU,当需要清理的时候用一个新的 LongAdder 对象来代替。去除冗余累加操作某些度量器的实现里面,有些统计维度比较多,需要同时更新多个 LongAdder,例如 Dropwizard Metrics的 meter 实现里面计算1分/5分/15分移动平均,每次需要更新3个 LongAdder,但实际上这3次更新操作是重复的,只需要更新一次就行了。RT为0时避免调用Add方法大多数场景下对 RT 的统计都以毫秒为单位,有些时候当 RT 计算出来小于1ms的时候,传给metrics的 RT 为0。当我们发现 JDK 原生的 LongAdder 并没有对add(0)这个操作做优化,即使输入为0,还是把逻辑都走一遍,本质上调用的是sun.misc.Unsafe.UNSAFE.compareAndSwapLong。如果这个时候,metrics 判断 RT 为0的时候不对计数器进行 Add 操作,那么可以节省一次 Add 操作。这对于并发度较高的中间件如分布式缓存很有帮助,在我们内部某个应用实测中发现,在30%的情况下,访问分布式缓存的 RT 都是0ms。通过这个优化可以节约大量无意义的更新操作。QPS 和 RT 合并统计只需要对一个Long的更新,即可实现同时对调用次数和时间进行统计,已经逼近理论上的极限。经过观测发现,通常对于中间件的某些指标,成功率都非常高,正常情况下都在100%。为了统计成功率,需要统计成功次数和总次数,这种情况下几乎一样多,这样造成了一定的浪费,白白多做了一次加法。而如果反过来,只统计失败的次数,只有当失败的情况才会更新计数器,这样能大大降低加法操作。事实上,如果我们把每一种情况进行正交拆分,例如成功和失败,这样的话,总数可以通过各种情况的求和来实现。这样能进一步确保一次调用只更新一次计数。但别忘了,除了调用次数,还有方法执行 RT 要统计。还能再降低吗?答疑是可以的!假设 RT 以毫秒为单位进行统计,我们知道1个 Long 有64个bits(实际上Java里面的Long是有符号的,所以理论上只有63个 bits 可用),而 metrics 的一个统计周期最多只统计60s的数据,这64个 bits 无论怎样用都是用不掉的。那能不能把这63个 bits 拆开来,同时统计 count 和 RT 呢?实际上是可以的。我们把一个 Long 的63个 bits 的高25位用来表示一个统计周期内的总 count,低38位用于表示总 RT。——————————————| 1 bit | 25 bit | 38 bit || signed bit | total count | total rt |——————————————当一次调用过来来的时候,假设传过来的 RT 是n,那么每次累加的数不是1,也不是n,而是1 * 2^38 + n这么设计主要有一下几个考虑:count是每调用一次加一,RT 是每调用一次加N的操作,如果 count 在高位的话,每次加一,实际是一个固定的常数,而如果rt放在高位的话,每次都加的内容不一样,所以每次都要计算一次;25 bits 最多可以表示 2^25 = 33554432 个数,所以1分钟以内对于方法调用的统计这种场景来说肯定是不会溢出的;RT 可能会比较大,所以低位给了38bits, 2^38=274877906944 基本也是不可能超的。如果真的overflow了怎么办? 由于前面分析过,几乎不可能overflow,因此这个问题暂时没有解决,留待后面在解决。无锁 BucketCounter在之前的代码中,BucketCounter 需要确保在多线程并发访问下保证只有一个线程对 Bucket 进行更新,因此使用了一个对象锁,在最新版本中,对 BucketCounter 进行了重新实现,去掉了原来实现中的锁,仅通过 AtomicReference 和 CAS 进行操作,本地测试发现性能又提升了15%左右。四、全面的指标统计Dubbo Metrics 全面支持了从操作系统,JVM,中间件,再到应用层面的各级指标,并且对统一了各种命名指标,可以做到开箱即用,并支持通过配置随时开启和关闭某类指标的收集。目前支持的指标,主要包括:操作系统支持Linux/Windows/Mac,包含CPU/Load/Disk/Net Traffic/TCP。JVM支持classload, GC次数和时间, 文件句柄,young/old区占用,线程状态, 堆外内存,编译时间,部分指标支持自动差值计算。中间件Tomcat: 请求数,失败次数,处理时间,发送接收字节数,线程池活跃线程数等;Druid: SQL 执行次数,错误数,执行时间,影响行数等;Nginx: 接受,活跃连接数,读,写请求数,排队数,请求QPS,平均 RT 等;更详细的指标可以参见这里, 后续会陆续添加对Dubbo/Nacos/Sentinel/Fescar等的支持。五、REST支持Dubbo Metrics 提供了基于 JAX-RS 的 REST 接口暴露,可以轻松查询内部的各种指标,既可以独立启动HTTP Server提供服务(默认提供了一个基于Jersey+ sun Http server的简单实现),也可以嵌入已有的HTTP Server进行暴露指标。具体的接口可以参考这里:https://github.com/dubbo/metrics/wiki/query-from-http六、单机数据落盘数据如果完全存在内存里面,可能会出现因为拉取失败,或者应用本身抖动,导致数据丢失的可能。为了解决该问题,metrics引入了数据落盘的模块,提供了日志方式和二进制方式两种方式的落盘。日志方式默认通过JSON方式进行输出,可以通过日志组件进行拉取和聚合,文件的可读性也比较强,但是无法查询历史数据;二进制方式则提供了一种更加紧凑的存储,同时支持了对历史数据进行查询。目前内部使用的是这种方式。七、易用性和稳定性优化将埋点的API和实现进行拆分,方便对接不用的实现,而用户无需关注;支持注解方式进行埋点;借鉴了日志框架的设计,获取度量器更加方便;增加Compass/FastCompass,方便业务进行常用的埋点,例如统计qps,rt,成功率,错误数等等指标;Spring-boot-starter,即将开源,敬请期待;支持指标自动清理,防止长期不用的指标占用内存;URL 指标收敛,最大值保护,防止维度爆炸,错误统计导致的内存。如何使用使用方式很简单,和日志框架的Logger获取方式一致。Counter hello = MetricManager.getCounter(“test”, MetricName.build(“test.my.counter”));hello.inc();支持的度量器包括:Counter(计数器)Meter(吞吐率度量器)Histogram(直方分布度量器)Gauge(瞬态值度量器)Timer(吞吐率和响应时间分布度量器)Compass(吞吐率, 响应时间分布, 成功率和错误码度量器)FastCompass(一种快速高效统计吞吐率,平均响应时间,成功率和错误码的度量器)ClusterHistogram(集群分位数度量器)后续规划提供Spring-boot starter支持Prometheus,Spring MicroMeter对接Dubbo,Dubbo 中的数据统计实现替换为 Dubbo Metrics在 Dubbo Admin 上展示各种 metrics 数据对接 Dubbo 生态中的其他组件,如Nacos, Sentinel, Fescar等参考资料Dubbo Metrics @Github:https://github.com/dubbo/metricsWiki:https://github.com/dubbo/metrics/wiki (持续更新)本文作者:望陶,GitHub ID @ralf0131,Apache Dubbo PPMC Member,Apache Tomcat PMCMember,阿里巴巴技术专家。子观,GitHub ID @min,Apache Dubbo Commiter,阿里巴巴高级开发工程师,负责 Dubbo Admin 和 Dubbo Metrics 项目的开发和社区维护。本文作者:中间件小哥阅读原文本文为云栖社区原创内容,未经允许不得转载。 ...

March 15, 2019 · 2 min · jiezi

Spring Cloud Alibaba迁移指南(四):零代码兼容 Api-Gateway

自 Spring Cloud 官方宣布 Spring Cloud Netflix 进入维护状态后,我们开始制作《Spring Cloud Alibaba迁移指南》系列文章,向开发者提供更多的技术选型方案,并降低迁移过程中的技术难度。第一篇:一行代码从 Hystrix 迁移到 Sentinel第二篇:零代码替换 Eureka第三篇:极简的 Config如果你为 Api-Gateway(可能是 Zuul,也可能是 spring cloud gateway) 选择了 Eureka 为注册中心, 找不到一个合适的替换方案而苦苦烦恼时,那接下来的内容将是非常值得你一读。Spring Cloud Alibaba 不管是开源的服务注册组件还是商业化,都实现了 Spring Cloud 服务注册的标准规范。这就天然的给开发者提供了一种非常便利的方式将服务注册中心的 Eureka 迁移到开源的 Nacos。兼容 Api-Gateway:零代码替换 Eureka使用 Spring Cloud Alibaba 的开源组件 spring-cloud-starter-alibaba-nacos-discovery 来替换 Eureka,兼容 Api-Gateway(注意: 这里的 Api-Gateway 是一个统称,有可能是基于 Zuul 来实现,也有能可能是基于 spring cloud gateway 来实现。)仅需要完成以下几个简单的步骤即可。环境准备工作:本地需要安装 Nacos。Nacos 的安装方式也是极其的简单,参考 Nacos 官网。假设现在已经正常启动了 Nacos 。添加 Nacos 的 pom 依赖,同时去掉 Eureka。 在需要替换的工程目录下找到 maven 的配置文件 pom.xml。添加如下的 pom 依赖:<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId> <version>0.2.1.RELEASE</version> </dependency>同时将依赖的 spring-cloud-starter-netflix-eureka-client pom 给去掉。 application.properties 配置。 一些关于 Nacos 基本的配置也必须在 application.properties(也可以是application.yaml)配置,如下所示:spring.cloud.nacos.discovery.server-addr=127.0.0.1:8848同时将与 Eureka 相关的配置删除。(可选) 更换 EnableEurekaClient 注解。 如果在你的应用启动程序类加了 EnableEurekaClient 注解,这个时候需要更符合 Spring Cloud 规范的一个注解 EnableDiscoveryClient 。注意:以上几个步骤不仅仅是在集成 Api-Gateway 网关的项目中做相应的更改,通过 Api-Gateway 网关进行转发的后端服务也都要做相应的更改。完成以上三个步骤,就已经兼容了 Api-Gateway 网关的路由转发。关于如何使用 Spring Cloud Alibaba 的商业化组件 ANS 来替换掉 Api-Gateway 的注册中心 Eureka,详细的文档可参考这里。至此,《Spring Cloud Alibaba迁移指南》系列文章的四篇已全部,若您在迁移过程遇到了其他难题,欢迎到Spring Cloud Alibaba@GitHub 提issue。本文作者:中间件小哥阅读原文本文为云栖社区原创内容,未经允许不得转载。 ...

March 1, 2019 · 1 min · jiezi

Spring Cloud Alibaba迁移指南(二):零代码替换 Eureka

自 Spring Cloud 官方宣布 Spring Cloud Netflix 进入维护状态后,我们开始制作《Spring Cloud Alibaba迁移指南》系列文章,向开发者提供更多的技术选型方案,并降低迁移过程中的技术难度。第二篇,Spring Cloud Alibaba 实现了 Spring Cloud 服务注册的标准规范,这就天然的给开发者提供了一种非常便利的方式将服务注册中心的 Eureka 迁移到开源的 Nacos 。 第一篇回顾:一行代码从 Hystrix 迁移到 Sentinel零代码使用 Nacos 替换 Eureka如果你需要使用 Spring Cloud Alibaba 的开源组件 spring-cloud-starter-alibaba-nacos-discovery 来替换 Eureka。需要完成以下几个简单的步骤即可。1. __本地需要安装 Nacos。__Nacos 的安装方式也是极其的简单,参考 Nacos 官网。假设现在已经正常启动了 Nacos 。2. 添加 Nacos 的 pom 依赖,同时去掉 Eureka。 在需要替换的工程目录下找到 maven 的配置文件 pom.xml。添加如下的 pom 依赖:<dependencies> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId> <version>0.2.1.RELEASE</version> </dependency></dependencies>同时将依赖的 spring-cloud-starter-netflix-eureka-client pom 给去掉。 3. application.properties 配置。 一些关于 Nacos 基本的配置也必须在 application.properties(也可以是application.yaml)配置,如下所示: application.properties:spring.cloud.nacos.discovery.server-addr=127.0.0.1:8848同时将和 Eureka 相关的配置删除。4. (可选) 更换 EnableEurekaClient 注解。如果在你的应用启动程序类加了 EnableEurekaClient 注解,这个时候需要更符合 Spring Cloud 规范的一个注解EnableDiscoveryClient 。直接启动你的应用即可。到目前为止,就已经完成了 “零行代码使用 Nacos 替换 Eureka”。完整的方式可参考 Spring Cloud Alibaba 的官方 Wiki 文档。零代码使用 ANS 替换 Eureka如果你需要使用 Spring Cloud Alibaba 的商业化组件 spring-cloud-starter-alicloud-ans 来替换 Eureka。也是仅需完成以下几个简单的步骤即可。1. 本地需要安装 轻量版配置中心。 轻量版配置中心的下载和启动方式可参考 这里。假设现在已经正常启动了轻量版配置中心 。2. 添加 ANS 的 pom 依赖,同时去掉 Eureka。 在需要替换的工程目录下找到 maven 的配置文件 pom.xml。添加如下的 pom 依赖:<dependencies> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-alicloud-ans</artifactId> <version>0.2.1.RELEASE</version> </dependency></dependencies>同时将依赖的 org.springframework.cloud:spring-cloud-starter-netflix-eureka-client pom 给去掉。 3. (可选) application.properties 配置。 一些关于 ANS 基本的配置也可以在 application.properties(也可以是application.yaml)配置,如下所示: application.properties:spring.cloud.alicloud.ans.server-list=127.0.0.1spring.cloud.alicloud.ans.server-port=8080如果不配置的话,默认值就是 127.0.0.1 和 8080 ,因此这一步是可选的。同时将和 Eureka 相关的配置删除。4. (可选) 更换 EnableEurekaClient 注解。如果在你的应用启动程序类加了 EnableEurekaClient 注解,这个时候需要更符合 Spring Cloud 规范的一个注解EnableDiscoveryClient 。代码层面不需要改动任何代码,直接启动你的应用即可。到目前为止,就已经完成了 “零代码使用 ANS 替换 Eureka”。完整的使用方式可参考 Spring Cloud Alibaba 的官方 Wiki 文档。本文作者:中间件小哥阅读原文本文为云栖社区原创内容,未经允许不得转载。 ...

February 27, 2019 · 1 min · jiezi

Spring Cloud Alibaba迁移指南(一):一行代码从 Hystrix 迁移到 Sentinel

摘要: 本文对Hystrix、Resilience4j、Sentinel进行对比,并探讨如何使用一行代码这种极简的方式,将Hystrix迁移到Sentinel。 Hystrix 自从前段时间 宣布停止维护之后,社区推荐了 resilience4j。自 Spring Cloud 官方宣布 Spring Cloud Netflix 进入维护状态后,我们开始制作《Spring Cloud Alibaba迁移指南》系列文章,向开发者提供更多的技术选型方案,并降低迁移过程中的技术难度。第一篇,我们对Hystrix、Resilience4j 和 Sentinel 三个开源项目进行对比,并探讨如何使用一行代码这种极简的方式,将Hystrix迁移到Sentinel。Hystrix 自从前段时间 宣布停止维护之后,社区推荐了 resilience4j。这 3 款产品各有优劣势,具体的功能差异参考下表(该表来源 Sentinel Wiki): SentinelHystrixresilience4j隔离策略信号量隔离(并发线程数限流)线程池隔离/信号量隔离信号量隔离熔断降级策略基于响应时间、异常比率、异常数基于异常比率基于异常比率、响应时间实时统计实现滑动窗口(LeapArray)滑动窗口(基于 RxJava)Ring Bit Buffer动态规则配置支持多种数据源支持多种数据源有限支持扩展性多个扩展点插件的形式接口的形式基于注解的支持支持支持支持限流基于 QPS,支持基于调用关系的限流有限的支持Rate Limiter流量整形支持预热模式、匀速器模式、预热排队模式不支持简单的 Rate Limiter 模式系统自适应保护支持不支持不支持控制台提供开箱即用的控制台,可配置规则、查看秒级监控、机器发现等简单的监控查看不提供控制台,可对接其它监控系统目前 Sentinel 在 Spring Cloud Alibaba 项目中已经适配了 Spring Cloud 体系,可以用来完全替代 Hystrix 的功能了。Spring Cloud Alibaba Sentinel 功能介绍Spring Cloud Alibaba Sentinel 主要是为了整合 Sentinel 和 Spring Boot/Cloud 技术栈。目前完成了如下功能:自动适配 Servlet 容器。只需要配置 url-pattern(默认拦截所有请求),即可对拦截的这些 url 进行限流降级操作整合了 RestTemplate,使用 RestTemplate 进行操作的时候会被限流降级整合了 Feign,兼容了原先的 Hystrix 支持 Feign 的编程模型数据源可配置化,只需在配置文件中配置数据源信息,即可动态加载规则Endpoint 暴露各种元数据,比如配置信息,规则数据HealthIndicator 检查 Sentinel 健康状态 (整合中)支持 Spring Cloud Gateway 和 Zuul (整合中)Spring Cloud Alibaba Sentinel 代替 Hystrix想要使用 Spring Cloud Alibaba Sentinel,需要加上依赖信息:<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-alibaba-sentinel</artifactId> <version>0.2.1.RELEASE</version></dependency>0代码修改兼容 Feign加上 Feign 的依赖:<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-openfeign</artifactId> <version>${latest.version}</version></dependency>把 hystrix 的配置改成 sentinel 的即可使用 Sentinel 的限流降级功能:# feign.hystrix.enabled: truefeign.sentinel.enabled: true@FeignClient(name = “service-provider”)public interface EchoService { @RequestMapping(value = “/echo/{str}”, method = RequestMethod.GET) String echo(@PathVariable(“str”) String str); @RequestMapping(value = “/echo/save”, method = RequestMethod.POST) String save(Foo foo);}对于这个 EchoService,echo 方法对应的资源名是 GET:http://service-provider/echo/{str}, save 方法对应的资源名是 POST:http://service-provider/echo/save。只需配置这些规则,限流降级操作即可立即生效。一行代码支持 RestTemplateSentinel 还跟 Spring 生态的 RestTemplate 做了整合,可以对 RestTemplate 请求过程进行限流和降级操作,只需要在构造 RestTemplate 的时候加上 @SentinelRestTemplate 注解即可:@Bean@SentinelRestTemplatepublic RestTemplate restTemplate() { return new RestTemplate();}@SentinelRestTemplate 注解还暴露出了对应的属性可进行限流降级后的自定义错误,默认的行为是返回 “RestTemplate request block by sentinel” 信息。关于 @SentinelRestTemplate 的详细信息可以参考 Wiki。本文作者:中间件小哥阅读原文本文为云栖社区原创内容,未经允许不得转载。 ...

February 26, 2019 · 1 min · jiezi