InfoQ出品的《阿里巴巴技术迷你书》，里面介绍了许多阿里巴巴的案例，对架构理解有很强的帮助，建议大家阅读，开阔视野，提升境界。
（一）陶勇谈海量数据技术架构
1.数据需要从集中式走向分布式，实现水平拆分
2.大量数据支撑策略：1.压力分摊，集中转分布；2.多种存储方案（核心数据存oracle，做RAC；大表存mysql集群；弱关系数据KV-Store）
3.数据同步的三套产品：Erosa：Bin-log解析；Eromanga：增量数据发布订阅；Otter：数据双向同步
4.缓存需要注意的两点：1.切分粒度；2.生命周期，数据有效期
（二）潘磊谈阿里巴巴国际空间站
1.一般网站后台数据架构：数据库+搜索引擎+存储，让系统小型化，让读系统依附一些可线性扩展的cache，写系统集中到oracle或mysql上。
2.数据扩容问题解决思路：对数据进行水平拆分和垂直拆分，上端提供一致的访问手段自动进行路由，下端屏蔽对具体数据库的依赖。
3.成为一个真正的架构师：热爱技术，专研遇到的问题，成为行业的业务专家，善于学习书本知识和别人交流，针对薄弱环节系统性学习，勤于实践。
4.成为一个架构师，他必须要关心技术的所有外延，比如说操作系统、网络、存储，甚至数据库，所有关联到的东西。作为一个架构师，应该去全面的掌握问题，当然深度你可以根据应用的场景，可能会因场景而异，或者因人而异。
（三）潘磊谈阿里巴巴国际空间站
1.notify的核心特性是： 提供事务支持、不保证消息顺序、消息可能会重复、推模型
2.RocketQ(MetaQ) 主要面向消息有序的场景，能够提供更大的消息堆积能力
3.Notify主要面向需要更加安全可靠地交易类场景，无序，推模式
4.无状态节点可以任意扩容，通过随机算法或轮询的方式，有状态节点使用hash或tree做一层映射，同时需要考虑用数据扩容及迁移工具来配合节点扩容时的数据迁移。
（四）跨境网站的优化与挑战
1.建立性能基线系统，基线系统是对性能的关键指标，如DNS解析时间， StartRender、首屏加载时间、 Full load时间、服务端响应时间、应用峰值QPS建立了基线，当超过基线的20%，系统会报警到相关页面的负责人这里，负责人会关注并修复问题。
2.建立性能诊断系统，前端模拟浏览器行为，监控影像性能的因素，例如请求数、 Dom节点数、 html大小、图片大小和数量。
3.阿里前端优化实践经验：
- 减少http请求是非常有效的措施
- 减少重定向
- 预加载
- 尽量减少cookie的大小
- 延时加载
- Ajax异步化减少DOM的节点数，加快渲染时间， first byte时间
- CDN加速，加长资源过期时间，减少回源
- DNS预解析
- js不要放在头部阻塞浏览器并行渲染
4.确定优化重点和关键指标，建立长期的优化跟踪机制和完善的配套性能诊断体系
（五）淘宝交易系统演进
1.从单一整合功能的系统--->按技术服务拆分，通过服务框架发布查找服务--->引入消息框架解决高并发的处理问题--->将技术能力下沉到平台，支持上面的应用--->按业务将业务模块化，通过业务规则的灵活组合实现业务扩展
2.高质量的交易系统的7个特点：
- 第一，通过服务治理，把业务规则从原有功能中剥离，明确各个服务所提供功能的完备性及独立性，从系统边界上确保功能之间无耦合。
- 第二，通过集中式的业务规则管控，保证交易全链路的业务规则统一及业务规则灵活可配置。
- 第三，通过标准化的交易框架及组件化设计，保证服务在交易平台快速接入。
- 第四，通过异步并行及容错，提升系统响应速度，减少单点服务故障导致的整体不稳定。
- 第五，通过开关及预案机制，保证代码的兼容性发布，业务降级容错。
- 第六，通过流量管控，防止雪崩，保证在正常情况或者某个服务集群能力波动时，整个交易系统不被压垮。
- 第七，通过在前端应用中做前后端解耦，通过约定的数据模型，前端开发只负责页面展示和交互，实现前端、后端的并行开发，也使得不同终端的自适应可以以较低成本实现。
3.应对交易洪峰：流量管控机制，超出服务能力的请求拒绝，同时引导用户到静态化的页面上去
（六）蔡学镛谈CEP
1.衡量CEP功能的两个因素：EPL语言和分析引擎的效率