[架构] 架构概述
Posted cxc1357
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了[架构] 架构概述相关的知识,希望对你有一定的参考价值。
定义
- 对业务场景抽象后得出的支撑骨架
- 架构为业务场景而生,被业务场景所弃
- 架构设计没有最好,只有“最合适”(受实际场景制约)
- 人员技术研发能力/业务复杂度/数据规模大小/时间成本/运维能力...
- “最合适”架构是各方面折中(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
以上是关于[架构] 架构概述的主要内容,如果未能解决你的问题,请参考以下文章