历史上 90%的故障源于业务新版本上线，如何最大化保障功能迭代过程中业务流量无损一直是开发者比较关心的问题。尤其对于分布式架构的微服务应用而言，服务之间的依赖关系错综复杂，一个业务功能需要多个微服务共同提供能力，一次业务请求需要经过多个微服务才能完成处理，牵一发而动全身。业务的发展需要应用系统不断的迭代，我们无法避免应用频繁变更发版，但是我们可以提升应用升级过程中的稳定性和高可用。
包大小是衡量APP性能的一项重要指标，它直接影响用户的下载点击率（包太大不想下）、下载安装成功率（下载慢不用了）、APP卸载率（太占空间先删掉）。 包大小的计算逻辑很简单，它是各种类型的文件占用磁盘大小相加。APP瘦身的技术却很复杂，代码文件的复杂度和编译器策略决定了可执行文件的大小，业务功能和工程架构决定了代码文件的复杂度。iOS APP瘦身，需要掌握的技能有XCode构建技术、LLVM编译器技术、CocoaPods构建技术、图片压缩技术、持续集成技术。 本文总结提炼了Alibaba.com App的瘦身的技术和策略，系统化地介绍APP瘦身的业务价值、分析技术、瘦身技术、防劣化机制，让读者可以系统化地了解APP瘦身的技术体系。本文还基于实践经验，介绍各种瘦身技术的ROI，让读者可以避免踩雷，将资源浪费在效果不佳的技术上。希望对你有所帮助。
搜索是电商平台的核心流量入口，承载着平台主要的成交引导、意图收敛、活动投放。一个稳定、高效、可扩展的搜索系统是电商平台得以生存发展的基石。本文探讨如何构建完善的商品搜索系统， 并根据闲鱼二手交易的差异化特性介绍闲鱼搜索系统的时效性优化。
本文提出了HTTP协议在目前网络传输中存在的问题，然后基于两个典型问题做了合理的方案设想，最终推演出的第四种方案。
研发过程中，开发同学在接到一个需求后，必须要回答两个问题：做什么（WHAT）、怎么做（HOW）。本文就开发与测试在拆解需求时面临的共性问题，结合自己过往的经验，总结的一个实用的方法。本文不讨论技术选型，仅从思考逻辑上总结应该如何拆解与实现一个给定的需求。欢迎讨论。
阿里很早就开启了线上交易应用部署单元化，因为交易单元化部署要比简单的应用服务单元化难度大很多，首先要涉及到写操作，其次交易时涉及到用户的多项资产的写，例如交易下单会涉及到商品信息（价格）、买家信息（积分）、优惠信息（优惠券）、库存等多重信息，商家可能会修改商品的价格、库存数量等，这些信息本身就是多点写的，控制不好就会出现数据一致性问题。 将交易数据完全按照某一维度进行单元化的拆分比较难，所以尽量让交易的强依赖的数据做到单元闭环，若依赖的数据做跨单元异步调用，降低交易链路的复杂性是必须的一个选择。
