相信大家对上周的 《来自 Spring Cloud 官方的消息,Spring Cloud Alibaba 即将毕业》文章记忆犹新。本周,Spring Cloud Alibaba 正式毕业,并发布了毕业后的第一个版本。
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--spring-cloud-starter 的格式进行命令。考虑到孵化器的 starter 都是以 spring-cloud-starter-alibaba- 开头,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 信息参考这里。
- issue 615:支持 Spring Cloud Gateway,spring-cloud-alibaba-sentinel-zuul 重命名为 spring-cloud-alibaba-sentinel-gateway。该模块实现了 Sentinel 适配网关(Spring Cloud Gateway, Netflix Zuul)相关的逻辑
- issue 614:支持 WebFlux,spring-cloud-alibaba-starter-sentinel 内部分别适配了 WebServlet 和 WebFlux
- issue 626:Sentinel OpenFeign 场景下解决了接口继承场景下调用父类接口方法出错的 bug
- issue 782:Sentinel OpenFeign 场景下解决了接口中存在 default 方法下调用 default 方法出错的 bug
- issue 741、 issue 615:新增网关和http-method-specify 相关的配置
- issue 716:优化了SlotChainBuilder的加载逻辑,确保非网关场景下 HotParamSlotChainBuilder 生效,网关场景下SlotChainBuilder生效
- issue 707:删除 DataSource 相关的加载日志,改由 Sentinel 自身的 SPI 实现(未来实现)
- issue 265:添加SentinelHealthIndicator 用于查询 Sentinel 的健康状态
4、Nacos Discovery
- nacos-client 版本更新至 1.1.1。Nacos 各版本的 release 信息参考这里。
- issue 765:添加心跳相关的配置参数。包括 心跳的周期、心跳超时时间以及实例删除的超时时间
- issue 669:添加NacosRule 支持权重的 Ribbon 路由规则
- issue 728:支持 ServiceRegistryEndpoint 对当前应用服务状态的操作/查询
- issue 708:支持与 Spring Cloud Config 共同使用
- issue 650:适配 ServerIntrospector,可获取 metadata 以及 secure 信息
- issue 644:NacosWatch 删除内部逻辑,只进行HeartbeatEvent 事件的发送
5、Nacos Config
- nacos-clinet 版本更新至 1.1.1。Nacos 各版本的 release 信息参考这里。
- issue 652:修复NacosConfigEndpoint 线程不安全的 bug
6、RocketMQ Binder
- issue 541:适配MessageSource,consumer 端可以注入 PollableMessageSource 进行消息的拉取
- issue 709:解决不同 jvm 下 instanceName 相同导致 rebalance 失败的 bug
7、Dubbo Spring Cloud
- dubbo 版本更新至 2.7.3。Dubbo 各版本的 release 信息参考这里。
- issue 589:ip 获取策略使用 Spring Cloud 官方的InetUtils 工具获取
- issue 592:Spring Cloud 注册中心配置spring-cloud://localhost 成为可选项,默认直接沿用原生的 Spring Cloud 注册中心
- issue 623:为服务实例的变化新增监听机制
- issue 591:修复某些场景下启动报 NPE 的 bug
- issue 600:不再强依赖 spring-boot-actuator,成为可选依赖
8、Seata
- seata 版本更新至 0.7.1。Seata 各版本的 release 信息参考这里。
- issue 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
1、Spring Boot Admin 是一个开源社区项目,用于管理和监控 SpringBoot 应用程序。但是它没有跟 Spring Cloud 做深度的整合。我们希望做一个 Spring Cloud Admin,它能提供如下功能:
- 增加服务治理控制台,整合微服务控制能力
- 服务查询、管理
- 配置管理
- 限流降级等
- 项目管理/监控
2、参考 Spring Cloud Azure Playground http://azure-spring-cloud.azurewebsites.net/ ,创造 Spring Cloud Alibaba Playground,把一些最佳实践,视频教程,自动生成项目等功能放上去。
3、增加 Spring Cloud Alibaba 最佳实践项目。
4、针对 Spring Cloud Alibaba 各种特性,开发对应的实战 Demo。
5、替换 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 版本依赖:
毕业对应的版本依赖:
我们在 GitHub 上提供了一个项目 ,详情参考这里。
用于对比毕业版本跟孵化器版本开发项目的区别。该项目使用了 Nacos Config & Nacos Discovery & Sentinel 功能,master 分支是毕业版本,incubator 分支是孵化器版本。这是使用 diff 命令比较两个分支代码的不同点:
结论: 我们发现只有 pom 里的包名和版本号不一致,代码层面无需任何修改。
版本的对应关系:
项目地址参考这里。
本文作者:方剑,花名洛夜,GitHub ID @fangjian0423,开源爱好者,阿里巴巴高级开发工程师,阿里云产品 EDAS 开发,Spring Cloud Alibaba 开源项目负责人。
本文为云栖社区原创内容,未经允许不得转载。