分布式系统架构的问题和解决思路
1、亚马逊做分布式服务架构，遇到了哪些问题，如何解决的？
1) 采用分布式系统架构后出现的问题：
- 一个线上故障的工单会在不同的服务和不同的团队中转过来转过去；
- 每个团队都可能成为一个潜在的 DDoS 攻击者，除非每个服务都要做好配额和限流；
- 监控和查错变得更为复杂。除非有非常强大的监控手段；
- 服务发现和服务治理也变得非常复杂。
2) 亚马逊为了支撑分布式架构而进行的改变：
- 分布式服务的架构需要分布式的团队架构。在亚马逊，一个服务由一个小团队(Two Pizza Team 不超过 16 个人，两张 Pizza 可以喂饱的团队)负责，从前端到数据，从需求分析到上线运维。这是良性的分工策略——按职责分工，而不是按技能分工；
- 分布式服务查错不容易。一旦出现比较严重的故障，需要整体查错。出现一个 S2 的故障，就可以看到每个团队的人都会上线。在工单系统里能看到，在故障发生的一开始，大家都在签到并自查自己的系统。如果没问题，也要在线待命(standby)，等问题解决；
- 没有专职的测试人员，也没有专职的运维人员，开发人员做所有的事情。开发人员做所有事情的好处是——吃自己的狗粮(Eat Your Own Dog Food)。自己写的代码自己维护自己养，会让开发人员明白，写代码容易维护代码复杂。这样，开发人员在接需求、做设计、写代码、做工具时都会考虑到软件的长期维护性；
- 运维优先，崇尚简化和自动化。为了能够运维如此复杂的系统，亚马逊内部在运维上下了非常大的功夫。现在人们所说的 DevOps 这个事，亚马逊在 10 多年前就做到了。亚马逊最为强大的就是运维，拼命地对系统进行简化和自动化，让亚马逊做到了可以轻松运维拥有上千万台虚机的 AWS 云平台；
- 内部服务和外部服务一致。无论是从安全方面，还是接口设计方面，无论是从运维方面，还是故障处理的流程方面，亚马逊的内部系统都和外部系统一样对待。这样做的好处是，内部系统的服务随时都可以开放出来。而且，从第一天开始，服务提供方就有对外服务的能力。可以想象，以这样的标准运作的团队其能力会是什么样的。
2、在分布式系统中需要注意的问题有哪些以及对应的解决方案是什么？
1）异构系统的不标准问题
- 软件和应用不标准；
- 通讯协议不标准；
- 数据格式不标准；
- 开发和运维的过程和方法不标准。
解决方案
- 分布式系统架构需要有相应的规范；
- 开发的API接口需要有对应的规范标准，如：Swagger规范；
- 底层和中间层是不能让用户灵活修改的，而是只让用户选择（一个好的配置管理，应该分成三层:底层和操作系统相关，中间层和中间件相关，最上面和业务应用相关）；
- 数据通讯协议，作为一个协议，一定要有协议头和协议体。协议头需要非常规范地让每一个使用这个协议的团队都使用一套标准的方式来定义，这样才容易对请求进行监控、调度和管理。
2）系统架构中的服务依赖性问题
- 分布式系统中，服务的依赖也会带来一些问题，如果非关键业务被关键业务所依赖，会导致非关键业务变成一个关键业务。这是服务治理的内容。服务治理不但需要我们定义出服务的关键程度，还需要我们定义或是描述出关键业务或服务调用的主要路径。
- 分布式架构不但要在应用层上进行业务隔离，而且要在数据库上进行隔离，不然一个非关键业务把数据库拖死，会导致全站不可用。最好一个业务线使用单独的数据库。（微服务要求，不但要拆分服务，还要为每个服务拆分相应的数据库）
3）故障发生的概率更大
- 分布式系统比单体应用出现问题的概率会更大，这就需要在设计时考虑如何减轻故障。如果无法避免也要使用自动化的方式回复故障，减少故障影响面；
- 人类无法对复杂的事情做到事无巨细的管理，只有机器自动化才能帮助人类。也就是人管代码，代码管机器，人不管机器。
4）多层架构的运维复杂度更大
可以把系统分成四层:基础层、平台层、应用层和接入层。
- 基础层就是我们的机器、网络和存储设备等；
- 平台层就是我们的中间件层，Tomcat、MySQL、Redis、Kafka 之类的软件；
- 应用层就是我们的业务软件，比如，各种功能的服务；
- 接入层就是接入用户请求的网关、负载均衡或是 CDN、DNS 这样的东西。
任何一层的问题都会导致整体的问题; 没有统一的视图和管理，导致运维被割裂开来，造成更大的复杂度。分工不是问题，问题是分工后的协作是否统一和规范。
3、思考
1）亚马逊推分布式系统的做法是否值得每个公司学习和效仿？
2）按职责分工，和按技能分工的区别是什么？
3）开发人员做所有事情这样的做法是否可取？
4）分布式系统架构如何定规范，需要定哪些规范？
5）如何规划业务对应数据库的关系？
6）多层架构如何制定统一的管理视图？
4、参考内容
1）、《从亚马逊的实践，谈分布式系统的难点》。
