上一讲解释了几个名词，也就是架构和组件模块以及框架平台等之间的关系，这节我们直接进入正题，架构设计的三个原则，先给结论。

• 合适原则

是用mysql还是oracle，要看你的业务场景，比如电信的系统，原有系统很多都在oracle上存储数据，你不可能一下子全部换掉，但是电信业务的一个周边系统，全新的就完全可以用mysql；是用react还是vue，或者jsp，看你团队的技术体系，后期维护成本，业界好的不一定适合；是用单体系统，还是微服务，看项目成本和交付时间节点，一个简单的管理系统，用户总量上限1000，单体就可以了；数据库单表没到千万，就不要考虑分库分表了，先把缓存和sql优化先；已有系统是php的，不到最后不要用java再写一套，成本太高；数据量不大的就不要大数据平台了，BI就行了，当然如果有人给钱也行的；团队5、6个人，就不要想什么都自己从头做，开源的一堆拿来用不是很香吗？

适合公司当前业务和团队，就是最好的，业界领先的不一定适合你。

• 简单原则

简单就是简单，不是简约。软件设计很大程度上就是加中间层，抽象了中间层就可以解决很多问题。如：DAO，就是屏蔽了对象实体和关系数据库的存储映射关系，数据库连接池，就是抽象了业务逻辑和物理数据库的连接，负载均衡，就是抽象了外部请求和服务提供者之间的请求连接。遇到过极端的例子，以前有个同事设计时喜欢抽象至少三层以上，造成代码理解起来非常困难，严重过度设计，工厂模式，抽象工厂模式，你不能再有个抽象抽象工厂模式！

例如设计一个主备方案，如果你用心跳来实现，可能大家都认为这太简单了。但如果你引入 ZooKeeper 来做主备决策，可能很多人会认为这个方案更加“高大上”一些，毕竟 ZooKeeper 使用的是 ZAB 协议，而 ZAB 协议本身就很复杂。这里的复杂不一定就是优秀的，如果可以，为什么不用心跳来实现主备方案呢？

软件系统的复杂性在于结构和逻辑的复杂，结构上即一个系统如果其组成的组件或者模块很多时，组件之间的关系链就变得复杂，而且追踪一个问题时链路很长，不好追踪，某个组件变动之后会影响其他关联的组件。逻辑上即一个系统如果某个组件的逻辑太多，也会导致复杂性，比如前文提到过的图书管理系统，图书管理和用户管理都在一个模块中，就会导致复杂性，开发时代码混在一起，模块之间无法单独编译提交，功能升级时，也会导致其他模块无法正常使用。

变量命名时，使用英文全称，保证其他人可以看懂，就是简单原则，名字虽然长了一些，但是不重要，看懂才是最终的目的。

总之，我们看到，无论是结构的复杂性，还是逻辑的复杂性，都会存在各种问题，所以在架构设计时如果简单的方案和复杂的方案都可以满足需求，最好选择简单的方案；在架构设计时每个地方都要使用简单原则的思想进行设计，不求高大上，只求简单美。

• 演化原则

碰到过面试官问：你觉得新系统是直接分库，还是单库？我说，你预估数据量多大，他说，目前无法判断。那就直接单库好了，就这么几个人初创公司，哪有时间弄分库，分完了后面分页查询，统计都很麻烦，完成业务逻辑才是目前重点，后面数据量上来了，在修改。看看目前的大型系统，基本上都是逐渐演化而来的。一口吃不成一个胖子，关键当前也没有钱。软件系统是根据业务的变换不断进行演进的，不像建筑，一旦盖好了，就无法在修改了，所以保持快速上线，保证业务模式正确，在进行不断升级迭代才是合理的做法。

总之，架构师在进行架构设计时需要牢记这个原则，时刻提醒自己不要贪大求全，或者盲目照搬大公司的做法。应该认真分析当前业务的特点，明确业务面临的主要问题，设计合理的架构，快速落地以满足业务需要，然后在运行过程中不断完善架构，不断随着业务演化架构。

以上三个原则是架构设计时的一种指导思想，根据不同的业务场景，进行设计和甄别，该复杂就不要简单，不能一蹴而就，合适的就是最好的。系统架构没有标准，两个人做出来的方案都可以满足需求，但是原则可以统一。