1.性能问题
系统模块的 TPS/OPS （每秒请求／事务数量）开始出现上涨时，系统可能会出现莫名其妙的错误，要么就是大量客户端请求超时，要么就是磁盘 I/O 尤其是写操作时特别高，要么就是数据库出现无数的表 锁。
原因多种多样，有可能是 Linux 操作系统的若干参数没有优化，有可能是基础设施薄弱，还有可能是数据表设计阶段没有联系业务方进行聚集索引和非聚集索引的调整。
调优涉及多个方面：硬件层面、 网络层面、操作系统层面、应用软件层面和代码质量层面。
2.可用性问题
一个己经上线的业务系统突然岩机。但是又没有可接替它继续工作的备用系统。
高可用性的前提是：保证服务系统能够持续工作
实现高可用性一般有两种手段： 一种是通过第三方软件／组件保证系统的可用性；另一种是软件／组件自身己具备高可用的技术实现。
3.异常处理问题
同一顶层设计下，多个子系统间用来调用时发生的异常问题。在分布式业务执行过程中，技术人员需要假设的前提是：调用过程的异常问题无论如何都会出现， 即使是再完美的业务系统也不能避免。
系统间调用的异常如果处理不好，那么其造成的损害，特别是对数据一致性的损害将是巨大的。
处理这些异常问题:1.使用消息队列的事务机制、重发机制或者私信机制，
2.利用RPC实现的事务补偿机制,
3.使用带有熔断机制的第三方组件，
4.利用日志数据排查和解决系统间调用异常
4.系统问依赖问题
整个顶层设计下的若干个子系统肯定存在依赖关系，但是依赖关系是否科学、是否可以持久维护是需要考虑的一个非常关键的要点 。
客户方不懂技术，是我们在需求调研阶段遇到的算一个问题的问题，但关键看需求人员从哪个方面着手向用户解释，引导用户对需求逻辑进行分析 。
比起前两个代码级别的循环依赖和业务级别的循环依赖，整个顶层设计下的若干子系统的循环依赖问题才是架构师最头疼的问题
5.系统雪崩问题
由于系统间存在依赖关系，当业务服务系统 A l 变得不可用时，依赖它的另一个系统 B 的服务也会变得不可用，当系统 B 的服务不可用时，依赖系统 B 工作的服务系统 C 也变得不可用 ……
当然还有一类最常见的问题，就是开发人员写代码时突然“断片”留下的低级问题。由于单元测试覆盖率的缺失，这类问题又没有很好地在自测和集成测试步骤中被发现，最终被发布到上线环境。
要尽可能避免这类问题最好的办法是优化技术团队的版本发布流程、优化自动测试方案，将问题扼杀在线下。