公司：阿里巴巴
阿里巴巴集团创立于1999年，是中国大陆一家以提供互联网服务为主的综合企业集团，目前实行位于杭州，上海与北京的双总部制度。
阿里巴巴服务范围包括B2B贸易、网上零售、购物搜索引擎、第三方支付和云计算服务。集团的子公司包括阿里巴巴B2B、淘宝网、天猫、一淘网、阿里云计算、聚划算、全球速卖通、阿里巴巴国际交易市场、饿了么、飞猪、优酷、盒马鲜生、阿里影业、菜鸟网络、高德地图、Lazada、Daraz等。旗下的淘宝网和天猫在2012年销售额达到1.1兆人民币，2015年度商品交易总额已经超过三兆元人民币，是全球最大零售商。
至2012年九月底止的财政年度，以美国会计准则计算，阿里营业额按年增长74%至318.39亿元（港元‧下同），盈利急升80%至37.75亿元。2015年全年，阿里巴巴营收146.01亿美元，净利为74.94亿美元。2017年，根据阿里巴巴集团向美国证券交易委员会提交的IPO招股书显示，雅虎持有阿里巴巴集团22.6%股权、软银持阿里集团34.4%股份，另管理层、雇员及其他投资者持股比例合共约为43%，当中马云持阿里巴巴集团约8.9%、蔡崇信持股为3.6%。
2019年11月，阿里巴巴集团在在港交所二次上市。香港财经界把阿里巴巴、腾讯（港交所：700）、美团点评（港交所：3690）、小米（港交所：1810）四只中国大陆科技股的英文名称首个字母，合称“ATMX”股份。
2019年11月26日，阿里巴巴集团港股上市，总市值超4兆，登顶港股成为港股“新股王”。2020年8月，阿里巴巴集团港股总市值首次超过6万亿。
阿里巴巴拆份出去的蚂蚁集团上市前，网络金服整体遭遇到政府的强力监管，阿里巴巴同样受到影响，2021年4月10日，阿里巴巴集团涉垄断被中国市场监管总局罚款182.28亿元人民币。2023年三家中国最主要的金融机构，再联合开罚71亿元，不过也随着官方宣布最后整顿工作的完成，阿里巴巴股价开始反弹。
分布式系统一致性测试框架Jepsen在女娲的实践应用
这里我们按照本质、结构、作用 的顺序简明地描述Jepsen。
iOS 性能检测新方式——AnimationHitches
AnimationHitches 主要用于代替帧率检测，并且提出 卡顿时间比(Hitch Time Ratio) 的概念用于替代 FPS。
ABF平台设计（二）-流水线的配置器
ABF平台的配置中心又可以称之为渲染中心，负责所有应用的渲染数据与渲染功能配置。
400倍加速, PolarDB HTAP实时数据分析技术解密
PolarDB技术团队提出了In-Memory Column Index(IMCI）的技术方案，在复杂分析查询场景获得的数百倍的加速效果。
端智能研发核心套件：MNN 工作台深度剖析
一文揭开算法研发效率提升利器的神秘面纱。
形式化验证工具TLA+：程序员视角的入门之道
本文从程序员视角介绍形式化验证工具TLA+。
Flutter难点问题之GPU后台Crash
还在为Flutter GPU后台Crash而苦恼吗，快进来看看吧！
Java单元测试技巧之JSON序列化
本文统性地总结了JSON序列化在编写Java单元测试用例中的使用技巧。
阿里靠复盘，复出了什么？
人才复盘要有去留，业务复盘要有取舍。
在多模态训练中融入“知识+图谱”：方法及电商应用实践
随着人工智能技术的不断发展，知识图谱作为人工智能领域的知识支柱，以其强大的知识表示和推理能力受到学术界和产业界的广泛关注。
阿里技术专家详解DDD系列 第二弹 - 应用架构
架构这个词源于英文里的“Architecture“，源头是土木工程里的“建筑”和“结构”，而架构里的”架“同时又包含了”架子“（scaffolding）的含义，意指能快速搭建起来的固定结构。而今天的应用架构，意指软件系统中固定不变的代码结构、设计模式、规范和组件间的通信方式。在应用开发中架构之所以是最重要的第一步，因为一个好的架构能让系统安全、稳定、快速迭代。在一个团队内通过规定一个固定的架构设计，可以让团队内能力参差不齐的同学们都能有一个统一的开发规范，降低沟通成本，提升效率和代码质量。
在做架构设计时，一个好的架构应该需要实现以下几个目标：
- 独立于框架：架构不应该依赖某个外部的库或框架，不应该被框架的结构所束缚。
- 独立于UI：前台展示的样式可能会随时发生变化（今天可能是网页、明天可能变成console、后天是独立app），但是底层架构不应该随之而变化。
- 独立于底层数据源：无论今天你用MySQL、Oracle还是MongoDB、CouchDB，甚至使用文件系统，软件架构不应该因为不同的底层数据储存方式而产生巨大改变。
- 独立于外部依赖：无论外部依赖如何变更、升级，业务的核心逻辑不应该随之而大幅变化。
- 可测试：无论外部依赖了什么数据库、硬件、UI或者服务，业务的逻辑应该都能够快速被验证正确性。
这就好像是建筑中的楼宇，一个好的楼宇，无论内部承载了什么人、有什么样的活动、还是外部有什么风雨，一栋楼都应该屹立不倒，而且可以确保它不会倒。但是今天我们在做业务研发时，更多的会去关注一些宏观的架构，比如SOA架构、微服务架构，而忽略了应用内部的架构设计，很容易导致代码逻辑混乱，很难维护，容易产生bug而且很难发现。今天，我希望能够通过案例的分析和重构，来推演出一套高质量的DDD架构。
阿里技术专家详解 DDD 系列- Domain Primitive
对于一个架构师来说，在软件开发中如何降低系统复杂度是一个永恒的挑战，无论是 94 年 GoF 的 Design Patterns ， 99 年的 Martin Fowler 的 Refactoring ， 02 年的 P of EAA ，还是 03 年的 Enterprise Integration Patterns ，都是通过一系列的设计模式或范例来降低一些常见的复杂度。但是问题在于，这些书的理念是通过技术手段解决技术问题，但并没有从根本上解决业务的问题。所以 03 年 Eric Evans 的 Domain Driven Design 一书，以及后续 Vaughn Vernon 的 Implementing DDD ， Uncle Bob 的 Clean Architecture 等书，真正的从业务的角度出发，为全世界绝大部分做纯业务的开发提供了一整套的架构思路。
阿里技术专家详解DDD系列 第三讲 - Repository模式
这篇文章和《阿里技术专家详解DDD系列 第二弹 - 应用架构》隔了比较久，一方面是工作比较忙，另一方面是在讲Repository之前其实应该先讲Entity（实体）、Aggregate Root（聚合根）、Bounded Context（限界上下文）等概念。但在实际写的过程中，发现单纯讲Entity相关的东西会比较抽象，很难落地。所以本文被推倒重来，从Repository开始入手，先把可以落地的、能形成规范的东西先确定下来，最后再尝试落地Entity。这个当然也是我们可以在日常按照DDD重构时尝试的路径。
提前预告，接下来的一篇文章将覆盖Anti-Corruption Layer（防腐层）的逻辑，但是你会发现跟Repository模式的理念非常接近。等所有周边的东西都覆盖之后，再详细讲Entity也许会变得不那么抽象。
DDD 的宏观理念其实并不难懂，但是如同 REST 一样，DDD 也只是一个设计思想，缺少一套完整的规范，导致DDD新手落地困难。 我之前的架构篇主要从顶层设计往下看，从这一篇开始我希望能填补上一些 DDD 的代码落地规范，帮助同学在日常工作中落地 DDD 思想，并且希望能通过一整套规范，让不同的业务之间的同学能够更快的看懂、掌握对方的代码。但是规则是死的、人是活的，各位同学需要根据自己业务的实际情况去有选择的去落地规范，DDD 的规范不可能覆盖所有场景，但我希望能通过解释，让同学们了解 DDD 背后的一些思考和取舍。
原来下拉除了刷新，还能这么玩！
“下拉刷新专利由推特拥有，但我想任何人都不用为此担心。-Loren Brichter ”
据说这种交互是前苹果设计师L.B.设计Tweetie应用时缔造的，现在从推特到QQ，下拉刷新已经成为普适的体验，它几乎存在于你手机里的每一个APP中。
浏览器中的 ESM
本文主要介绍下模块化标准间差异、基本加载原理。
Pixel-如何建立设计系统中的色彩体系
体系由「设计理念+设计规则+设计物料」构成；而「设计规则」包含了「色彩+图形+排版...」等体系，它们确保了设计系统之所以是系统，其中「色彩」是品牌映射至产品实体、展现平台人文的关键要素。