定义
- 对业务场景抽象后得出的支撑骨架
- 架构为业务场景而生，被业务场景所弃
- 架构设计没有最好，只有“最合适”（受实际场景制约）
- 人员技术研发能力/业务复杂度/数据规模大小/时间成本/运维能力...
- “最合适”架构是各方面折中（Balance）的结果
- 单体架构->注册、查询、下单分别成立一个部（微服务架构）
目标
- 功能
- 性能
- 指标：QPS/TPS
- 工具：apachebench(简称ab)/http_load/jmeter
- 手段：加机器(简单粗暴)，前端优化(CDN/动静分离/减少请求次数/)，后端代码优化,缓存(如redis)，JVM优化
- 可用性
- 思想：通过集群提供数据冗余，再通过自动发现并且故障转移机制保证组件的高可用
- 手段：redis-cluster集群，MongoDB分片集群，消息中间件(ActiveMQ/RabbitMQ/kafka/RocketMQ)集群，数据库MySQL集群等
- 伸缩性
- 思想：系统容量不够时，能否方便地进行扩容
- 手段：容器化，docker+k8s进行部署管理
- 扩展性
- 当有需求发生变更或新增时，是否能在不改代码或者改动很少代码的情况下实现功能
- 在合适的情景下使用设计模式
- 安全性
- XSS攻击
- SQL注入
- CSRF攻击（跨站请求伪造）
- DDOS攻击（分布式拒绝服务攻击）
Monoliths/ALL IN ONE/单体架构
- 客户端
- APP/小程序/H5/M
- 服务端
- 所有逻辑都在单体服务器的process中处理
- 处理过程
- APP端请求发给单体服务
- 单体服务接收请求
- 单体服务从数据库读取需要数据
- 单体服务对数据库返回的数据进行逻辑处理
- 单体服务对返回结果进行封装，返回给APP端
- 前后端分离
- APP是前端，Server是后端
- Server返回给APP的只有数据，没有展示逻辑
- 举例
- 多个页面请求在一个进程中处理
- 用户个人主页：查询个人详细信息
- 商品详情页：查询商品详细信息
- 交易记录页：获取已交易商品列表
- 问题：耦合，如一个人负责一个功能，每个人提交代码都要重新编译war
Microservices/分布式微服务架构
- 拆分Monoliths
- 垂直拆分
- 类似数据库分库
- 按业务拆分成3个进程
- 用户/商品/交易...
- 水平拆分
- 类似数据库分表（info%1024）
- 每个业务进一步按请求功能拆分成3个进程
- 接收请求/读取库/业务逻辑处理/返回...
- 网关层/业务逻辑层/数据访问层/数据库或Cache
- 网关层、商品数据访问层稳定
- 业务逻辑层变化频繁
- 网关层用SAAS服务
- 异步架构
- 同步架构等待时间较长
- 在网关层和业务逻辑层之间增加MQ
- 普适架构
- 网关层+业务逻辑层（业务逻辑较简单）
- 业务逻辑层+数据访问层
- 业务逻辑层变薄，抽象出公共业务逻辑层
- DNS解析/静态资源/动态接口数据
- 网关层：Tomcat支持连接性能弱
- 反向代理：承受更大流量（百万级），100台Nginx对应个100个IP
- LVS层虚拟化：把100个IP虚拟成2个IP
- 静态资源放在CDN，每个城市都有节点
- DNSPod
- 适用于一般OLTP场景
- 协议分类
- 通信协议
- HTTP/TCP/WebSocket...
- 数据传输协议
- JSON/XML（文本）
- ProtoBuffer/MessagePack/Dubbo/私有...（二进制）
- 通信协议
- 协议选择
- APP<->网关层
- 没有长连接需求，用HTTP/HTTPS+JSON
- 有长连接需求（Server主动推消息给APP，IM），用TCP/WebSocket+ProtoBuffer
- 网关<->业务逻辑层<->数据访问<->DB/Cache
- 通信用TCP
- 数据包较大，用二进制协议/SQL/Redis
- APP<->网关层
- 垂直拆分
（左：DNS，中：静态，右：动态）
中台模式
- 将产品技术力量和数据运营能力从前台剥离，称为独立的中台
- 包括搜索事业部、共享事业部、数据平台事业部等，为前台即零售电商事业群提供服务
- 业务中台、技术中台、数据中台、算法中台
参考
OLTP和OLAP
https://baijiahao.baidu.com/s?id=1611554859260686629&wfr=spider&for=pc