开发中我们经常会用到异步方法调用，具体到代码层面，异步方法调用的实现方式有很多种，比如最原始的通过实现Runnable接口或者继承Thread类创建异步线程，然后启动异步线程；再如，可以直接用java.util.concurrent包提供的线程池相关API实现异步方法调用。 如果说可以用一行代码快速实现异步方法调用，那是不是比上面方法香很多。 Spring提供了Async注解，就可以帮助我们一行代码搞定异步方法调用。Async注解用起来是很爽，但是如果不对其底层实现做深入研究，难免有时候也会心生疑虑，甚至会因使用不当，遇见一些让人摸不着头脑的问题。 本文首先将对Async注解做简单介绍，然后和大家分享一个我们项目中因Async注解使用不当的线上问题，接着再深扒Spring源码，对Async注解底层异步线程池的实现原理一探究竟。
测试流水线经过多个迭代准入准出的实践应用，基本完成了线上化、标准化以及流程自动化提升，目前客服域已实现100%的应用通过测试流水线准出完成测试。当前在商家和ERP推广，大家一起来了解下测试准出流水线是什么，解决什么问题，又需要如何接入和线上化应用。
现代软件部署中，容器技术已成为不可或缺的一环，在云计算和微服务架构中发挥着核心作用。随着容器化应用的普及，确保容器环境的可靠性成为了一个至关重要的任务。这就是容器SRE（Site Reliability Engineering，站点可靠性工程）的职责所在。容器SRE工程师不仅要保证系统的高可用性，还需要优化运行效率，确保系统在各种压力和突发情况下的韧性。 然而，容器SRE的工作常常是背后默默的付出，通常涉及着大量看似琐碎却极其关键的维护任务。例如某一天，你可能发现K8s集群中的Kubelet进程CPU使用异常飙高，这就需要容器SRE工程师立即介入，进行深入的诊断和问题排查，避免类似问题成为生产环境中的隐患。这种排查过程往往涉及复杂且难以预测的环境，通常需要SRE工程师具备高度的专业知识和快速应变能力。因此，虽然容器SRE工程师的努力可能不为大众所见，但对于现代依赖软件和云服务的任何系统来说，这些工作显得尤为严谨和重要。 通过本文，我们将深入探讨容器SRE在日常工作中面临的挑战和如何通过专业技能和创新技术方案来定位和解决问题，确保技术平台的稳健运行。
随着得物业务的快速发展，积累了大量的时序数据，这些数据对精细化运营，提升效率、降低成本有着重要作用。在得物的时序数据挖掘场景中，时序预测Prophet模型使用频繁，本文对Prophet的原理和源码进行深入分析，欢迎阅读和交流。
Babel是一个比较庞大的项目，其子工程就有至少140个(如 babel/plugins/presets/lerna/babel-loader等)，产出的子工具已经是前端开发的基础设施，对开发效率、代码质量等有非常高的要求。 在本文中，我们将了解Babel是怎样进行项目管理的。
搭建一个落地页需要涉及到多方合作，需要不断地进行沟通协调。繁杂的流程需要耗费很多的时间，因此我们推动产品重新搭建了一个专门服务于软广投放流程的编辑器——星创，完成广告搭建在投放业务各系统中的闭环。
Pulsar作为新一代MQ中间件，在底层架构设计上充分贯彻了存算分离的思想，broker与Bookeeper两个组件独立部署，前者负责流量的调度、聚合、计算，后者负责数据的存储，这也契合了云原生下k8s大行其道的时代背景。Bookeeper又名Bookie ，是一个单独的存储引擎。在组件关系上，broker深度依赖Bookie，内部集成了 Bookie的client端，broker和Bookie之间基于TCP通信，使用protobuf。
领域驱动设计简称“DDD”，一套“知易行难”的方法论。同时我所工作的这些年，尤其在某大厂做初创项目的那段时间，经常会产生各式各样的“思想碰撞”，特别在设计中台基建类领域时，为了保证充足的扩展性和稳定性，都要好好的“碰撞”一下。虽然在设计过程中，每个人的想法不尽相同，但是最终达成一致的那一刻，每个人的技术思想都会得到提升。 对于DDD，我的观点是，它是一套非常优秀的能提升个人认知高度的方法论。注意，我说的是个人认知，不仅是它所带来的业务和团队价值（它所带来的业务和团队价值会在下面讲）。它的战略设计方法论能很好提升技术人员的全局视野，它的战术设计方法论也能强化个人的技术细节把控力和结构性思维。除此之外，好的DDD设计也反映出一个技术人员对于业务的理解力，往往优秀的领域专家也是半个业务专家。 如果你一直困惑于自己究竟该如何提升技术和业务思考能力；如何提升全局视野，提升自己的结构化思维的能力；如何在写了这么多代码，做了这么多需求的情况下，补充系统化的技术理念。如果这些疑惑点你都涉及，那么理解DDD，同时按照DDD的方式去思考和建设，能够为你带来显著的提升。
