基本原则
好系统是迭代出来的,先解决核心的问题.
不要过度复杂设计.
可以适当先行的预估规划设计.
无状态设计原则
尽可能的使用无状态设计,无状态的意思就是说当前请求不会依赖于其他的请求,要么就是存储在数据源中,不能存储在当前的服务器上.
无状态设计对系统设计来说意味着水平扩容,常见的比如说共享session扩容就会十分麻烦,因为每台服务器的内存中都会有session,这是有状态的,服务器需要记录,扩容会相对麻烦,如果使用token则没有此问题,机器请求一上去就直接水平加机器,也是最方便的解决方式.
拆分系统
用户量大.
业务复杂.
拆分大纲是高内聚，低耦合。
一般都是根据系统业务进行拆分.
比如优惠卷系统.
可以和有能力的产品经理或者架构师配合.
随着每一个接口或者模块的业务量越来越细,我们可以根据功能维度进行拆分.
优惠卷发放功能.
创建优惠卷功能.
领取优惠卷功能.
之后服务甚至可以对接其他相关的平台.
为什么我们已经根据系统的维度进行拆分了,还需要根据功能的维度进行拆分呢?
因为从系统稳定性的角度考虑,无论是发版还是说提需求,假设你有个用户系统和订单系统,有一个需求牵连到2个系统,那么相当于是2个系统都需要重新发版,而且会增加跨部门沟通的联调成本,如果我们从功能维度进行拆分的话,就不需要考虑这么多的问题呢.
读写原则
可以按照读写服务进行拆分，比如查询是一个服务，数据写入又是一个服务，其中数据写入服务单独拆分出来，还能对接其他的服务。
读服务: 多级缓存。 redis，网关（负载），CDN，DNS。
写服务: 分区，分库，分表。
切面原则
用户分流，在用户人数特别多的时候做切面，引导用户到附近城市的CDN。
CDN里一般都是存放着静态数据，不用频繁更新的那种，每个城市的数据也基本一致。
其实可以理解为拦截器，里面还可以添加黑白名单，权限校验等等。
模块原则
有些可能会被称为基础架构组。
可以理解为二方库，在原有模块上做开发，提供公共模块。
让其他服务的人也可以调用，比如综合消息队列，综合短信发送模块。
对外接口提供统一配置，让别人无需关注底层的实现。
服务化原则
流量是不可控的，要提前做好限流，熔断，降级，隔离，恢复的方案。
因为调用的服务一多，就容易出错，要做好服务出错的预处理方法，比如熔断和降级就能保证不会出现服务雪崩的问题，调用超时一直等待。
问题
所有需要鉴权的都是有状态的嘛?
其实不是这样的,比如我们的token,如果你执行一个创建订单的逻辑,但是创建之前你肯定需要登录呀,看起来是2次请求,但是实际上你单独执行第二次请求,假设你没有token,它是会直接跳转到登录界面的,所以其实是对业务没有影响的.
需要存储的token为什么是无状态的呢?
因为没有存储在服务器的内存当中,在真实场景中我们一般存储在redis下.
