问题一：异构系统的不标准问题
这主要表现在：软件和应用、通讯协议、数据格式、开发和运维的过程和方法不标准。
不同的语言会出现不同的兼容性和不同的开发、测试、运维标准。比如：有的软件修改配置要改它的.conf 文件，而有的则是调用管理 API 接口。
通讯：不同的软件用不同的协议，就算是相同的网络协议里也会出现不同的数据格式。还有，不同的团队因为用不同的技术，会有不同的开发和运维方式。这些不同的东西，会让我们的整个分布式系统架构变得异常复杂。所以，分布式系统架构需要有相应的规范。…
数据通讯协议。通常来说，协议有协议头（最基本的协议数据）和协议体（真正的业务数据）。协议头，统一标准定义，才容易对请求进行监控、调度和管理。
问题二：系统架构中的服务依赖性问题。
如果非关键业务被关键业务所依赖，会导致非关键业务变成一个关键业务。
服务依赖链中，出现“木桶短板效应”——整个 SLA 由最差的那个服务所决定。
服务治理需要定义出服务关键程度和关键业务或服务调用的主要路径。否则无法运维或是管理整个系统。
数据库方面也需要做相应的隔离：避免非关键业务把数据库拖死，那么会导致全站不可用。系统间不能读取对方的数据库，只通过服务接口耦合。这也是微服务的要求：拆分服务和相应数据库。
问题三：故障发生的概率更大
故障恢复时间过长/影响面过大才可怕。
系统里添加各种监控指标是在“使蛮力”。信息太多等于没有信息，要定义出关键指标。
设计时就要考虑如何减轻故障。如果无法避免，也要使用自动化的方式恢复故障，减少故障影响面。
问题四：多层架构的运维复杂度更大
基础层：机器、网络和存储设备等。
平台层：中间件层，Tomcat、MySQL、Redis、Kafka 之类的软件。
应用层：业务软件，比如，各种功能的服务。
接入层：接入用户请求的网关、负载均衡或是 CDN、DNS 这样的东西。
没有统一的视图和管理，导致运维被割裂开来，造成更大的复杂度。
技术团队分为产品开发、中间件开发、业务运维、系统运维等子团队。整个系统会像 “多米诺骨牌”一样，一个环节出现问题，就会倒下去一大片。因为没有一个统一的运维视图，不知道一个服务调用是如何经过每一个服务和资源，花大量的时间在沟通和定位问题上。
分工不是问题，问题是分工后的协作是否统一和规范。
