【1-1：读懂-互联网架构】

基本概念

1. 业务架构

• 定义：业务战略，治理，组织和关键业务流程。从企业视角来看，重在价值、信息、协作，关联多部门。
• 从业务角度描述系统承载的功能集合、领域边界、各组成部分的逻辑关系。区别于技术架构，业务架构图里避免出现技术类的术语，如 DB、MySQL、CMQ、同步、异步、并发等。

2. 应用架构

• 定义：要部署的各个应用程序的蓝图，其交互以及与组织核心业务流程的关系。

3. 数据架构

• 定义：一个组织的逻辑和物理数据资产和数据管理资源的结构。

5. 技术架构：

• 定义：支持部署业务，数据和应用程序服务所需的逻辑软件和硬件功能。这包括IT基础设施，中间件，网络，通信，处理和标准。
• 技术架构体现的要具有技术特色，例如同步、异步、消息等

互联网架构

• 业务层：与访问连接的桥梁
• 应用层：代码、项目
• 数据层：数据
• 部署层：环境（硬件、云平台）

一、业务层

1.1 单体模式

单体模式就是以单业务为主，逐个业务线扩张，系统也呈现为多个MVC独立运行状态，每个业务一套系统，会带来很多问题：

技术架构上

• 相同的功能需要重复性的投资
• 业务系统间的集成和协作成本高
• 不利于基础性业务的沉淀和持续发展

组织架构上

• 部门在单体模式往往每一个项目团队跟随项目疯狂扩展，项目利用率低

1.2 中台战略

中台是一种企业架构，实际上是共享理念在业务、系统、组织架构上的落地实施

二、数据层

2.1 主从读写

• 连接多个数据库，数据之间形成主从关系，从库上读，读写压力被分散。
• 数据库集群：一主多从、双主单写
• 但是这个不能解决一个表过大的问题，就要考虑拆表的问题

2.2 分库分表

• 主从库的写入依然是有一个统一的主库入口。随着业务量的提升，继续细粒度化拆分业务分库:订单库，产品库，活动库，会员库
• 横向分表:(拆记录)3个月内订单，半年内订单，更多订单
• 纵向分表:(拆字段)name、phone-张表，info、address一张表，俩表id一致（根据活跃度拆表，通过字段关联起来）

2.3 高速缓存

• 一些热点数据放到redis中
• redis性能可靠，纯内存，子带分片，集群，哨兵，支持持久化
  存在的问题
• 缓存策略:冷热数据的存放，缓存与db的边界需要架构师去把控，重度依赖可能引发问题8XU(memcache造成db高压案例; redis短信平台故障案例)
• 缓存陷阱: 击穿（单- key过期)，穿透(不存在的 key)，雪崩(多个 key 同时过期)
• 数据一致性:缓存和 db 之间因为同一份数据保存了两份，自然带来了一致性问题

2.4 数据多样化

• 分类
  搜索引擎（ES）、缓存集群（mysql）、mysql集群、分布式文件、nosql

• 开发框架支持:
  存储的数据多样化，要求开发框架架构层面要提供多样化的支撑，并确保访问易用性
  数据运维:多种数据服务器对运维的要求提升，机器的数据维护与灾备工作量加大
  数据安全:多种数据存储的权限，授权与访问隔离需要注意

三、应用层

3.1 动静分离

3.2 SOA

解决服务之间的通信问题

3.3 微服务

• 方案
  微服务是基于SOA的思想，将系统粒度进一步细化而诞生的一种手段，中台化得以实现，各个中心以及前端业务拆解为多个小的服务单元
• 技术
  微服务经历了从1.0(cloud)到2.0的演化(service mesh)，目前企业中主流的解决方案依然是cloud全家桶Spring Cloud(课题:Spring Cloud微服务前沿技术栈，Spring、Spring Boot源码剖析)
• 特点
  服务拆分:粒度并非越小越好。太小会带来部署维护等一系列成本的上升。
  接口约束:系统增多，各个服务接口的规范化日益重要，要求有统一的服务接口规范，推动企业消息总线的建设
  权限约束:接口不是任意想调就可以调的，做好权限控制，借助oauth2等手段，实现服务之间的权限认证

四、部署层

4.1 角色划分

把数据据、缓存、消息等中间件剥离出去，单独机器部署

4.2 应用集群

• 方案
  • apache:早期负载均衡方案，性能一般
  • Nginx:7层代理，性能强悍，配置简洁，当前不二之选
  • haproxy:性能同样可靠，可做7层或4层代理
  • Ivs:4层代理，性能最强，linux集成，配置麻烦
  • f5:4层，硬件负载，财大气粗的不二选择
• 特点
  • session保持:集群环境下，用户登陆需要分布式session做支撑
  • 分布式协同:分布式环境下对资源的加锁要超出线程锁的范畴，上升为分布式锁
  • 调度问题:调度程序不能多台部署，容易跑重复，除非使用分布式调度，如elastic-job
  • 机器状态管理:多台应用机的状态检测与替换需要做到及时性，一般niginx层做故障转移
  • 服务升级:滚动升级成为可能，灰度发布
  • 日志管理:日志文件分散在各个机器，促进集中式日志平台的产生

4.3 多层代理

常见的代理工具：52528

4.4 异地访问

将相同的系统部署多份，分散到异地多个机房，或者电信、移动多个网络中
不同地点，不同网络接入的用户，有了不同的访问入口和选择

4.4 云平台

当部署数量增加时，出现了云平台，

• 方案

  • 虚拟化：Vmware
  • 容器化：docker
  • 容器编排工具：k8s
  • 云化解决了资源的快速伸缩，但仍需要企业自备大量机器资源，推动私有云到企业云进化

• 特点

  • 注意资源的回收，降低资源闲置和浪费，例如大促结束后要及时回收
  • 运维要求:需要运维层面的高度支撑，门槛比较高
  • 预估风险:云瘫痪的故障造成的损失不可估量