架构设计始终遵守的原则：长远眼光，适度设计，最小落地。 （没有必要立刻实现的东西不要去落地它，不然意味着没完没了的部署，维护和对现有代码的影响）

做架构和做产品类似的：最小可行性架构原则。（架构始终是为了产品服务的，产品都是一步一个小的mvp原则）

不同的系统就该用不同的架构，即使相同的系统在不同时期也是不同的架构，比如淘宝十几年，每两三年架构都不太一样，也是因为根据业务的特别和规模不断地演变。

能决定一个业务的特点有如下几个属性：是否金融，ToB或者ToC，是否电商型，规模小中大

还有根据规模小中大，是否经常有秒杀需求，架构也会有很大区别。

以某基金公司的直销平台为例子，其特点：金融，ToC，是电商有强支付需求，非数据型，规模不大。

所以系统：对支付额外做了一套系统，再一套系统业务运营支撑平台，同时做两个APP&微信公众号，因为合规部门就一个人而当时以互联网理财政策管理不太严格，未做等级保护三，也只服务于境内用户，也没有ETL需求，也没有秒杀需求，不用弹性扩容。一年6000W资金基本都花在研发上，做了一个十来系统的微服务。

以淘宝的业务需求，请参看： https://segmentfault.com/a/1190000018626163 也是一点点做上去的，不是一次性架构到最终状态的。

然后再看迪斯尼乐园的系统：https://new.qq.com/rain/a/20210530A06AF100 不同的业务估计也是不同的系统，比如景区管理，肯定也就是MIS系统。 对于线上商品买卖，估计类似淘宝平台的电商系统，因为规模远小于淘宝，肯定架构和淘宝差很多。

金融的（有内部很多合规要求&安全要求），大量的数据导入工作量，主要ToB（也ToC），弱电商（几乎不用怎么支付，就是买一下会员）

对于这种系统，应该如何架构。是也是一步一步来，即使最终的架构（即使业务高速发展10年，也不会演变成淘宝那种电商型的系统架构）

因为这种只是大量的只读请求，和大量的数据导入，以及大数据读取或计算，尤其当只有toB时，10年内用户并发量总是不大的。

照这种趋势极速发展10年，可能产生的最终架构是：多拆分几个系统，可能只需要刚刚形成微服务（完全不需要讲究非常好的弹性扩容，当访问量大，自动买机器自动部署扩容）