第一章，阿里技术架构演进

1、金融级系统的6个关键支撑目标：

a、高可用--实实在在的4个9。系统可以容忍各种硬件故障，可以在服务不中断的情况下升级，关键系统，具备异地容灾能力

b、安全 --及时，多层次检测防御安全攻击 ，具备快速阻断大规模有组织的攻击

c、性能 --实时交易--并发能力，批量交易--吞吐能力，系统具备可伸缩，快速平行增加资源情况下满足突发的业务量

d、成本 --单笔交易成本，峰值交易处理成本 作为关键指标进行成本优化。

e、资金安全 --交易与数据的强一致性，具备准实时的交易资金核对能力。

f、数据质量 -- 数据的准确，完成和及时性。

2、OceanBase：金融级分布式数据库

  商业数据库成本高昂，扩展困难。OceanBase已支撑了阿里的核心交易及账务系统。--建议尝试使用。

3、全链路压测:世界级的创新，帮助了阿里充分评估自己的系统性能弱点及资源规划，--建议尝试使用。

4、单元化架构

单元化架构可实现异地多活－阿里为三地四中心，并可动态扩展。

实现思路：系统单元化演进--把大系统拆分成相对独立的小规模系统，每一个单元系统可以部署到任何地点的数据中心，实现异地多活。

单元化架构的关键特性：

a.自包含性--比如一次充值交易，涉及到的所有计算与数据都在一个单元内完成；

b.松耦合性--跨单元只能进行服务调用，不能直接访问数据库，在用户体验允许的情况下尽量采用异步处理；

c.故障独立性--一个单元的故障，不能传播到其他单元；

d.容灾性--单元之间互相备份；

5，金融级中间件

6.弹性混合云。

第二章，稳定，双11的生命线

1，阿里的全链路压力测试，是个伟大的发明，可在线上进行真实的全链路压力测试，实现关键：

a、线上数据的同步和创建，

b、压力模型系统,

c、隔离系统，防止对线上交易的影响（流量隔离，时间控制（修改jdk8的jvm时钟））

d、构造执行系统。

e、事后分析系统

关键原则：建立一套线上影子体系满足流量隔离

2.实时业务审计系统（BCP）

目标：业务数据的正确性，保证系统可用性及业务正确

a.配套数据链路排查工具，trace产品－－鹰眼系统，监控及定位问题。

b.数据修复平台--实现发现问题后的自动修复。

3、故障治理

重视系统间的依赖关系，任何非核心业务均可能影响核心业务。 

故障治理有效手段：故障重现，故障演练，故障突袭。

3.系统自我保护，稳定性的最后一道墙

建立系统保护体系：

a、限流

b、非关键业务的自动降级

c、流量调度

d、负载保护

e、重视预案的力量

    自动发现问题是根本，在人为不干预的情况下自动处理，通过系统自我保护，让问题自愈。

对于突发情况，预案的准备及执行的透明是关键

第三章，技术拓展商业边界

花呗风控系统应用架构

注重压力测试／应急预案 的重要性。

第四章，移动端的技术创新之路

1.weex的大规模应用：兼容了H5和Native的优势，优点：发布快，流畅度高。建议推广。

2.tmf框架演进：交易平台作为电商的核心平台之一，承载着各类电商业务，而这些业务之间的业务逻辑差异非常大，TMF平台则是对这些业务的抽象功能封装，保证各类交易开发的一致性，尽可能复用原有经验。

基于TMF框架的交易平台架构

第五章，繁荣生态，赋能商家

      1、聚石塔

－－提供IT基础设置及数据云服务，链接淘宝开放平台，为商家个性IT需求进行支撑。

      2、阿里中间件产品系列

－－ 解决如何使设计出的平台具备真正意义上的线性扩展能力，不管业务如何增长，平台都能快速的应对业务的访问。－－aliware

3、蚂蚁金服 金融机构间的协同运维的探索和实践

     日常运行时由多根专线分担交易流量，对通信成功率的关键指标进行监控

－－建立机构能力检测平台：自动以真实的业务的要求向下游系统及银行机构发起交易流量，使用真实的卡和资金，测试完成后自动回流。

－－机构间自动化运行管理：限流，根据策略，分析网络／银行出现异动的情况下，采用支付宝侧拦截并引导用户使用其他支付工具的方式。自动以秒计方式进行调整。

－－自动化，秒级的自动流量管控。尽量提高反射弧（发现到完成自动决策，包括限流，切换通道等）的效率；2016年双11，银行渠道相关业务自动化率达到89%，零点高峰达到96%，交易管控已经自动化处理。

－－蚂蚁金服与银行开放互动的优化机制，双方报警打通，系统监控打通。快速定位故障源。

－－支付机构与金融机构的运维协同体系：从人工＋自动化 －》 开放＋智能

本文出自 “技术论坛-天使之城” 博客，请务必保留此出处http://zhangmeng.blog.51cto.com/310854/1923229

《尽在双11》－－阿里巴巴技术演进与超越 读书笔记