研发过程中，开发同学在接到一个需求后，必须要回答两个问题：做什么（WHAT）、怎么做（HOW）。本文就开发与测试在拆解需求时面临的共性问题，结合自己过往的经验，总结的一个实用的方法。本文不讨论技术选型，仅从思考逻辑上总结应该如何拆解与实现一个给定的需求。欢迎讨论。
大型电商系统并非一开始就具有完整设计的高可用特性，而是随着用户的不断增加与业务的快速增长逐步演进与完善的。当前高可用架构体系是互联网企业系统架构的基础要求，随着公司的业务发展，尤其是对于电商平台，每次发生稳定性故障带来的影响越来越大，提供稳定的服务，保证系统的高可用已经变成了整个技术团队需要面对的挑战。 基于此，我们深度采访了得物技术团队核心成员，探索他们在高可用架构上的实践、演进，深入了解大促备战是如何进行的，异地多活体系是如何建设的，全链路压测是怎么实践的等过程。
阿里很早就开启了线上交易应用部署单元化，因为交易单元化部署要比简单的应用服务单元化难度大很多，首先要涉及到写操作，其次交易时涉及到用户的多项资产的写，例如交易下单会涉及到商品信息（价格）、买家信息（积分）、优惠信息（优惠券）、库存等多重信息，商家可能会修改商品的价格、库存数量等，这些信息本身就是多点写的，控制不好就会出现数据一致性问题。 将交易数据完全按照某一维度进行单元化的拆分比较难，所以尽量让交易的强依赖的数据做到单元闭环，若依赖的数据做跨单元异步调用，降低交易链路的复杂性是必须的一个选择。
使用kafka可以对系统解耦、流量削峰、缓冲，可以实现系统间的异步通信等。在活动追踪、消息传递、度量指标、日志记录和流式处理等场景中非常适合使用kafka。这篇文章主要介绍下kafka中的基本概念。
工作中经常有人聊起交互跟产品的差别是什么？交互跟UI的差别是什么？似乎从入行至今，都一直有过这样的声音。互联网红利期的逐步消退，资本紧缩，压缩人力成本似乎成了一件趋之若鹜的事，所以早年阿里提出了全栈设计师、全栈工程师的概念，但本质上各种细分岗位的工作一直都存在，从未消失过，只不过以不同的形式被平摊了，但效果却难以说是好的。下面将去抛砖引玉的探讨交互设计价值点，并聊聊能否被兼并或取代。
Kubernetes 中应用实例数设置有固定实例数、HPA 和 CronHPA 三种策略。使用最多的是固定实例数，但是很多业务都存在波峰浪谷，如果采用固定实例数的方式会造成较大的资源浪费。Kubernetes 中提供了 HPA 及 CronHPA 两种机制实现按需扩容实例数量，减少资源浪费。CronHPA 是用户设定定时规则，在固定时间进行实例数伸缩。但是设定定时规则较为复杂，如果定时间隔设置较大就会造成资源浪费。HPA 可以根据应用实时负载设置实例数量，当应用负载高时扩容，当应用负载低时则缩容实例。HPA 是基于实时负载进行扩容，只有当负载已经比较高时才会触发扩容，但此时业务已经处在高负载中因此业务部分流量出现响应慢或者超时的问题，即存在“弹性滞后”的问题。为此，我们提出了一种智能化弹性伸缩方案 AHPA，可以根据历史时序数据进行主动预测，提前扩容，避免弹性滞后。同时，会根据实时数据动态调整主动预测结果，兼容周期变动等场景。
