架构设计原则

前言

架构设计的难点在于不确定性，比如:

1.我是选择比较成熟的技术(后续演进怎么办)，还是选择最新的技术(出问题怎么办)
2.我是选择mysql(比较熟悉)，还是mongodb(可能更适合业务)
3.选择React(灵活)，还是vue(易用)
4.我是做电商，能否照搬淘宝京东那一套？

合适原则

合适比领先更重要,合适从三方面说：

1.人员合适，你给我5个人叫我弄一个淘宝，能支持亿级用户（天方夜谭）
2.时间合适，这个时间不是指项目开发周期。而是系统的运行时间。一个系统的架构是在不断的完善中进行的，而不是一蹴而就。像淘宝现在的架构，就是他们经历了10多年的演进才达到的。
3.业务和数据量合适。假设你系统用户只有10万人，你想的再完美(你靠想象设计了1000万的)，系统到了100万，1000万还是会出问题的(请根据问题完善架构)。淘宝就是经历了无数个双十一的，才形成今天的架构。让你仿照淘宝很简单(仿其形而不得其髓)，你没有双十一那么高的并发量，和用户量。你就不知道他们到底遇到了什么问题(想象和实际是两种东西)。所以有多少业务和数据量，就做什么样的架构。后期再慢慢演进。

简单原则

简单从量方面说:
一.要求结构简单，当子系统或组件多了以后。其交互程密集网状结构，调用链路变长(出问题的概率越大)。其中一个组件的修改可能会影响到其它组件

二.逻辑简单:当逻辑复杂后(以单体服务为例)，存在以下问题
1.代码量大(就一个服务，包含了所有功能)
2.一个小的错误，就有可能造成整个系统崩溃，不可用
3.各种分支冲突问题(开发的人多了，功能往主分支上合)
4.故障后，需要对整个系统进行排查
5.上线要整体更新
6.版本问题(要求订单上v2,支付上v3,物流上v4)

业务中用到的算法复杂，会造成后续人员难以理解(难修改)

演化原则

一个优秀的架构是通过不断的演进得到的。
一个架构的初始落地是满足当前的业务需求。后期随着业务的扩张，不断对系统进行迭代(保留优秀设计，修复带有缺陷的设计，改正错误设计，移除无用设计)。
当业务发生变化时，框架要进行扩展，重构，甚至重写(但是我们可以保留有价值的经验，教训，逻辑，设计)，从而得到一个优秀的架构

总结

1.合适比领先更重要，如果你是做电商的，淘宝架构虽然领先，但并不一定适合你当前的业务
2.一个好的架构是在业务的实践中，不断进行演进的，脱离业务的架构都是刷流氓
3.一口气吃不成胖子，请设计符合当前业务实际情况的架构，勿贪大贪全
4.结构简单和逻辑简单要进行取舍，把握一个度