单体架构，多应用服务器架构，多应用服务器集群式微服务架构，多应用服务器集群式微服务中台架构，云原生高可用集群架构，服务器安全性建议，缓存优化建议

本地缓存

多台应用服务器

注册

用户服务

锁机制

mongodb集群

RDS

问题1：数据库和缓存会有数据一致性的问题解决方案：:1.最终一致性：缓存设置超时时间（会出现在超时时间内可能会有数据一致性问题，这个可以根据实际的业务场景选择对应的方案）（高并发场景下，部分请求直接读库，解决方案：加分布式锁）2.实时一致性问题2：存储数据过大，网络可能会出现IO解决方案：对数据进行压缩问题3：缓存穿透，缓存雪崩，缓存击穿等问题

云原生高可用微服务架构

镜像仓库服务

集群部署

设备

数据一致性

防火墙

redis集群

内容应用服务器

其他服务

主从复制

项目系统部署安全

读写分离

数据量大，访问量大，不会有网络io，比较热门的数据，比如首页

Skywalking：分布式追踪系统，分布式调用链图形化

分库分表

Node2

将多个微服务数据进行汇总整合

应用服务器

灾难备份

亚马逊服务器

... ...

其他内容服务

过期策略

登录

分布式文件存储

单体优势： 公司业务处刚开始阶段，开发简单直接， 代码和项目集中式管理。 排查问题时只需要排查这个应用就可以了， 更有针对性。 只需要维护一个工程， 节省维护系统运行的人力成本。单体劣势:伴随着公司业务功能越来越多， 开发团队的规模越来越大。 在技术层面， 数据库的连接数成为应用服务器扩容的瓶颈。 单体架构增加了研发的成本抑制了研发效率的提升。单体架构对于系统的运维也会有很大的影响。

OAuth2 统一登录授权

GET请求

elasticsearch集群

应用对接

查询放缓存，第一次查询从库中获取数据，保存到缓存中，第二次查询直接从缓存中获取即可。

交易中台

分布式寻址算法

缓存

session问题：二个应用服务器，用户登录之后session会话会出现二个，可能登录之后又让你登录一次解决：使用Redis做分布式session（添加中间件）使用session复制：将一台服务器上面的session复制到另一台（耗内存，耗宽带）使用Nginx的算法：ip_hash：根据不同的ip通过hash算法分发到不同的服务器上（单点故障：假设一台服务器挂了，那么原来请求的ip还是会分发到这台服务器上，导致无法访问）

热点数据缓存

用户

数据量很大，访问量一般，会有网络io，比如一般商品

服务监控和保护

数据中台

用户中台

使用idea进行功能开发，编码

前期可提交到GitHub或者码云

云原生架构的一些问题：技术复杂度：从原来单一架构使用的技术到现在云原生架构使用的技术，技术层面成几何倍增。（这个需要提升技术人员的技术了）多种中间件安装配置搭建：使用到了多种中间件，这个从零开始搭建成本太高。（使用镜像）

内容展示

前端页面

拉取代码，build，打包，SSH

内容中台

mysql数据库集群

工作流

内容获取

分布式事务

堡垒机

哨兵模式

Nignx缓存

认证授权

弹性伸缩

出于安全考虑，服务器只允许通过堡垒机进行运维。在没有提供安全访问策略表的情况下，除了被堡垒机访问之外，所有虚拟机无法访问任何主机，也无法被任何主机访问。

Zabbix：分布式系统监视以及网络监视功能

消息队列：高可用，消息丢失，消息消费的幂等性，顺序性，消息延迟，过期失效，消息队列满了等问题

单体应用

问题1：随着并发量上去了，应用服务器可以横向扩展，但是数据库承载的量还是有限的，这个时候就需要对数据库进行优化解决方案：换数据库：mysql ，redis，mongodb，es，oracle，tidb（需要解决数据同步一致性）分库分表，读写分离:jdbc应用层：shardingsphere，tddl(效率高，对业务有入侵)proxy代理层：mycat，mysql-proxy(效率低一些，对业务没有入侵)问题2：资源浪费比如：秒杀场景这种高并发情况下，其实只针对下订单的模块需要增加机器，但是现在这种架构将整个应用的服务都增加上去了，对资源造成浪费。问题3：跨部门问题业务垂直，会员部门，商品部门都改了一个bug，现在要上线，如果会员部门的bug修复好了，商品部门bug没修复好，这个时候因为都是同一个应用代码，会员部门就得陪着加班

产品数量不多，用户群体大

Nacos 服务注册集群

定时任务调度

单体架构

Skywalking

ELK

Zabbix

私网

请求

Node3

并发竞争

数据迁移

海量数据查询优化

缓存穿透

其他用戶服务

API Gateway 集群（Spring Cloud Gateway）

MongoDB

云原生= 微服务+自动化+持续交付+容器化

数据分片

lambda

VPC

系统负载保护

Sentinel（未） 流控 | 负载均衡

预留服务

内容服务

数据库

集群模式

负载均衡与缓存

日志采集分析集群

备份故障恢复

Prometheus：对于运维人员来说，他们需要监控机器的 CPU、内存、硬盘的使用情况，以此来保证运行在机器上的应用的稳定性。对于研发人员来说，他们关注某个异常指标的变化情况，从而来保证业务的稳定运行。对于产品或运营来说，他们更关心产品层面的事情，例如：某个活动参加人数的增长情况，活动积分的发放情况

ElasticSearch

缓存雪崩

安全性

提交代码

详情页优化

基础服务

熔断降级

POST请求

用戶应用服务器

Grafana

Prometheus

缓存击穿

其他服务中台

多应用服务器集群式微服务中台架构

多应用服务器集群式微服务架构

多应用服务器架构

数据存储

流量控制

编排治理

页面静态化，将页面放到CDN里面，图片放到云存储里面

Redis

营销中台

模板更换问题：模板更换了一个，所有的静态页都得换，仅适用产品数量少的情况。不同国家，静态页同步问题：通过网络同步：比如linux命令scp方式，有多少节点，同步多少份，静态页数量*服务器数量。定时任务：保证在不同机器开启的定时任务不会生成相同的静态页面（上锁）消息中间件：订阅topic，生成服务器静态化页面

API请求

浏览器访问

Node1

消息队列

数据持久化

数据量小，数据访问很高，没有tomcat并发上限，存储热点数据，内存小，比如618活动，双十一活动

缓存优化

集群分片

MySql

产品数量多，用户群体多

redis缓存