面试的时候你是否会经常被问到下面的问题“你之前是如何设计这个系统？请介绍下你的思路”。遇到这种情况我们很多人会陷入到某个技术点里，听的面试官一头雾水，而真正我们忽略了系统设计思路。

案例背景：
电商系统，用户发布一条商品评论，后台的逻辑会调用一系统的远程接口，比如风控、图片、广告、消息等。这样RPC的设计会使接口的性能很低，那怎么来升级改造呢？

案例分析：

解决问题的方法也很多，比如使用MQ消息队列做解耦，异步的处理流程。这样的回答，只是问题的“术”。我们要升华到底层的思维逻辑，这是“道”。

复杂来源：

从功能性复杂度方面看，需要利用MQ消息队列来实现业务之间的解耦；

从非功能性复杂度方面看，需要从高性能(TPS和QPS)和高可用方面来控制非功能性。

解决方案：

1.采用开源的MQ消息管道

2.采用开源的Redis实现消息队列

3.采用内存队列+MySQL来实现

一般情况下，你至少需要两到三种备选方案，考虑通过不同的技术方式来解决问题。

评估标准：

针对案例中的点评系统，要如何评估方案呢？

1.系统无单点原则

冗余：在关键组件上使用冗余。这意味着您在系统中使用多个相同的组件或备用组件，以便在一个组件出现故障时，系统可以继续运行。这可以包括冗余服务器、存储设备、网络链路等。

负载均衡：使用负载均衡器来分配流量到多个服务器或实例。如果一个服务器出现故障，负载均衡器可以自动将流量重定向到健康的服务器，从而确保系统的可用性。

分布式架构：将系统划分为多个独立的微服务或组件，分布在不同的物理位置或数据中心。这可以减少系统的整体风险，因为单一故障不会影响整个系统。

2.可水平扩展原则

分布式架构：将系统分解成多个独立的组件或微服务，这些组件可以分布在不同的服务器或节点上。这种分布式架构有助于实现水平扩展，因为您可以独立地扩展每个组件，而不是整个系统。

负载均衡：使用负载均衡器来分发流量到不同的服务器或节点。负载均衡器可以根据负载情况自动调整流量分配，确保每个服务器或节点都得到平衡的负载。

自动伸缩：实施自动伸缩机制，以根据负载的变化自动添加或移除服务器或节点。云服务提供商通常提供自动伸缩服务，允许根据需要动态调整资源。

数据存储分区：如果系统涉及数据存储，考虑使用分区或分片技术，将数据分布到多个存储节点上。这有助于均衡数据访问负载。

不要陷入某个纯粹技术点的优劣之争，这样很难有结果，越大的项目越明显。

作为技术人员，考虑问题的方式比具体的选型结果更为重要。

技术实现：

在确定了解决方案后，需要进一步说明技术上的落地实现方式和深层原理。

总结：

在回答复杂度来源的时候，需要结合具体的业务场景和业务发展阶段来阐述。业务场景表明业务的独特性，发展阶段表明业务的成熟度。同一个业务场景在不同的阶段产生的矛盾是不一样的。
在回答解决方案的时候，有价值的解决方案一定是建立在明确复杂度来源基础之上的。所以在设计架构的时候要分主要和次要问题。主要问题一定要解决，次要问题可以取舍。
在回答评估标准的时候，要从功能性和非功能性角度出发，对于很难决策的方案，需要从更高的视角进行考量。
在技术实现的细节上，要尽量讲出技术的实现原理，不要浮于表面的框架组合。

所以，我们要有架构师视角，就是全局的视角，包括了空间全局和时间全局，在空间全局上你要看到系统的领域边界，在时间全局上你要看到系统的发展周期。