避免故障造成更大影响的方法论
这也只是美好的愿景,就是画的大饼。——ljl
从系统的角度来看,豌豆荚的方式并不是完全隔离故障,隔离保持在组件水平。
碎片(Shard):数据库结构或者存储子系统的描述。
条(Sliver):即碎片
块(Chunk):即豌豆荚组
集群(Cluster):会和群组(Pool)交替使用,特别是当有一个共享的会话或者状态概念时,但有时用来指主备配置的高可用性解决方案。
群组(Pool):常被引用指一组执行类似任务的服务器。
这些术语对于初次接触的人来说可能有点难以理解,但是最终怎么称呼在你自己,喜欢就好,关键在于一个正确的设计——允许在高请求压力下可以拓展和优雅的失败。
好处有很多,如明显提高可用性和可拓展性,减少上市时间和降低开发成本,使应用版本回滚变得容易,可以在网站/应用/平台仍然在给客户提供服务的情况下推出新功能。
当你用电不当,就会跳闸,不会让你错误的用电方式影响除了你房间以外的更大区域。
就是上述道理,当故障隔离域或泳道在平台或系统架构级别失败时,你只会失去泳道服务的功能、地区和用户。
好的泳道架构会保证你危害的局部性,不好的则会造成大的影响,你不会愿意因为邻居的电饭锅短路而让你们小区都没有电可以用的。
下面给出一些实际的例子:
Healthcare.gov是美国医疗保险交易系统。
2010年3月23日*患者保护和可负担医疗法案(PPACA)*在美国被签署成法律,此后不久就开始构建医疗保险交易系统。
最初的架构是单一门户的网站,创建相互关联的网格服务,服务大多数美国人的需求。但是当时网站的可用性和响应速度都糟糕的惊人。问题主要原因如下:
那么该如何解决这个问题呢?
出现问题可以立刻聚焦到对应的隔离泳道,针对泳道提问“是否刚刚在这里发布了代码?”“日志有什么异常?”等问题,大大节省工作量。
好的架构提升灵活性。
如果你运营某个电子商务平台,你可能会有代码、对象、方法、模块、服务器和数据库集中在结账、查找、比较、浏览、运输和库存管理等。团队致力于这些方面,拥有专业的方法允许更快的新功能研发和更快的解决已知或现有的事故和问题。总体来说因为开发更快,交付速度的加快可能会导致更短的产品上市时间。
显而易见的会降低成本。
你可能会认为运营额外的网站会比运营单一的网站耗费更多的资金,网站数量越多运营费用也越多。
这是真的,多数企业希望拥有可以经受住地理隔离的灾难的产品,在不同程度上投资灾难恢复措施,以帮助减轻这些灾难的影响。
假设有适当的故障隔离架构,运行三四个合适的故障隔离数据中心的资本支出可以显著低于运行两个完全冗余的数据中心。
可以尝试计算失去的机会(失去的收入),系统故障导致的交易量的损失和高客户流失率是可以测量的。这种当前损失和未来收入损失的比较可以用来确定实施故障隔离架构是否值得。
大多数的故障隔离系统绝对不与功能或数据边界之外的任何东西发生调用和互动关系。
当然~完全的不共享做不到。
共享可能导致一个组件的问题影响多个系统,导致大面积的问题。(如数据库的问题影响整个系统)
在一些领域,如边界或网关的路由器、财务。这可能是难以做到的。不过话说回来,在没有这个障碍的前提下,越是彻底的运用这个原则,结果会越好。
我们倾向于没有任何通信发生在故障隔离区以外和从不允许同步通信。
例如已经建立了数据库用到的说法是不正确的。交易如何到数据库?跨越泳道的通信将要发生,但是根据原则2,这是不该发生的事。在这种情况下,也许你已经创建了一个服务器群组,但因为交易越界,按照我们的定义它不是一个泳道。
天下没有免费的午餐。
故障隔离也不是免费的,也未必是便宜的。
虽然它有许多好处,但是想想你的平台能坚持多久,值得你花费那么多来做故障隔离吗。你的股东们得不到立即的回报,这也会是一个问题。
所以你应该实现适当数量的故障隔离,以产生积极的股东回报。
你可能会问:“好吧,谢谢,告诉我该怎么做?”
不幸的是,答案取决你的的特定需求,我们不能准确的描述在你的环境中到底需要做什么。
不过有一些简单的规则可以帮助我们提高可扩展性和可用性。
确保把和盈利关系密切的系统和可能失败产生问题的系统适当的隔离。
电子商务网站与利益最密切的是购买流程。
内容网站与利益最密切的是广告系统。
收费的反复注册网站与利益最密切的是注册到收费的过程。
某些组件多次引发事故,你一定要考虑这些组件未来的预留空间并隔离这部分。
再一再二不再三
对于多重SaaS系统非常有用。
通常,多重服务(multitenant)表明你试图从共享中获得成本效益。在许多情况下,这种方法意味着你可以把系统设计成在单一泳道中运行一个或多个应用。如果你的平台是这样的,应该充分的利用它。如果某个服务特别忙,那么给他分配一个专用的泳道。如果大部分服务的利用率很低,那么就把它们都分配到一个泳道。
一个简单的方法。
将设计概要画在平板上,然后:
故障隔离架构原则如下:
原则1:绝不共享。泳道共享的越少,其故障隔离度就越高。
原则2:不跨越泳道。同步通信从不跨越泳道。如果跨越了泳道,那么边界的划分是不正确的。
原则3:交易发生在泳道。不可能建立多服务泳道,因为那些服务通信将违反原则2。
故障隔离架构的方法如下:
方法1:盈利的泳道。千万别把收款机和其它系统混在一起。
方法2:泳道是事故的最大来源。确定造成反复发生问题的根源,然后隔离它们。
方法3:泳道的天然隔离。客户的边界是最好的泳道隔离索。