[架构] 架构概述

时间：2020-03-29 10:46:02 阅读：89 评论：0 收藏：0 [点我收藏+]

标签：提交代码封装 app code 思想 apache ack 客户端返回结果

定义

对业务场景抽象后得出的支撑骨架
架构为业务场景而生，被业务场景所弃
架构设计没有最好，只有“最合适”（受实际场景制约）
- 人员技术研发能力/业务复杂度/数据规模大小/时间成本/运维能力...
“最合适”架构是各方面折中（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