适度设计应该是架构设计的第一原则。我们用不同场景下的交通解决方案来类比一下。
1公里以内：步行（免费）、自行车（免费）、电动自行车（几分钱）；
1公里-10公里：步行（免费）、自行车（免费）、电动自行车（几毛钱）、汽车（几元钱）；10公里-100公里：电动自行车（几毛钱）、摩托车（几元钱）、汽车（几十元钱）；
100公里-1000公里：摩托车（几十元钱）、汽车（几百元钱）、火车（几百元钱）、飞机（几百元钱）；
1000公里-10000公里：飞机（几千元钱）；
1万公里-10万公里：飞机（几万元钱）；
10万-100万公里（地月距离为38万公里）：宇宙飞船（上亿元钱）；
数光年（电影《流浪地球》中地球要迁移到另一恒星系的距离为4.2光年）：地球+行星发动机（没概念，至少万亿以上）
可以看出，对于不同规模的问题，解决方案有所不同，其成本可能会有巨大差距。每个解决方案也都有自己适用的范围，骑自行车到不了月球，飞机也不能把你送到小区门口买菜。
架构设计应以满足一定周期内的需求为目标，周期一般考虑一年即可，需求包括功能性的和非功能性的。在这两方面都满足，并考虑一定的前瞻性的前提下，架构应尽量简单，以降低成本，缩短实现周期，使质量更高。以下是一些常见的考虑：
能少一个组件就少一个组件
要有这样的意识，每增加一个组件，包括研发、测试、运维、硬件资源占用的总体成本就会上升数万元。
能不用微服务就不用微服务
微服务是有一些优点，但缺点也很明显：响应时间增加、综合成本上升、管理复杂度高。对于中小型系统、不需要频繁发布的系统，采用微服务架构就像是杀鸡用牛刀。
能不用分布式就不用分布式
使用分布式技术的前提是处理能力需求超出了单机的能力上限。经常看到一些解决方案在单机能力尚有较多富余时就早早引入分布式技术，白白增加了系统复杂度，引起成本上升。
（二）避免问题扩大化
解决一个问题时尽量直接解决，不要间接解决而引入新的问题。
经常看到有的系统，数据库刚出了一点性能问题，就开始考虑分库分表之类。这个时候，应当首先解决导致性能问题的直接原因，比如慢查询、表设计不合理等，万不得已才考虑分库分表以及引入一些数据访问中间件。在引入数据访问中间件之前，还可以考虑在驱动级别解决问题，以避免增加进程级的组件，引起管理复杂度上升和性能下降。