eBay Architecture(3)--What do we think about?_graceful degradation or fault tolerance-CSDN博客

在考察一个项目的时候，architect主要从以下5个方面考虑问题：

Scalability(可扩展性)
1. Resource usage should increase linearly(or better!) with load。项目的设计必须满足当负载增加的时候，用于支持这些负载的资源必须是线性增加而不是指数增加的。这里的负载指流量(traffic)，用户数(user)，数据量(data)...。
2. Design for 10x growth in data,traffic,users,etc。做最初设计的时候就必须考虑到如果load是现在的10倍该怎么办。
Availability(正常工作比例)

1999年eBay曾进出现过站点24小时瘫痪的情况。Availability就是指系统的可正常工作性。OPS的大头头最关心的就是每年的Availability是99.6%还是99.9%，还是99.96%...

Resilience to failure。系统纠错能力，我们当然希望能够很好的handle一些日常的错误，有些错误，系统自己就能修复。
Graceful degradation。如果你查一下http://en.wikipedia.org/wiki/Fault-tolerant_system 就可以看到graceful degradation的定义，和fault-tolerance是一个意思。其核心思想就是不能让单点崩溃导致系统崩溃(don't let single point failure evolve into system failure)，并且希望如果你有10%的capacity失效了，那整个系统的性能下降也应该在10%以内。这里Randy举了一个例子，如果你有100台机器的一个系统，但是所有的业务都要经过其中的一台机器，那如果这台机器崩溃的话，整个系统就崩溃了。不要说，这台核心机器绝对不可能崩溃，任何问题都有可能出现，而且，你越说这台机器不可能出问题，我敢说，第一个出问题的多半就是那台机器。
Recoverability from failure。万一很不幸，出错了，无论市单点错误还是系统错误，你是不是有一揽子方案，能够迅速得从错误中恢复过来，时间就是金钱。

Latency(延时)
1. User experience latency。这直接影响用户体验，想象一下我用PPS看电影，一顿一顿的我肯定不爽。
2. Data latency。数据在eBay系统内部传输的延时。
Manageability(可管理性)

这是Operation Team很关心的一个问题。开发团队做好一个产品以后，是Operation Team在管理，OPS要保证站点一天24小时，一年365天正常运行。

1. Simplicity。管理起来是不是简单，方便。
2. Maintainability。是不是便于维护。
3. Diagnostics。这点非常重要，一定要有方法追查错误，系统性能下降了，我们怎么发现问题，eBay是有一套系统来进行Disgnostics的，但是员工的knowledge也非常重要，系统大了以后，一个模块要和很多模块打交道，诊断的时候非常重要的一点就是在问题发生的那个点，要对整个环境有全局的认识。
Cost(成本)
1. Development effort and complexity。开发成本。工程师的时间是很贵的，PD,QA,PJM...很多人呢。不同的方案复杂性不一样，要买的硬件也不同，哦，对了，机器也很贵的，特别在eBay买机器可不是一台两台啊。
2. Operation cost(TCO)。运营成本，MIT,DBA都是高学历人材，每个月都要发工资的。还有这么多设备，每天要好多少电啊，设备放在什么地方，房租呢...很多很多问题的。

上面说的5点很重要，这告诉了我们Architect的思维模式，知道了他们关心的事情，我们以后跟Architect打交道的时候就会好很多，一些问题在工程师做设计的时候就能开始考虑了。当然在eBay的流程上来说也会保证这一点，如果你的项目大到一定程度，就会要求involve architect，开会讨论，最后要architect approval这个方案的。