5分钟了解系统架构设计（3）

最近梳理了之前学习的架构设计相关的一些课程学习总结，将其整理成了一个大纲脑图，以每篇5分钟系列展现出来，希望对你有所帮助。本篇，我们聚焦如何在面试中回答架构设

最近梳理了之前学习的架构设计相关的一些课程学习总结，将其整理成了一个大纲脑图，以每篇5分钟系列展现出来，希望对你有所帮助。

本篇，我们聚焦如何在面试中回答架构设计。

其实，关于架构设计的问题，我们只需要做到立足于点、连接成线和扩散成面。

下面，我们以一个典型案例来看看，如何基于这个套路来回答。

典型案例

在电商中，当用户发表一条商品评论，后台的逻辑是点评系统会调用一系列的远程 API 接口，如调用风控系统、广告系统、消息系统……几个甚至十几个系统的接口。

在业务建设之初，考虑到快速开发与上线，商品评论发布是通过同步 RPC（Remote Procedure Call，远程过程调用）远程调用各系统接口完成的。这种方式在系统少、逻辑简单的阶段很符合实际情况的设计。

但随着业务快速发展，通过 RPC 同步调用的问题逐渐暴露出来。由于过多地依赖其他系统，导致评论发布的接口性能很低，可用性也容易受到其他系统影响。而且每当点评系统需求上线时，其他系统都需要跟着进行联调测试，导致需求迭代速度缓慢。

问题来了

你会如何做架构设计改造？为什么？

回答示例

回答套路：

四个层面，缺一不可。

一谈复杂来源，二谈解决方案，三谈评估标准，四说技术实现。

示例回答：

（1）复杂来源

互联网软件通常分为功能性的复杂度和非功能性的复杂度两种。从功能性复杂度来看产品业务发展快速、系统越来越多、协作效率越来越低，其问题根源就在于各业务子系统强耦合。于是我们引入了MQ来解耦各个子系统，这是系统业务领域带来的本质复杂度，解决的是业务系统效率的问题。从非功能性复杂度来看基于现有的TPS/QPS需求（假设目前峰值TPS=44，QPS=460）结合考虑业务规模发展的前提（假设未来业务预估峰值为目前峰值的4倍），点评消息队列系统的TPS为176，QPS为1840，这个量级的数据意味着并不需要设计高性能架构方案。基于现有可用性问题的考量，假设点评系统的MQ挂掉，将导致用户评论失败，在用户体验层面虽然可以提示用户重新操作，但是如果问题影响到了点评消息的读取导致评论没有走风控策略，就会造成严重的的影响。所以高可用性是点评消息系统的复杂度之一，点评的写入、存储和读取，都需要保证高可用性。综合来看点评系统改造的复杂度在于功能性复杂度（即要解决业务发展带来的系统耦合和开发效率缓慢的问题）以及非功能性复杂度（即要保证系统的高可用性）。