可扩展的架构方案的一些思考

构建故障隔离的架构

故障隔离架构

经常把故障隔离架构比喻成泳道，对于游泳选手，泳道既代表了障碍也代表了引导。障碍物的存在是为了确保游泳选手产生的波浪不进入另一个泳道，干扰其他游泳选手。在比赛中，这有助于确保选手不受干扰。
在架构中，泳道以类似的方式保护系统。在泳道内，一个系统的操作局限在该泳道的隔离带内，而不会交叉影响到其他泳道的操作。此外，泳道为设计新功能的架构师和工程师提供引导，帮助他们决定哪些功能应该放在哪类泳道，向高可扩展性的架构目标前进。
类似的比喻还有豌豆荚（Pod, docker中的术语）

故障隔离的好处

1. 故障隔离和可用性：
   1. 限制影响
   2. 有利于时间检测和分辨

如果进行故障隔离

1. 绝不共享（也称为“共享越少越好”），泳道共享的越少，其故障隔离度就越高。如果某两条泳道共享一个数据库，他们实际上是同一个泳道，而不是两个不同的泳道。从服务的角度看，如果有两个较小的故障隔离区，当一个应用服务器失败时，这样的隔离会有所帮助。然而，当数据库失败时，两个泳道都会失败。
2. 泳道的边界不可逾越。同步通信从不跨域泳道。如果跨越了泳道，那么边界划分是不正确的。
3. 交易发生在泳道旁边。不可能建立多服务泳道，因为那些服务通信将违反原则2。

何时实施故障隔离

大案主要取决于特定的需求、增长率、不可用率、系统不可用的原因、客户期望的可用性以及对用户的可用性承诺。以下是一些有用的规则：

1. 泳道与盈利：盈利的泳道（千万别把收款机和其他系统混在一起）。
   把与盈利关系密切的事情和可能失败及有需求限制的其他系统适当的隔离。如果你经营的是电子商务网站，那么与盈利关系密切的可能是购买流程。包括从购买按钮，结算直到信用卡处理的全过程。
2. 泳道是事故的最大来源。确定造成反复发生问题的根源，然后隔离他们。
3. 泳道的天然隔离。客户的边界是最好的泳道隔离索。

为扩展分割应用

AKF应用扩展立方体：

1. X轴代表复制应用或服务，这样就可以很容易地把工作无差别地分配到实例中去。一方面，X轴的方法很容易概念化，通常能以较低的成本实施。另一方面，x轴的实施受紧密耦合的单体应用增长的限制，这往往会延迟交易处理。
2. Y轴代表应用的工作责任安装服务或功能分割。解决复制的代码和数据集不断增长所带来的问题。
3. Z轴代表在交易时基于属性查找找或确定分割工作。通常，这些是按照请求者、客户或者当事人分割。它有助于提高灾难恢复能力，把事故影响限制在一部分特定的客户范围内。

融会贯通：
X轴分割是功能的镜像，Y轴分割基于工作分割应用，Z轴分割基于客户、位置或有一些特定标志的值（例如，一个hash值或取模的结果）

数据复制的延迟问题

通过以下问题来确定复制的数据：

1. 数据元素更新的频率是多少？ 如果读写的比例很高，复制延迟是否可以接受？ 如果更新频繁而读取罕见，那么复制几乎没有什么好处。
2. 所读的数据元素是否会用在计算中并在未来写入数据库？如果是，复制延迟可能是不可接受的。
3. 在决策目的中数据价值的区别是什么？例如，最新更新的变化值不大，但是这样的差异是否会真的对查看数据的人在决策的结果上产生影响？
4. 最后，在考虑数据库复制时，先看看本地数据库的功能。几乎从来没有必要自己研发复制功能。

扩展案例

1. 分离怪异数据

代理

1. 代理缓存：一般由互联网服务提供商（ISP）提供，以处理来自一组有限数量的用户对无限数量的应用或网站的请求。有限数量的用户可以是所有的服务用户或是处在同一地理范畴的用户子集。只有在一段时间内所请求的数据量达到了要求的最低水平，缓存才有意义。
2. 反向代理缓存：一般在网站服务器前实施。任何对该应用有访问权限的用户都可以使用缓存服务。反向代理缓存可以处理来自任何数量的用户对有限数量的网站的请求。

在多服务器环境下保存状态或保持会话。

三种方式：避免、集中和分散。

1. 避免：
   1. 完全删除会话数据
   2. 通过在代码中对用户取模数来关联用户和某个特定的服务器
   3. 通过会话Cookie从负载均衡器上把用户与特定服务器关联起来
2. 分散：
   1. 在浏览器的Cookie中存储所有会话的Cookie信息
   2. 存储会话Cookie作为会话对象的索引，所有信息存储在数据库或文件系统中
   3. 采用加密、hash算法单向验证
3. 集中
   1. 在一个集中的会话缓存系统中存储会话
   2. 也可以使用数据库，但是不推荐