分布式架构的难点：
- 分布式是被拆成好几个服务了，原来是在一个服务器上直接执行完的代码，现在被拆分到了N个服务器上执行，并且还可能是用了不同的编程语言。因此导致了这个业务的链条变大“又长又复杂”，所以需要在决定使用分布式之前，就要先确定好通信规则，想好监控的问题，这样在遇到问题后才能快速的解决问题。
异构系统的标准问题
- 复杂的系统，就宛如一个复杂的社会。就像是秦始皇统一六国之后所行使的“书同文，车同轨”，让本来规则不同的六国，都使用同一个规范。这样减少了在各个地方之间的沟通，提高了生活和工作的效率。
- 所以在分布式系统中也需要一个统一的规范，各个系统都遵循这个规范。才能更好的展开合作，提高生产率。
一个好的配置管理，应该分成三层：底层和操作系统相关，中间层和中间件相关，最上面和业务应用相关。
于是底层和中间件层不能让用户灵活修改的，而是只能让用户选择。比如：操作系统的相关配置应该形成模板来让人选择，而不是让人乱配置的。只有配置系统形成了规范，我们才能hold得住众多的系统。
系统架构中的服务依赖性问题
- 分布式架构下，服务是会有依赖的，一个服务依赖链上某个服务挂掉了，可能会导致多米诺骨牌效应。
- 如果非关键业务被关键业务所依赖，会导致非关键业务变成一个关键业务。
- 微服务要求不但要拆分服务，还要为每个服务拆分相应的数据库（避免某个服务把数据库拖死）。
分布式的故障发生概率更大
- 分布式系统中，机器和服务非常多。相比下比传统单体发生故障的频率更大。
- 单体系统故障的影响面很大
- 分布式系统，如果做了隔离和集群可以降低影响
- 出故障不可怕，恢复时间长、影响面大才可怕
- 所以分布式系统要做好监控，但也不应该所以指标都监控。因为监控的指标多了等于没有监控，反而增加了看日志检查的时间。
但机器和服务数量越来越多，人类的缺陷就成了瓶颈。因为人无法对复杂的事情做到事无巨细的管理。
只有机器自动化才能帮助人类，也就是，人管代码，代码管机器，人不管机器！
多层架构运维复杂度更大
通常系统被分成四层：基础层、平台层、应用层和接入层
- 基础层就是我们的机器、网络和存储设备
- 平台层就是我们的中间件层，Tomcat、MySQL、Redis、Kafka之类的软件
- 应用层就是我们的业务软件或服务
- 加入层就是用户请求的网关，负载均衡或是CDN、DNS等
每一层都会导致整体的问题；
如果没有统一的视图和管理，导致运维被割裂开来，会造成更大的复杂度
在每一层都要有一个统一的标识，在各个层中标记这个请求的先后是哪个请求，方便排查问题
分工不是问题，问题是分工后的协作是否统一和规范