近日，阿里巴巴中间件团队宣布开源 Sentinel，并发布了首个社区版本v0.1.0。Sentinel 作为阿里巴巴“大中台、小前台”架构中的基础模块，覆盖了阿里的所有核心场景，因此积累了大量的流量归整场景以及生产实践。Sentinel 以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。
限流：当我们设计了一个函数，准备上线，这时候这个函数会消耗一些资源，处理上限是1秒服务3000个QPS，但如果实际情况遇到高于3000的QPS该如何解决呢？Sentinel提供了两种流量统计方式，一种是统计并发线程数，另外一种则是统计 QPS，当并发线程数超出某个设定的阈值，新的请求会被立即拒绝，当QPS超出某个设定的阈值，系统可以通过直接拒绝、冷启动、匀速器三种方式来应对，从而起流量控制的作用。 熔断降级：接触过Spring Cloud、Service Mesh的同学，都知道熔断降级的概念。服务之间会有相互依赖关系，例如服务A做到了1秒上万个QPS，但这时候服务B并无法满足1秒上万个QPS，那么如何保证服务A在高频调用服务B时，服务B仍能正常工作呢？ 一种比较常见的情况是，服务A调用服务B时，服务B因无法满足高频调用出现响应时间过长的情况，导致服务A也出现响应过长的情况，进而产生连锁反应影响整个依赖链上的所有应用，这时候就需要熔断和降级的方法。Sentinel通过并发线程数进行限制和响应时间对资源进行降级两种手段来对服务进行熔断或降级。 外媒报道，Google 正试图通过将 AndroidX（以前被称为 Android 支持库）迁移到公开的 Android 开源项目（AOSP）中，为开发者提供更高的透明度。此举意味着主要功能开发和修复的过程将更开放，更改将可见。
AndroidX 最初是一个小的集合库，旨在为新的 Android 平台 API 提供向后兼容性。因此，它的开发与平台紧密相关，所有工作都在 Google 内部分支先完成，然后再推送至 AOSP 。由于这种保密机制，导致开发者很难为项目做出贡献。开发者若是想进行完整的 AndroidX 构建和测试，就不得不先查看超过 40GB 的 Android 平台代码。 如今的 AndroidX 的范围已经大大扩展，囊括 AppCompat、Room 和 WorkManager 等库。其中的许多库已实现高级抽象，而不再与 Android 平台的新版本相关联。因此，两年多前，Google 就已经开始将 AndroidX 从 Android 平台版本转移到自己独立的版本控制中。 此次通过将 AndroidX 迁移至 AOSP ，开发者将能够实时查看功能和 bug 修复。 按照 Google 的说法，AOSP 是一个进行试验和原型设计的地方。一些新的库会先出现在此存储库中，然后正式合并到现有库，或者是在发布之前被删除，亦或是在 alpha 开发期间进行大幅调整。更多内容，请关注本次专辑…… JDK 团队在上周五发起了一起名为 “Project Skara” 的意见征集，旨在讨论如何改进自 2008 年以来一直使用 Mercurial 存储库的 JDK 源码管理方案。据悉，发起这个项目的原因是想帮助 OpenJDK 贡献者提高效率。JDK 开发者和 OpenJDK 审查员 Joe Darcy 在邮件中写道：
为帮助 OpenJDK 贡献者提高效率，Project Skara 建议无论是经验丰富的提交者还是新人，都来参与讨论代替 SCM 和代码审查的选项，比如基于 Git 而不再是 Mercurial，甚至是其他第三方选择。为更好地进行对比，Project Skara 还打算未来在不同的服务商下托管 JDK 12 的源码。 Joe 还列出了一些评估标准，供贡献者参考：性能，从主存储库进行克隆操作的时间，本地操作的时间等。空间效率，在不同地区的可用性。支持 Linux、Mac 和 Windows 等常见开发环境。。能够轻松承载 JDK 的整个历史以及未来十年的增长预期。支持常用的 JDK 代码审查实践。程序化 API，可辅助或自动化审核和管理流程。 邮件发起后，参与者的意见明显分为两组：认为从 Mercurial 到 Git 会更方便的，以及已经习惯 Mercurial ，不认为折腾有啥好处的。对于 Project Skara 提出的建议你怎么看？欢迎评论。 |
