web系统架构逻辑

web系统架构逻辑 

大体分三大类：用户、商品、订单
1、单体就是单机，集成在一起，后期可考虑将庞大的拆分模块程序化，每个程序独立维护，程序之间互相关联，只是单体的进化版
2、分层构架体系，表现层（如何提供给用户展示），业务层（处理交易），数据层（数据范式和组织）、持久层（放置在存储系统上）
3、SOA，基于服务化构建，服务总线，消费服务客户端直接请求服务总线
4、分布式形式，将一个庞大的应用程序，切分成很小的程序模块，每个程序都可以独立运行，程序内部数据通过API封装向外提供，程序与程序之间相互调用，调用关系较复杂成网状模型
5、微服务，在分布式基础上对大的程序切割的逐个细小

grpc 调用http/2.0

动静分离访问流程

1、访问静态页面
PC --> 反向代理 --> 静态后端服务器
此时PC已经有静态业务了，有CSS、NODEJS、图片等，内容自带URL

2、访问动态页面
PC触发URL --> 反向代理 --> 动态后端服务器
APP自身已经包含CSS、NODEJS
APP --> 反向代理 --> 静/动态后端服务器，静态只是返回一些图片
在动静分离的情况下，APP和PC访问流程还是有一定的区别

优化思路

反向代理 --> 后端服务器
只需要一个持久连接，响应处理多个来自客户的请求，这样可以减轻后端服务器的压力
反向代理还可以设置缓存，定期缓存动态内容，减少后端服务多次处理相同的事件

1、反向代理网络IO到后端服务，后端服务磁盘IO转换，反向代理单次本地磁盘IO，若缓存服务器基于内存中工作，那么磁盘IO也可以省略了
2、缓存类型一般是键值类型的组织格式，基于哈希，分级结构，哈希也会节省网络带宽，而不是直接获取源数据，这样能快速查询缓存时间，提高缓存命中率
3、还需要考虑缓存命中率，缓存大小，定期清理缓存，缓存基于LRU算法先用先出
4、需要评估缓存的命中率，若命中率过低，会给系统带来负面影响，2分动态，8分静态

缓存
1、代理方式：网络七层，递归式，若底层查不上向上查询
2、旁路模式：客户端相关智能的工作

客户端去找redis查缓存是否命中，若没有命中，就找服务端，查找之后结果在由客户端存放在缓存服务器中，迭代式

varnish也是代理级缓存
缓存数据涉及到用户隐私，不建议缓存，比如用户的密码

注意：
1、只要后端被调度是存储功能的服务器，有两种形式，副本和非副本
2、副本形式（如mysql主从），注意调度方式如轮询RR
3、非副本，前端服务必须能路由到后端，路由又分两种（静态映射，URL、取）和（CH 、哈希）
4、非副本还需要考虑冗余性（高可用），并需要考虑权威数据源
5、冗余又分很多层，硬件存储层，主机层、应用层、数据层等
6、若缓存命中率当时规划是80%，那么后端服务规划时只能承载30-50%，这样会导致雪崩效应，若缓存全挂了，所有请求就会到后端服务，这样可能会导致后端服务挂了，一次性并发特别高，为了解决这种情况，可以使用熔断，对流量进行控制分发，比如单机控制保持2000连接

小结

避免一个机房业务挂了，业务全挂了，这时可以使用多个机房，如A机房提供服务，B机房容灾，主从同步，也可做灰度发布

底层，工程经验，如何动手解决问题（操作经验，只能在底层）
规律性认知（将知识组成框架）
认知
运维核心三大类：发布、变更、故障处理
1、发布：总版本迭代。灰度发布、滚动发布
2、变更：如服务器扩容和减少
3、故障处理 ：应急响应

应用才是核心，如分布式，微服务
服务动态发现，注册，总线功能