为什么使用分布式系统？

为什么使用分布式系统

1. 增大系统容量

   我们的业务量越来越大，而要能应对越来越大的业务量，一台机器的性能已经无法满足了，我们需要多台机器才能应对大规模的应用场景。所以，我们需要垂直或是水平拆分业务系统，让其变成一个分布式的架构。

2. 加强系统可用

   我们的业务越来越关键，需要提高整个系统架构的可用性，这就意味着架构中不能存在单点故障。这样，整个系统不会因为一台机器出故障而导致整体不可用。所以，需要通过分布式架构来冗余系统以消除单点故障，从而提高系统的可用性。

单体应用和分布式架构优缺点

亚马逊的要求

为了克服这些问题，亚马逊这么多年的实践让其可以运维和管理极其复杂的分布式服务架构。

1. 分布式服务的架构需要分布式的团队架构。 在亚马逊，一个服务由一个小团队（Two Pizza Team 不超过 16 个人，两张 Pizza 可以喂饱的团队）负责，从前端到数据，从需求分析到上线运维。这是良性的分工策略——按职责分工，而不是按技能分工。
2. 分布式服务查错不容易。 一旦出现比较严重的故障，需要整体查错。出现一个 S2 的故障，就可以看到每个团队的人都会上线。在工单系统里能看到，在故障发生的一开始，大家都在签到并自查自己的系统。如果没问题，也要在线待命（standby），等问题解决（我在《故障处理最佳实践：应对故障》一文中详细地讲过这个事）。
3. 没有专职的测试人员，也没有专职的运维人员，开发人员做所有的事情 开发人员做所有事情的好处是——吃自己的狗粮（Eat Your Own Dog Food）。自己写的代码自己维护自己养，会让开发人员明白，写代码容易维护代码复杂。这样，开发人员在接需求、做设计、写代码、做工具时都会考虑到软件的长期维护性。
4. 运维优先，崇尚简化和自动化。 为了能够运维如此复杂的系统，亚马逊内部在运维上下了非常大的功夫。现在人们所说的 DevOps 这个事，亚马逊在 10 多年前就做到了。亚马逊最为强大的就是运维，拼命地对系统进行简化和自动化，让亚马逊做到了可以轻松运维拥有上千万台虚机的 AWS 云平台。
5. 内部服务和外部服务一致。 无论是从安全方面，还是接口设计方面，无论是从运维方面，还是故障处理的流程方面，亚马逊的内部系统都和外部系统一样对待。这样做的好处是，内部系统的服务随时都可以开放出来。而且，从第一天开始，服务提供方就有对外服务的能力。可以想象，以这样的标准运作的团队其能力会是什么样的。

要求：
最好一个业务线用一套自己的数据库。这就是亚马逊服务器的实践——系统间不能读取对方的数据库，只通过服务接口耦合。这也是微服务的要求。我们不但要拆分服务，还要为每个服务拆分相应的数据库。

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

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

参考链接：
https://nettee.github.io/posts/2016/Scalable-Web-Architecture-and-Distributed-Systems/