首页 文章 精选 留言 我的

精选列表

搜索[国产神器],共5675篇文章
优秀的个人博客,低调大师

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 开源项目负责人。

优秀的个人博客,低调大师

为什么国产手机痴迷于做"生态"?

【大咖・来了 第7期】10月24日晚8点观看《智能导购对话机器人实践》 曾几何时,中国智能手机产业从硬件的比拼到了“情怀”又到了今天的“生态恋”,似乎相关手机企业如果不玩“生态”,就落伍了,就没有未来。而我们的媒体们也是动辄就以什么生态来评论手机企业是否具有竞争力,或者对此大加吹捧,尽管可能连它们自己(包括企业)都没有完全搞清楚这些企业的“生态”究竟是什么,确切地说这些“生态”未来如何给这些企业带来可观的营收和利润。 了解和熟悉智能手机产业的业内知道,在当前的智能手机产业中最挣钱或者严格说能够放在台面上说挣钱的企业就是苹果和三星。尽管三星连续多个季度利润下滑,但在上个季度中,二者还是合计拿走了全球智能手机产业超过100%的利润。重要的是,它们这些营收和利润几乎全部来自手机硬件本身的销售。 在此也许有人会说,我们又拿苹果和三星来压人,甚至称不具可比性,但我们想说的是,首先我们多数打着“生态”旗号的企业在宣传上都是以上述两家企业为目标,其次是上述两个企业是当前两大智能手机产业阵营的代表,所以只要玩手机产业,这两家企业无论是从我们企业主观设置的竞争对手,还是客观所处的产业范畴,都是不可回避的。那么到此又会有人称,苹果不就是靠着生态才有今天吗? 不过我们想告诉有此认识的人,不要说智能手机(iPhone本身),就是从苹果整个营收和利润的来源看,硬件占据了其90%以上的份额。所谓的生态给苹果带来的营收和利润充其量在10%左右。当然我们在此并非否认生态的重要性,只是澄清,至少在常人认为的苹果生态中,生态其实是为硬件服务的,生态本身给苹果带来的营收和利润微乎其微。这点和我们国内目前某些“生态恋”企业所言的不指望手机硬件本身挣钱,而是利用围绕其生态挣钱截然相反。 还有一点证明苹果是以硬件本身为核心的典型例子是,近日,全球应用数据分析网站App Annie***发布的数据显示,今年***季度,谷歌应用商店Google Play的应用下载总量较苹果应用商店App Store高出70%,但后者的应用下载营收却较Google Play高出了70%左右,较2014年第三季度的60%有所扩大。究其原因,就是iPhone6及iPhone6 Plus的热销,拉动了苹果App Store营收的增长。 分析完苹果,再看三星。三星之前的陨落是业内共知的事实。但最根本的原因还是在手机硬件本身败给了iPhone硬件的品质和中国手机企业硬件的性价比。与业内所谓的三星缺乏生态系统没有直接的关系。这点通过今年三星新近发布的Galaxy S6和Galaxy S6 Edge受热捧,预定量目前已经超过2000万部也得到了证明。 理由很简单,今日三星所谓的生态与之前的三星相比有何实质性的改观吗?当然没有,而从媒体报道及相关权威评论看,恰恰是Galaxy S6和Galaxy S6 Edge与之前的Galaxy相比在硬件上有了创新才是其再次受捧的主要原因。正如瑞士信贷***分析师江翰(Keon Han)所言:市场、运营商甚至用户都一致认为新系列有别于以往的任何系列,因为无论从设计还是规格,S6系列都是三星史上***的。由于这位明星分析师以往的推荐都给追随他的投资者们带来过丰厚回报,所以此评论还是具有一定的代表性和权威性,重要的是,这些评论主要指的就是手机硬件本身。 通过上述我们对于苹果和三星这两个智能手机产业代表的简单分析,既然手机硬件本身能够带来巨大的营收和利润,为何我们国内企业却羞于谈这些,而对所谓生态情有独钟呢? 首先是我们国内手机企业的品牌溢价能力有限,或者彼此间差距不大。这从在市场中多数国内手机企业几乎都是以“性价比”作为手机硬件本身***差异化竞争力可见一斑。但谁都知道“便宜没好货,好货不便宜”的道理。具体到手机产业,尽管看似配置相同,但不同厂商的配件,彼此间的差距还是不小的。其实这点在我们日常生活中比比皆是,在此就不一一例举了。重要的是,品牌溢价背后的真正的与硬件相关的核心竞争力的缺乏。 其次,正是由于上述创新力的缺乏,为了能够博得投资人及用户的认可,不指望手机本身挣钱,而是通过服务和应用挣钱的“生态”就成为了极好的借口和混淆用户对于手机硬件创新及优劣的认识。尤其是对于投资人,生态系统的建立需要时间更为可信,以为其实质赔钱的手机业务继续投资。 ***就是从宣传的角度看,以“生态”之名也也极易获得关注,且显得自己与对手的不同,但就我们接触到的媒体及评论人,多数对于某些厂商的“生态”都是雾里看花,云山雾罩。至于未来能够成为营收和利润的主力,更是百思不得其解。 更为矛盾的是,恰恰是这些认为手机硬件不重要,恋“生态”的厂商们却为了出货量的排名打得不可开交,当然这背后的逻辑是这些所谓“生态”实质上还是以手机为核心,既然因为性价比挣不到可观的营收和利润,至少在市场份额上要有所表现才好(没有占有率,何以成为核心),否则怎么和业内去和投资人圆“生态”之说呢?可话又说回来,既然手机是“生态”的核心,连核心都挣不到钱,那它是怎么成为核心的呢? 另外,从目前恋“生态”的厂商看,多数的营收还是来自手机硬件本身(利润就不要说了吧),丝毫没有显示出“生态”的主要作用在哪里。对,在未来,那未来有多远呢?回答还是“未来”。 综上所述,我们认为,进入到今年以来,中国手机产业“生态恋”的背后是我们手机产业核心竞争力缺失和创新乏力的典型反映,是为自己所谓手机性价比不挣钱遮掩的借口,是中国手机产业竞争末路剑走偏锋的产物。 【责任编辑: chenqingxiang TEL:(010)68476606】

资源下载

更多资源
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长,特征是大鼻子、头戴帽子、身穿背带裤,还留着胡子。与他的双胞胎兄弟路易基一起,长年担任任天堂的招牌角色。

Spring

Spring

Spring框架(Spring Framework)是由Rod Johnson于2002年提出的开源Java企业级应用框架,旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念,提供核心容器、应用上下文、数据访问集成等模块,支持整合Hibernate、Struts等第三方框架,其适用范围不仅限于服务器端开发,绝大多数Java应用均可从中受益。

Rocky Linux

Rocky Linux

Rocky Linux(中文名:洛基)是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版,作为CentOS稳定版停止维护后与RHEL(Red Hat Enterprise Linux)完全兼容的开源替代方案,由社区拥有并管理,支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性,采用模块化包装和SELinux安全架构,默认包含GNOME桌面环境及XFS文件系统,支持十年生命周期更新。

WebStorm

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源,继承了IntelliJ IDEA强大的JS部分的功能。

用户登录
用户注册