问架构师都是如何设计的？

很多人做了多年架构设计，很多人连架构设计的关键流程和步骤都不知道。

很多人确实上线了很多系统，也确实做了很多需求，但基本上都是毫无方法，全凭自己想象的在做架构设计。

总的来说，架构设计有四个大的步骤，其中第二个步骤最容易被大家忽略。

步骤一：理解需求以及定义系统边界。

Understand the problem & Identify the scope of the system.

理解需求，核心是和产品确定功能要求，以及根据业务确定性能要求。

定义系统边界，核心是要明确系统哪些要做，哪些不做。

步骤二：也就是最容易被忽略的一个步骤，调研已有的类似的系统。

Research on existing systems.

你做的系统，是业内首创吗？如果不是，看看类似的系统是怎么做架构设计的。参考成熟的方案，能让你的架构设计事半功倍。

步骤三：顶层设计。

high-level architecture design.

设计系统的主要组件，以及它们之间的交互方式。例如:

使用机房，还是云？

使用单体，还是微服务?

要不要cache，要不要mq?

用rdb，还是nosql?

...

这里要包含系统架构的粗略图，以及实现核心需求的流程图。

步骤四：也是非常重要的一个步骤啊，解决主要矛盾迭代设计。

Refine the design.

顶层设计完之后，哪里是系统的主要矛盾？

我们要根据潜在的主要矛盾，细化与迭代顶层设计。

例如：你要做一个计数系统，对推文的阅读，转发，点赞，评论数进行计数。

假如主要矛盾如果是并发，1秒10万次？

那可能就要加入一些乐观锁，异步，批量请求，Copy On Write等巧妙设计，甚至牺牲一些一致性。

假如主要矛盾是一致性，不允许数据出错？

那可能就要加入一些互斥，校验，write-ahead logging等巧妙设计。

迭代设计，解决完一个主要矛盾，继续解决次要矛盾，直到所有的功能需求与性能需求得到满足。

这里面有个地方要注意：在第四步迭代设计的过程中，有可能会发现第三步顶层设计的缺陷。这个时候，可能要优化甚至推翻第三步顶层设计。

这也是为什么，一些系统运行了几年，就要进行重构。当初的顶层设计已经满足不了现有的业务需求了。在原有顶层设计基础上，解决不了主要矛盾了，那就重构顶层设计来解决。

这也是我非常推崇的两大核心架构设计理念：

其一，任何脱离业务的架构设计都是耍流氓；

其二，架构不只是设计而来的，更是迭代与演进而来的；

回归今日话题，架构设计的四大步骤：

其一，理解需求以及定义系统边界；

其二，调研已有的类似的系统；

其三，顶层设计，定义核心组件与交互；

其四，针对主要矛盾迭代设计；

有人问，第二步借鉴已有成熟系统的方案，在别的架构设计方法中，没有看到过这个步骤呀？莫不是搞笑的吧。

我非常严肃地声明，这个步骤非常重要，调研一定要多花时间。不行的程序员，看谁的代码都是屎；不行的架构师才会认为，我的方案最牛逼，别人的方案都是屎，但其实，自己原创的大部分方案才是屎。

保持开放的心态，借鉴优秀的方案，是优秀架构师的核心品质。

“借鉴”这一点，任何不接地气的架构方法，都不会有人说。

具体问题需要具体分析。一般的互联网系统有两个层面，系统用户数和活跃用户数，这些都跟你的业务有关，要从需求中来。

系统用户数会占存储，而活跃用户数占用你的处理能力。在活跃用户的基础上又有日活和月活，每个用户每天的请求数也不一定。系统的负载跟请求的数量成正比，跟频次也有很大关系。比如双11秒杀瞬时的请求频次就会非常高。

所以，要根据你的业务模型进行设计。

如果不知道怎么办？先找个跟你业务模型差不多的框架先跑起来再说，很多系统都是这么起来的。比如你做一个类似这个腾讯云开发者社区的网站，其实可以直接选一个BBS软件（如discuz?），把页面稍微定制一下就可以跑起来。然后如果有时间精力可以慢慢替换前端，替换后台API和数据库等。

充分理解业务痛点和需求，要解决的问题，进行技术调研，用最简单的技术架构去实现设计、去实践，从数据安全、监控、单元测试、压测、交付的一系列流程