支付宝架构学习笔记

在InfoQ上看了支付宝架构的介绍视频： http://www.infoq.com/cn/presentations/alipay-elastic-computing-architecture

感触颇深，前绝大多数系统的架构只做到了面向服务的架构，在弹性架构、高可用性等方面还有很多的工作要做，结合我所在公司的状况，我觉得如下一些点可以借鉴和考虑：

1）系统间的调用：支付宝使用了注册中心的方式来统一服务间的调用，这一点和淘宝的HSF http://wenku.baidu.com/view/c8e045f39e31433239689393.html比较类似（阿里还有一个叫做Dubbo http://code.alibabatech.com/wiki/display/dubbo/Home-zh的框架，是去中心化的架构，哪一种方式比较好比较难讲，个人更偏向于注册中心的方式，因为管理上更方便一些，至于单点失效的问题，由于注册中心的功能比较简单，基本上可以保证比较高的可用性），觉得系统间的调用需要做到如下几点：
    . 透明性：即服务的调用者不需要知道被调用者部署在哪一个节点上
    . 可追踪性：一个节点依赖了哪些服务、被哪些服务依赖，可以方便的查到
    . 避免单点失效
使用统一的框架来实现系统间的调用还是很有必要的。

2）使用框架来实现分布式事务：在交易类的系统里面有很多这样的场景（其他很多系统也应该有类似的需求），即数据库拆分之后（甚至有些任务执行的不是数据库操作）需要实现各个子任务的一致性，采用框架来实现是一个不错的方案

3）分布式锁：额外提供服务来支持分布式锁，避免使用数据库的方式进行select for update. 这样可以很大程度上减少数据库的压力

4）系统间的调用包括数据库事务，设置比较短的超时时间，避免由于部分系统不可用，导致大规模超时，占用了线程资源、数据库连接资源等，从而导致系统崩溃；

5）服务的优雅降级：这一点和No.1也是有关联的，将系统间的依赖分为强依赖和弱依赖，当需要系统降级时，会将部分弱依赖的服务调用切断，保证主要服务可以正常执行；

6）良好的监控系统：尽可能短的时间内发现问题；

7）故障切换：之前还比较奇怪，为什么同样是一个银行付款出了问题，我们的支付网关上相应的银行就不能付款了，但是支付宝却可以，原因就是支付宝可以做到检测到故障以后自动切换到该银行其他可用的渠道上去。

还有些其他的值得借鉴的地方，比如自定义容器，将容器扩展，不过这样的事情不是规模很大的公司，很难会做。