在 ICE、Rax 等项目研发中,我们或多或少都会接触到 build-scripts 的使用。build-scripts 是集团共建的统一构建脚手架解决方案,其除了提供基础的 start、build 和 test 命令外,还支持灵活的插件机制供开发者扩展构建配置。 本文尝试通过场景演进的方式,来由简至繁地讲解一下 build-scripts 的架构演进过程,注意下文描述的演进过程意在讲清 build-scripts 的设计原理及相关方法的作用,并不代表 build-scripts 实际设计时的演进过程,如果文中存在理解错误的地方,还望指正。
一个IP报文如何跨越万水千山达到目的地?本文将以阿里云为例,带领大家一起探索同地域内云上通信的全过程,完整展现云上同地域内各种场景的IP报文之旅,深入理解云网络技术、产品和通信。
随着微服务的流行,服务和服务之间的稳定性变得越来越重要。在 2020 年,Sentinel 社区推出 Sentinel Go 版本,朝着云原生方向演进。Sentinel Go 是一个流量治理组件,主要以流量为切入点,从流量路由、流量控制、流量整形、熔断降级、系统自适应过载保护、热点流量防护等多个维度来帮助开发者保障微服务的稳定性。 无论是流量控制还是熔断降级,实现的核心思想都是通过统计一段时间内的指标数据(请求数/错误数等),然后根据预选设定的阈值判断是否应该进行流量管控 那么如何存储并统计这一段时间内的指标数据则是核心关键,本文将揭秘 Sentienl-Go 是如何实现的毫秒级指标数据存储与统计。
最近几年,钉钉迅速成为一款国民级应用。IM 作为钉钉最核心的功能,每天需要支持海量企业用户的沟通,同时还通过 PaaS 形式为淘宝、高德等 App 提供基础的即时通讯能力,是日均千亿级消息量的 IM 平台。 我们通过 RocketMQ 实现了系统解耦、异步削峰填谷,还通过定时消息实现分布式定时任务等高级特性。另外,过程中也与 RocketMQ 深入共创,不断优化解决了很多问题,并且孵化出 POP 消费模式等新特性,彻底解决了RocketMQ 负载粒度只能到Queue级别、rebalance导致时延等问题。
LSM-Tree全称为Log-Structured Merge-Tree,日志结构合并树,它的架构分为内存部分和有序的磁盘部分,内存部分实现高速写,有序的磁盘部分实现高效查。
Kubernetes作为云原生计算的基础项目,已经在开发者和企业中获得广泛的支持。然而其自身复杂性和陡峭的学习曲线依然让人望而生畏。在 CNCF 2020年度调研报告中,在Kubernetes技术落地过程中面临最大的挑战就是复杂性。 IBM大型机之父 Fred Brooks 著名的论文No Silver Bullet[1],软件系统中的复杂性可以分为本质复杂性 (essential complexity) 和附属复杂性 (accidental complexity) 。本质复杂性是构建系统过程中不可避免的复杂性。附属复杂性则是任何非必要的复杂性,比如由于设计失误或者工具不当等引入的复杂性。附属复杂性会随着工具的改善而逐渐解决,而本质性的困难难以解决。 Kubernetes的本质复杂性与附属复杂性到底有什么?我们应该如何应对?
什么是分布式锁?对于这个问题,相信很多同学是既熟悉又陌生。随着分布式系统的快速发展与广泛应用,针对共享资源的互斥访问也成为了很多业务必须要面对的需求,这个场景下人们通常会引入分布式锁来解决问题。我们通常会使用怎么样的分布锁服务呢?有开源的 MySQL,Redis,ZooKeeper,Etcd 等三方组件可供选择,当然也有集团内自研的 Tair,Nuwa 等分布式锁服务提供方。总的来看,我们对分布式锁的需求可以大体划分为以下两类应用场景:
TypeScript 已于 2022.09.23 发布 4.9 beta 版本,你可以在 4.9 Iteration Plan 查看所有被包含的 Issue 与 PR