抛开业务讲架构都是耍流氓，架构设计的目的是为了解决软件系统复杂性带来的问题，我们的做架构设计的时候通常需要遵循以下三个原则，分别是：合适原则、简单原则和演化原则。
一、合适原则（合适优于先进）
在做架构设计之前通常需要对业务需求进行充分分析，识别出复杂点，并对这些复杂点提出最合适的解决方案。
那么怎样才算合适？这是个仁者见仁智者见智的问题，不同设计师有不同的想法，但通常都需要围绕着业务负责点、资源、成本等维度，这里的资源包括人力资源，也就是你所在团队有多少号人；而成本通常包括服务器成本，时间成本，学习成本等，也就是做成这样的一个系统需要多少台服务器，需要多少时间，充分考虑到这些方面之后才行进行较为合适的架构设计。而不是抛开一切，拍脑袋说要开发一个对标淘宝的系统，即使你只有几个人的团队和一个月时间。
因此做架构设计并不是一定要对标业界最牛逼的架构方案，而是要根据自身情况设计出最合适的架构方案，比如
1、采用单体架构还是微服务架构？
2、采用最新技术还是团队成员都熟悉的技术？
3、采用前后端分离还是前后端一体？
4、采用MySQL数据库还是MongoDB数据库？
以上问题皆没有标准答案，需要具体问题具体分析，只有围绕着业务复杂点、资源、成本等因素之后才能得出最合适的答案。
二、简单原则（简单优于复杂）
正如《UNIX编程艺术》总结的KISS（Keep It Simple, Stupid!）原则一样，软件架构也需要保持KISS原则，简单和复杂是相对的，通常系统的复杂度有以下两个方面：结构复杂、逻辑复杂。
1、结构复杂
通常来说，系统的组件越多，系统结构就越复杂，而且随着组件的增加，系统的结构复杂度呈指数级增长，从降低了系统的可用性和排查问题的难度。
2、逻辑复杂
那是不是说系统之后一个组件的时候，就最简单呢？这里就涉及到了另外一个问题，就是逻辑复杂，当系统只有一个组件时，那么意味着所有功能都在组件完成，组件将越来越庞大，就拿电商系统来说，一个组件需要包括商品功能、订单功能、支付功能、商户功能、物流功能等等，随着业务的增加，可能会出现几十号人同时开着十几个分支同时维护这个组件，那么从开发、测试、发版等系列过程将异常混乱。
因此架构时考虑的简单原则是需要平衡结构复杂度和逻辑复杂度，从而得到相对简单的方案。
三、演化原则（演化优于一步到位）
无论是淘宝还是新浪微博，一开始的架构都不是现在的架构，一开始都是采用最简单的架构方式，比如淘宝采用PHP，新浪微博采用LAMP，随着业务的增长才慢慢的演化系统架构来实现业务目标。
我们的做架构设计的时候，由于业务的不确定性，并不需要围绕着最终目标进行提前设计，因此这不单单会加大了服务器成本还会增加了系统复杂度，在业务未达到预期之前可能会白白浪费人力物力，我们只需要考虑到系统可扩展性即可，考虑到未来系统的演化进程。通过发布的每一个版本去检验市场，当市场反应较好，业务达到预期时，才根据短期目标对系统架构进行必要的调整。
