M Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== 原则性思想 ======
架构设计始终遵守的原则：长远眼光，适度设计，最小落地。 （没有必要立刻实现的东西不要去落地它，不然意味着没完没了的部署，维护和对现有代码的影响）

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

{{http://image.woshipm.com/wp-files/2016/10/2NhXSXHkCMp5XnVmtROA.png?800*400}}

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

====== 具体业务的特点 ======
能决定一个业务的特点有如下几个属性：是否金融，ToB或者ToC，是否电商型，规模小中大
^Y/N ^是否金融 ^ToB/ToC ^是否电商型（强支付需求） ^是否数据型 ^
|是  |对安全要求极高，往往一边做系统一边做安全。有合规部门且合规要求严格，如为网络等级保护三级做灾备环境和为境内外政策区别而做两套系统  |（B）用户量很少甚至能直接加载到内存  |需要严格控制事务一致性  |大量的ETL工作量，大量的只读请求  |
|否  |可以先做业务后做安全，一般没有专门的合规部门  |（C）用户量一般较大  |不需要严格控制事务一致  |业务初期少量甚至几乎没有ETL工作  |

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

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

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

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

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


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

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

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

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