(资料图)

1.自黑式攻击

1.1.自黑只会偶尔成为人类的美德

1.2.对系统来说，绝对不会推崇自黑

1.3.“自黑式攻击”是指系统或有人类参与的扩展系统联合外部对自身发起攻击

1.4.好的营销可以随时杀死你

1.4.1.并不是每个自黑的“伤口”，都可以归咎于营销部门

1.5.典型例子

1.5.1.公司市场部发出的致“精选用户组”的一份邮件

1.5.2.该邮件包含一些特权或优惠信息，其复制速度比木马病毒快得多

1.5.3.定价错误使得一个SKU的订购次数等于其他所有产品的订购总数

1.5.4.在基于ATG的基础设施中，锁管理器总是会处理分布式锁管理，以确保缓存的一致性

1.5.4.1.锁管理器资源只有一个，随着网站横向扩展，锁管理器会成为瓶颈，并且最终会成为风险

1.5.4.2.如果一个热门项目被无意修改，最终就可能会导致数以百计的服务器上出现数千个请求处理的线程，都在排队等待该项目的写入锁

2.共享资源

2.1.以面向服务的架构或“公共服务”项目为幌子，共享资源会成为水平扩展层级所有成员都需要使用的某个设施

2.2.可以是集群管理器或锁管理器

2.3.当共享资源流量过载时，它会成为限制系统容量的瓶颈

2.4.当共享资源有冗余且是非独占的时，就没有问题

2.4.1.可以同时为多个消费者提供服务

2.5.最具扩展性的架构是无共享架构

2.5.1.在无共享架构中，系统容量与服务器的数量几乎呈线性关系

2.5.2.无共享架构的问题在于，它会牺牲故障转移来获得更好的扩展性

2.5.3.通过减少共享资源的扇入个数，可以近似实现无共享架构，即减少调用共享资源的服务器

3.避免自黑式攻击

3.1.构建无共享架构

3.1.1.在无共享架构中，每台服务器在不知道任何其他服务器的情况下，仍然能够运行

3.1.2.服务器不共享数据库、集群管理器或任何其他资源，这是水平扩展的理想状态

3.1.3.通过中间件模式减少过量请求造成的影响，或尽量通过冗余和后端同步协议，实现共享资源本身的水平扩展

3.1.4.当共享资源不可用或没有响应时，还可以为系统设计一个后备模式

3.1.5.如果提供悲观锁的锁管理器不可用，那么应用程序可以进入后备模式并使用乐观锁

3.2.保护共享资源

3.2.1.当流量激增时，编程错误、意外的放大效应和共享资源都会产生风险

3.2.2.前端负载的增加，会导致后端处理量呈指数级增长

3.3.预留一部分基础设施，或整备一些新的云资源，用于应对商业促销或流量激增

3.4.当访问流量激增时，可以使用自动化扩展技术

3.4.1.注意服务器启动的延迟时间

3.5.保持沟通渠道畅通

3.5.1.应对人为的攻击，关键在于培训、教育和沟通

3.6.快速地重新分配实惠的优惠

3.6.1.任何一个认为能限量发布特惠商品的人，都在自找麻烦

3.6.2.根本就没有限量分配这回事

3.6.3.即使限制了一个超划算的特惠商品可以购买的次数，系统仍然会崩溃

4.放大效应

4.1.生物学中的平方-立方定律

4.1.1.虫子的重量随着体积增加而增加，符合时间复杂度O(n^3)

4.1.2.虫子的腿部力量会随腿的横截面积的增加而增加，符合时间复杂度O(n^2)

4.1.3.如果让虫子增大为原来的10倍，那么变大后的虫子的“力量与体重”之比就会变成原来的1/10

4.1.4.虫子的腿根本支撑不了10倍大的个头

4.2.“多对一”或“多对少”的关系

4.2.1.如果这个关系中一方的规模增大，另一方就会受到放大效应的影响

4.2.2.由于开发环境和测试环境的规模很少会与生产环境一致，因此很难在前两个环境中，看到放大效应跳出来“咬人”

4.2.3.1台数据库服务器被10台机器调用时，可以很好地运行

4.2.4.调用它的机器数量再额外添加50台时，数据库服务器就可能会崩溃

5.点对点通信

5.1.放大效应“咬人最凶”的情况

5.2.当只有一两个实例进行通信时，机器之间的点对点通信可能工作得很好

5.3.每个实例必须直接与其他实例进行沟通，连接的总数，会以实例数量平方的数量级上升

5.4.连接数会扩展到时间复杂度O(n^2)

5.5.务必将单个服务内的点对点通信，与服务之间的点对点通信区分开

5.6.除非是微软或谷歌这样的公司，其他公司不可能构建与生产环境相同大小的测试农场

5.6.1.这种类型的软件缺陷是不可能被测试出来的，必须通过设计来避免

5.6.2.参照测试环境检查生产环境，以发现放大效应

5.7.替换方式

5.7.1.UDP广播

5.7.1.1.广播能够应对服务器数量的不断增长，但它不节省带宽

5.7.1.2.与广播消息不相关的服务器产生一些额外的负载

5.7.2.TCP或UDP组播

5.7.2.1.只允许相关的服务器接收消息，传送效率更高

5.7.3.发布-订阅消息传递

5.7.3.1.服务器在消息发送的那一刻没有监听，也可以收到消息

读发布！设计与部署稳定的分布式系统（第2版）笔记08_自黑与放大-环球观察

1.自黑式攻击

1.1.自黑只会偶尔成为人类的美德

1.2.对系统来说，绝对不会推崇自黑

1.3.“自黑式攻击”是指系统或有人类参与的扩展系统联合外部对自身发起攻击

1.4.好的营销可以随时杀死你

1.4.1.并不是每个自黑的“伤口”，都可以归咎于营销部门

1.5.典型例子

1.5.1.公司市场部发出的致“精选用户组”的一份邮件

1.5.2.该邮件包含一些特权或优惠信息，其复制速度比木马病毒快得多

1.5.3.定价错误使得一个SKU的订购次数等于其他所有产品的订购总数

1.5.4.在基于ATG的基础设施中，锁管理器总是会处理分布式锁管理，以确保缓存的一致性

1.5.4.1.锁管理器资源只有一个，随着网站横向扩展，锁管理器会成为瓶颈，并且最终会成为风险

1.5.4.2.如果一个热门项目被无意修改，最终就可能会导致数以百计的服务器上出现数千个请求处理的线程，都在排队等待该项目的写入锁

2.共享资源

2.1.以面向服务的架构或“公共服务”项目为幌子，共享资源会成为水平扩展层级所有成员都需要使用的某个设施

2.2.可以是集群管理器或锁管理器

2.3.当共享资源流量过载时，它会成为限制系统容量的瓶颈

2.4.当共享资源有冗余且是非独占的时，就没有问题

2.4.1.可以同时为多个消费者提供服务

2.5.最具扩展性的架构是无共享架构

2.5.1.在无共享架构中，系统容量与服务器的数量几乎呈线性关系

2.5.2.无共享架构的问题在于，它会牺牲故障转移来获得更好的扩展性

2.5.3.通过减少共享资源的扇入个数，可以近似实现无共享架构，即减少调用共享资源的服务器

3.避免自黑式攻击

3.1.构建无共享架构

3.1.1.在无共享架构中，每台服务器在不知道任何其他服务器的情况下，仍然能够运行

3.1.2.服务器不共享数据库、集群管理器或任何其他资源，这是水平扩展的理想状态

3.1.3.通过中间件模式减少过量请求造成的影响，或尽量通过冗余和后端同步协议，实现共享资源本身的水平扩展

3.1.4.当共享资源不可用或没有响应时，还可以为系统设计一个后备模式

3.1.5.如果提供悲观锁的锁管理器不可用，那么应用程序可以进入后备模式并使用乐观锁

3.2.保护共享资源

3.2.1.当流量激增时，编程错误、意外的放大效应和共享资源都会产生风险

3.2.2.前端负载的增加，会导致后端处理量呈指数级增长

3.3.预留一部分基础设施，或整备一些新的云资源，用于应对商业促销或流量激增

3.4.当访问流量激增时，可以使用自动化扩展技术

3.4.1.注意服务器启动的延迟时间

3.5.保持沟通渠道畅通

3.5.1.应对人为的攻击，关键在于培训、教育和沟通

3.6.快速地重新分配实惠的优惠

3.6.1.任何一个认为能限量发布特惠商品的人，都在自找麻烦

3.6.2.根本就没有限量分配这回事

3.6.3.即使限制了一个超划算的特惠商品可以购买的次数，系统仍然会崩溃

4.放大效应

4.1.生物学中的平方-立方定律

4.1.1.虫子的重量随着体积增加而增加，符合时间复杂度O(n^3)

4.1.2.虫子的腿部力量会随腿的横截面积的增加而增加，符合时间复杂度O(n^2)

4.1.3.如果让虫子增大为原来的10倍，那么变大后的虫子的“力量与体重”之比就会变成原来的1/10

4.1.4.虫子的腿根本支撑不了10倍大的个头

4.2.“多对一”或“多对少”的关系

4.2.1.如果这个关系中一方的规模增大，另一方就会受到放大效应的影响

4.2.2.由于开发环境和测试环境的规模很少会与生产环境一致，因此很难在前两个环境中，看到放大效应跳出来“咬人”

4.2.3.1台数据库服务器被10台机器调用时，可以很好地运行

4.2.4.调用它的机器数量再额外添加50台时，数据库服务器就可能会崩溃

5.点对点通信

5.1.放大效应“咬人最凶”的情况

5.2.当只有一两个实例进行通信时，机器之间的点对点通信可能工作得很好

5.3.每个实例必须直接与其他实例进行沟通，连接的总数，会以实例数量平方的数量级上升

5.4.连接数会扩展到时间复杂度O(n^2)

5.5.务必将单个服务内的点对点通信，与服务之间的点对点通信区分开

5.6.除非是微软或谷歌这样的公司，其他公司不可能构建与生产环境相同大小的测试农场

5.6.1.这种类型的软件缺陷是不可能被测试出来的，必须通过设计来避免

5.6.2.参照测试环境检查生产环境，以发现放大效应

5.7.替换方式

5.7.1.UDP广播

5.7.1.1.广播能够应对服务器数量的不断增长，但它不节省带宽

5.7.1.2.与广播消息不相关的服务器产生一些额外的负载

5.7.2.TCP或UDP组播

5.7.2.1.只允许相关的服务器接收消息，传送效率更高

5.7.3.发布-订阅消息传递

5.7.3.1.服务器在消息发送的那一刻没有监听，也可以收到消息

5.7.3.2.传递的效率也较高

5.7.3.3.通常会让基础设施成本大增

5.7.4.消息队列

5.7.5.在所有可行的方案中，选择最简单的那个来做

相关文章

编辑推荐