Spring 社区的首个国产开源项目顺利毕业了
Spring Cloud Alibaba 于 2018年7月27日 在 Spring Cloud 孵化器仓库提交第一次代码,到 2019年8月1日 在 Alibaba 仓库发布第一个毕业版本,时间将近整整一年。
一年时间,Spring Cloud Alibaba 完成了从 Spring Cloud 最默默无闻的项目到 Spring Cloud 最火项目的蜕变,并且从孵化器仓库毕业了!
Spring Cloud Alibaba 的正式毕业离不开社区的帮助,非常感谢 Spring Cloud Alibaba 的 contributor,也非常感谢社区开源爱好者们创建的 issue,每一个 issue 都是对 Spring Cloud Alibaba 的帮助。
Spring Cloud Alibaba 毕业过程中的一些小插曲
1、在 5 月底的时候,Spring Cloud Alibaba Team 跟 Spring Cloud Team 有过一次毕业的沟通,并且准备在 Spring Cloud Hoxton 正式发布的时候宣布 Spring Cloud Alibaba 毕业。只不过后来 Spring Cloud 官方调整了项目策略,需要进行仓库迁移。双方 team 后续还因此开了一个视频会议,Spring Cloud Alibaba 因此提前毕业。
2、Spring Cloud Team 希望毕业后的 starter 命名方式跟 spring boot starter 规定的格式一致,以 alibaba-<X>-spring-cloud-starter 的格式进行命令。考虑到孵化器的 starter 都是以 spring-cloud-starter-alibaba-<X> 开头,Spring Cloud Alibaba 并不想破坏原有的规则。最终双方讨论了好多次才决定沿用老的 starter 命名方式。
3、在仓库迁移后的几天时间内,有社区的开源爱好者专门创建 issue 提问为何离开 spring cloud 仓库,Spring Cloud Alibaba 被各种质疑。后来 Spring Cloud Leader - Spencer Gibb 在 issue 上回复进行了解释。
4、Spring Cloud Alibaba 本来计划是 6 月份发布毕业版本,结果拖到了现在。为了引起不必要的舆论风险,我们一直在等待 Spring Cloud Team 官方的公告发布,期间跟 Spring Cloud Team 沟通了好多个晚上(有 12 小时时差)。
官方文章解读
官方文章内容写得有点多,我们翻译一下并做个简单的总结:
集成到 Spring Cloud Release Train 带来的不便:
-
项目的维护者不能自行发版,从而无法与项目集成的技术组件的 roadmap 保持一致,必须等到 Spring Cloud 的下一个 Release Train 才能发布新的版本更新集成的技术组件。
-
项目的维护者没有办法看到关键的统计数据,如 github 中的关键数据, 以及在依赖被下载了多少次。
以下的这些合作,其实与在不在 Spring Cloud Release Train 中没有关系:
-
Spring Cloud Team 会参与到项目中,进行代码 review 帮助更好地集成到 Spring Cloud 。
-
Spring Cloud Alibaba Starter 会加入到 start.spring.io 中,供用户选择。
- Spring Team 会将 Spring Cloud Alibaba 项目放在官方介绍页上https://spring.io/projects/spring-cloud-alibaba,介绍项目重要的一些发版和功能特性。
仓库迁移对于开发者来说,实际意味着什么?
- 从 Spring Cloud 的 github 中迁移并不是意味着这些项目的开发和维护模式有改变,Spring Cloud Alibaba Team & Spring Cloud Team 仍然维护着项目。
- 新的模式意味着 groupId 会发生改变,甚至有些项目的 artifactId 会改变,项目中的 package name 也会发生变化。需要用户侧代码修改。
- 开发人员需要明确地在开发中指明依赖的版本,不能通过 Spring Cloud BOM 继承依赖。
- 作为先行者,Spring Cloud Alibaba 将会首先遵循新的策略,Spring Cloud Alibaba 在毕业这个重大的时机迁移是一个合适的时间。未来大家会看到更多的 组件从 Spring Cloud Release Train 中迁移出去。
本次毕业版本的 release note
1、Greenwich 对应的版本支持此 Greenwich.SR2 版本
2、Finchley 对应的版本支持此 Finchley.SR4 版本
3、Sentinel
- sentinel 相关依赖的版本更新至 1.6.3。Sentinel 各版本的 release 信息:https://github.com/alibaba/Sentinel/releases
-
#615:支持 Spring Cloud Gateway,
spring-cloud-alibaba-sentinel-zuul
重命名为spring-cloud-alibaba-sentinel-gateway
。该模块实现了 Sentinel 适配网关(Spring Cloud Gateway, Netflix Zuul)相关的逻辑 -
#614:支持 WebFlux,
spring-cloud-alibaba-starter-sentinel
内部分别适配了 WebServlet 和 WebFlux -
#626:Sentinel OpenFeign 场景下解决了接口继承场景下调用父类接口方法出错的 bug
-
#782:Sentinel OpenFeign 场景下解决了接口中存在 default 方法下调用 default 方法出错的 bug
-
#741 #615:新增网关和
http-method-specify
相关的配置 -
#716:优化了
SlotChainBuilder
的加载逻辑,确保非网关场景下 HotParamSlotChainBuilder 生效,网关场景下SlotChainBuilder
生效 -
#707:删除 DataSource 相关的加载日志,改由 Sentinel 自身的 SPI 实现(未来实现)
-
#265:添加
SentinelHealthIndicator
用于查询 Sentinel 的健康状态 -
Nacos Discovery
-
-
nacos-client 版本更新至 1.1.1。Nacos 各版本的 release 信息:https://github.com/alibaba/nacos/releases
-
#765:添加心跳相关的配置参数。包括 心跳的周期、心跳超时时间以及实例删除的超时时间
-
#669:添加
NacosRule
支持权重的 Ribbon 路由规则
-
#728:支持
ServiceRegistryEndpoint
对当前应用服务状态的操作/查询
-
#708:支持与 Spring Cloud Config 共同使用
-
#650:适配
ServerIntrospector
,可获取 metadata 以及 secure 信息
-
#644:
NacosWatch
删除内部逻辑,只进行HeartbeatEvent
事件的发送
-
-
Nacos Config
-
-
nacos-clinet 版本更新至 1.1.1。Nacos 各版本的 release 信息:https://github.com/alibaba/nacos/releases
-
#652:修复
NacosConfigEndpoint
线程不安全的 bug
-
-
RocketMQ Binder
-
-
#541:适配
MessageSource
,consumer 端可以注入PollableMessageSource
进行消息的拉取
-
#709:解决不同 jvm 下 instanceName 相同导致 rebalance 失败的 bug
-
-
Dubbo Spring Cloud
-
-
dubbo 版本更新至 2.7.3。Dubbo 各版本的 release 信息:https://github.com/apache/dubbo/releases
-
#589:ip 获取策略使用 Spring Cloud 官方的
InetUtils
工具获取
-
#592:Spring Cloud 注册中心配置
spring-cloud://localhost
成为可选项,默认直接沿用原生的 Spring Cloud 注册中心
-
#623:为服务实例的变化新增监听机制
-
#591:修复某些场景下启动报 NPE 的 bug
-
#600:不再强依赖 spring-boot-actuator,成为可选依赖
-
-
Seata
-
-
seata 版本更新至 0.7.1。Seata 各版本的 release 信息,点击这里。
-
#686:修复负载均衡的 FeignClient 场景下 xid 传递失败的 bug
-
Thanks for the contributors: @Rivers-Shall, @ly641921791, @JevonYang, @cdfive, @eacdy, @pyhblacksky, @george510257, @AbelSara, @slievrly, @pigxcloud, @lovepoem, @liudaomanbu, @lujian0571, @jsbxyyx, @pengzai170, @hero-zhanghao, @wzlee, @xingfudeshi
Roadmap
Spring Boot Admin 是一个开源社区项目,用于管理和监控 SpringBoot 应用程序。但是它没有跟 Spring Cloud 做深度的整合。我们希望做一个 Spring Cloud Admin,它能提供如下功能:
-
-
增加服务治理控制台,整合微服务控制能力
-
服务查询、管理
-
配置管理
-
限流降级等
-
项目管理/监控
-
参考 Spring Cloud Azure Playground http://azure-spring-cloud.azurewebsites.net/ ,创造 Spring Cloud Alibaba Playground,把一些最佳实践,视频教程,自动生成项目等功能放上去。
-
-
增加 Spring Cloud Alibaba 最佳实践项目。
-
针对 Spring Cloud Alibaba 各种特性,开发对应的实战 Demo。
-
替换 Spring Cloud 服务调用客户端 OpenFeign & Ribbon。开发更通用的服务调用客户端,替换 Spring Cloud 服务调用客户端 OpenFeign & Ribbon。
Committer 机制
项目迁移到 Alibaba 自身的 GitHub 仓库后,不像在 spring-cloud-incubator 仓库中那样没有权限发展 committer。我们现在有权限发展 contributor 成为 committer。任何人只要在 Spring Cloud Alibaba 项目上提交了 Pull Request 并且被 merge,就可以成为 contributor;contributor 晋升为为 committer,需要这些条件:
1、至少提交 5 个有分量的 Pull Request
2、参与 issue 列表的维护及重要 feature 的讨论
3、参与 code review
希望有越来越多的开源爱好者能够成为 Spring Cloud Alibaba 的 contributor 或 committer,让我们共同完善 Spring Cloud 生态。
毕业后用户侧代码修改
仓库迁移必定涉及到代码修改。我们总结修改点有 3 点:
1、包名 package name
2、版本号 version number
3、如果用到了 Spring Cloud Alibaba 内部类,需要 reimport 这些类(少部分情况才需要改,大部分情况这些类都被 AutoConfiguration 屏蔽了)
以使用 Spring Cloud Alibaba Bom 和 Spring Cloud Nacos Discovery 为例,了解修改点到底有哪些:
孵化器对应的 bom 和 starter 版本依赖:
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-alibaba-dependencies</artifactId>
<version>0.9.0.RELEASE</version>
<type>pom</type>
<scope>import</scope>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>
毕业对应的版本依赖:
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-alibaba-dependencies</artifactId>
<version>2.1.0.RELEASE</version>
<type>pom</type>
<scope>import</scope>
</dependency>
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>
我们在 GitHub 上提供了一个项目 ,点击这里,了解更多,用于对比毕业版本跟孵化器版本开发项目的区别。该项目使用了 Nacos Config & Nacos Discovery & Sentinel 功能,master 分支是毕业版本,incubator 分支是孵化器版本。这是使用 diff 命令比较两个分支代码的不同点:
结论: 我们发现只有 pom 里的包名和版本号不一致,代码层面无需任何修改。
版本的对应关系:
项目地址:https://github.com/alibaba/spring-cloud-alibaba
本文作者:方剑,花名洛夜,GitHub ID @fangjian0423,开源爱好者,阿里巴巴高级开发工程师,阿里云产品 EDAS 开发,Spring Cloud Alibaba 开源项目负责人。
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
数据科学用 R 还是 Python 好?专业教授多角度分析
Norm Matloff 是加州大学戴维斯分校的计算机科学教授,他针对数据科学界常年争论的要点,作了一篇关于 R 和 Python 的对比分析。 在分析开始之前,Matloff 先抛出自己可能带有的潜在偏见:他写过 4 本与 R 相关的书,在useR! 和其他 R 的会议上做过演讲,并且目前担任 R 期刊的主编。但同时他也用 Python 敲过多年代码。Matloff 希望自己的分析能够被认为是公平且有帮助的。 接着,这位专业的计算机科学家和统计学家从以下几方面对 R 和 Python 做出了对比: 优雅 Python 明显胜出。 当然这是主观的。但是在不同编程语言的对比之下,Python 大大减少了括号的使用: if x > y: z = 5 w = 8 vs. if (x > y) { z = 5 w = 8 } Python 很时尚! 学习曲线 R 在这一场赢得巨大胜利。 作为一名教育工作者,Matloff 对这一点尤其感兴趣。 若使用 Python 做数据科学,必须学习很多不在基础 Python 中的材料,例如 NumPy、Pandas 和 ...
- 下一篇
KDE 存在一个很容易利用的 0day 漏洞,影响广泛
安全研究员 Dominik Penner 披露了 Linux KDE 桌面环境上存在的一个 0day 漏洞。 根据 Dominik 的说法,此漏洞存在于 KDE v4 与 v5 版本中,该漏洞使得嵌入在 .desktop 和 .directory 文件中的命令在打开文件夹或者将压缩文件夹提取到桌面时即可执行,目前几乎所有 Linux 发行版都在使用易受攻击的 KDE 版本。 .desktop 和 .directory 文件是符合 freedesktop.org 标准的桌面环境使用的配置文件,它们用于配置应用和文件夹的显示方式。.desktop 文件用于在 KDE 菜单中注册应用程序,而 .directory 文件用于描述 KDE 应如何显示文件夹。 在BleepingComputer 的采访中,Dominik 解释:“KDE 4/5 容易受到 KDesktopFile 类中的命令注入漏洞的攻击。当实例化 .desktop 或 .directory 文件时,它通过 KConfigGroup::readEntry() 函数使用 KConfigPrivate::expandString() ...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- CentOS关闭SELinux安全模块
- SpringBoot2整合Redis,开启缓存,提高访问速度
- Docker安装Oracle12C,快速搭建Oracle学习环境
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- SpringBoot2初体验,简单认识spring boot2并且搭建基础工程
- Linux系统CentOS6、CentOS7手动修改IP地址
- CentOS8安装Docker,最新的服务器搭配容器使用
- CentOS7,8上快速安装Gitea,搭建Git服务器
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果