架构设计三原则

架构设计三原则

本文参考极客时间，从0开始学架构。

架构设计三原则：

• 合适原则
• 简单原则
• 演化原则

一、合适原则

架构设计的几个误区：

1. 最流行架构
微服务很火，是不是立马把用的好好的springmvc改成微服务架构？docker很火是不是立马进入容器？

2. 追随一线大厂
我们在做电商，淘宝是一线大厂，要不要直接采用淘宝架构？微信开源了消息队列中间件，我们社交的也直接切换吧？

3. 追求大而全
我们随着业务展开用户量会提升很快，我们要兼容微服务扩展， 要加入消息队列，数据库主从，加入Elasticsearch 有利与后期查询，并且随着系统分布式部署，要加入docker来管理环境，日志管理要上kafka 等等。

以上几点，可以说都是错的，因为我们选型偏离的最主要的矛盾，为我们独特的业务场景，定制合适的系统架构，使用最流行的架构，有没有考虑我们业务特殊性？直接追随大厂有没有考虑我们团队的技术能力和是否真的能碰到大厂那种极端场景？追求大而全是否让有限的团队资源陷入无穷的低产出工作上？ 架构就是取舍，不求最新，不求最全，只求最合适。

二、简单原则

复杂，就意味着难度增加，不可控风险增加，保持简单，能系统方便理解，方便扩展，耦合度降低。简单并不代表没有技术含量，反而简单的实现更为实用，比花哨设计更能适应系统一步步演化。

三、 演化原则

罗马不是一天建成的，QQ也不是一天开发起来的。我们要做高内聚低耦合设计，就是为了可扩展。但是我们也要避开过度设计，避免根本不会遇到的场景投入过度资源，设计就是取舍，好钢用在刀刃上，集中资源做主要的事，然后根据未来的方向，不断重构优化，自然会衍生出最适合本业务的工程。

---