发布了 41 篇内容
共 43323字, 被阅读 1788次
获得了 4 次赞同
获得了 0次喜欢, 获得了 4 次收藏
参与了 3 次互动
互动包含发布评论、点赞评论、参与投票等
架构误区系列 6:万物异步化
异步化,是在分布式架构中为了解决容量问题、重试逻辑比较常用的一个技术手段。包括通过消息和通过定时任务。但是最近在做架构 Review 的过程中,发现了有过度使用异步化的趋势。
支付 API 设计
最近在做外汇产品的 API Review 工作。国外的 API 基本都是 Restful 的,包括 Payal、Wise、Adyen,现在都基本提供了 Restful 的 API 了,但是国内目前看微信、支付宝等都还没有往 Restful 上走。
架构误区系列 5:滥用分布式锁
分布式锁是在分布式系统中比较常见的一个组件,同时也是各面试官比较喜欢问的问题 ^_^ 分布式锁主要作用就是对关键资源的重入保护。但是,分布式锁并不是处处适用,有很多场景下其实是没必要用到这么重的架构组件的。
架构误区系列 4:volatile task
本期的架构误区系列关于一个领域建模的问题,针对的是一个常见的场景:一个单据创建后,在后续的特定时间需要触发一个任务的执行,但是如果单据修改,这个任务的执行时间点和内容就会发生变化。针对这种场景,应该如何设计这个任务触发的机制呢?
架构误区系列 3:单元测试依赖外部环境
单元测试,是大家日常工作中都经常用到的第一层保证软件质量的手段。但是由于各种依赖问题,在日常的研发活动中却经常掉链子:上千个 UT 的 case,每次跑都会随机挂几个;跑一次都要一个多小时,一天跑 20 多次才能有一两次稳定的结果。
架构误区系列 2:exactly once 的消息中间件不需要考虑消息重投
消息队列是大家在架构设计中比较常用的中间件。消息队列对消息投递的可靠性保证包括 at most once、at least once 和 exactly once。exactly once 的消息队列,在消费方是不是就不需要考虑消息重复投递的幂等性处理?
架构误区系列 1:简单依靠扩容解决容量问题
大促,或者业务增长,造成短时流量激增的场景下,是否通过扩容就可以解决问题。
架构误区系列(Architecture Pitfall)
架构误区系列,会重点通过一些案例的分析,点出一些似是而非的架构设计。本系列旨在为大家在架构实践提供基于案例的指引,希望对大家有所帮助。
服务怎么升级
大家日常都会面临服务升级的挑战。由于业务和客户诉求的升级,就需要同步的做服务升级。但是服务升级面临众多的挑战,包括兼容性、稳定性、维护多个版本的开发工作量等。综合在支付资金领域多年的服务化实践,服务升级最好的做法其实是有限升级模式。
软件架构 & 研发效率
对于大型互联网公司而言,研发效率应该也是一个永恒的话题。4000 人的飞书,动辄几千人的国际支付团队。其实业务也就那点,人不少,看着还要天天加班,目测上效率就有很大的问题。那如何提升软件研发的效率呢?
定时任务:历史 & 应用
在现实生活中,有许多需要定时执行的操作。比如:每日 / 每月计算利息、每月的财务报表、月底的工资发放等等。在软件中,我们一般通过定时任务来实现。
消息中间件:概念 & 应用
消息中间件,俗称消息队列,是在分布式架构中应用较广泛的一种基础组件。采用消息中间件可以达到应用解耦和削峰填谷的目的。本文主要介绍消息中间件的一些基本概念以及在实际场景中的应用模式。
最新评论
中台 vs 平台