分布式系统学习：02 分布式系统的难点

亚马逊经验

分布式服务化架构思想实践最早的公司应该是亚马逊。因为早在 2002 年的时候，亚马逊 CEO 杰夫·贝索斯（Jeff Bezos）就向全公司颁布了几条架构规定。STEVEY对AMAZON和GOOGLE平台的吐槽

亚马逊这么多年的实践让其可以运维和管理极其复杂的分布式服务架构。
1、分布式服务的架构需要分布式的团队架构。
2、分布式服务查错不容易。 一旦出现比较严重的故障，需要整体查错。
3、没有专职的测试人员，也没有专职的运维人员，开发人员做所有的事情。
4、运维优先，崇尚简化和自动化。
5、内部服务和外部服务一致。

分布式系统中需要注意的问题

问题一：异构系统的不标准问题

1、软件和应用的不标准
不同的软件，不同的语言会出现不同的兼容性和不同的开发、测试、运维标准。不同的标准会让我们用不同的方式来开发和运维，引起架构复杂度的提升。

2、通讯协议不标准
在通讯方面，不同的软件用不同的协议，就算是相同的网络协议里也会出现不同的数据格式。

3、数据格式不标准。

4、开发和运维的过程和方法不标准。

问题二：系统架构中的服务依赖性问题

分布式架构下，服务是会有依赖的，一个服务依赖链上的某个服务挂掉了，可能会导致出现“多米诺骨牌”效应。

• 非关键业务被关键业务所依赖，会导致非关键业务变成一个关键业务。
• 服务依赖链中，出现“木桶短板效应”。整个 SLA（Service-Level Agreement，服务等级协议） 由最差的那个服务所决定。

很多分布式架构在应用层上做到了业务隔离，然而，在数据库结点上并没有。如果非关键业务锁死数据库，会导致全站不可用。

问题三：故障发生的概率更大

在分布式系统中，因为使用的机器和服务会非常多，所以，故障发生的频率会比传统的单体应用更大。一方面，分布式系统中，虽然故障的影响面可以被隔离，但是因为机器和服务多，出故障的频率也会多。另一方面，因为管理复杂，而且没人知道整个架构中有什么，所以非常容易犯错误。

• 出现故障不可怕，故障恢复时间过长才可怕。
• 出现故障不可怕，故障影响面过大才可怕。

问题四：多层架构的运维复杂度更大

通常来说，我们可以把系统分成四层：基础层、平台层、应用层和接入层。

• 基础层：机器、网络和存储设备等。
• 平台层：中间件层，Tomcat、MySQL、Redis、Kafka 之类的软件。
• 应用层：业务软件，比如，各种功能的服务。
• 接入层：接入用户请求的网关、负载均衡或是 CDN、DNS 这样的东西。

对于这四层，任何一层的问题都会导致整体的问题；没有统一的视图和管理，导致运维被割裂开来，造成更大的复杂度。

参考资料：

左耳听风（极客时间）链接：
http://gk.link/a/10f5D

---

GitHub链接：
https://github.com/lichangke/LeetCode
知乎个人首页：
https://www.zhihu.com/people/lichangke/
CSDN首页：
https://me.csdn.net/leacock1991
欢迎大家来一起交流学习