什么是架构分隔

单体

单体：是把系统部署到一台服务器上，所有的请求业务都由这台服务器处理

优点：适合小型系统，节省资源

缺点：安全性低，一旦有突发压力， 整个系统都会面临崩溃

分层—隔离效果

分层：分层架构的一个突出特性是组件间关注点分离 (separation of concerns)。一个层中的组件只会处理本层的逻辑。

比如说，展示层的组件只会处理展示逻辑，业务层中的组件只会去处理业务逻辑

组件分离，让我们更容易构造有效的角色和强力的模型。这样应用变的更好开发，测试，管理和维护。

忌：分层使架构变得复杂，我们不能为了分层而分层

纵向分层是为了什么

• 整体灵活性

分析:总体灵活性是响应环境变化的能力。尽管分层模式中的变化可以隔绝起来，想在这种架构中做一些也改变也是并且费时费力的。分层模式的笨重以及经常出现的组件之间的紧耦合是导致灵活性降低的原因。

• 易于部署

分析:这取决于你怎么发布这种模式，发布程序可能比较麻烦，尤其是很大的项目。一个组件的小小改动可能会影响到整个程序的发布(或者程序的大部分)。发布必须是按照计划，在非工作时间或者周末进行发布。因此。分层模式导致应用发布一点也不流畅，在发布上降低了灵活性。

• 可测试性

分析:因为组件都处于各自的层次中，可以模拟其他的层，或者说直接去掉层，所以分层模式很容易测试。开发者可以单独模拟一个展示组件，对业务组件进行隔绝测试。还可以模拟业务层来测试某个展示功能。

• 性能

分析:尽管某些分层架构的性能表现的确不错，但是这个模式的特点导致它无法带来高性能。因为一次业务请求要穿越所有的架构层，做了很多不必要的工作。

• 伸缩性

评级:低分析:由于这种模式以紧密耦合的趋势在发展，规模也比较大，用分层架构构建的程序都比较难以扩展。你可以把各个层分成单独的物理模块或者干脆把整个程序分成多个节点来扩展分层架构，但是总体的关系过于紧密，这样很难扩展。

• 易开发性

分析:在开发难度上面，分层架构得到了比较高的分数。因为这种架构对大家来说很熟悉，不难实现。大部分公司在开发项目的都是通过层来区分技术的，这种模式对于大多数的商业项目开发来说都很合适。公司的组织架构和他们软件架构之间的联系被戏称为”Conway’s law”。你可以Google一下查查这个有趣的联系。

隔离设计原则

1，第一个依据是基于目的划分层次。 以领域驱动设计的四层架构为例，之所以引入应用层（Application Layer）， 就是为了给调用者提供完整的业务用例

2，第二个依据是面对变化 分层时应针对不同的变化原因确定层次的边界，严禁层次之间互相干扰， 或者至少将变化对各层带来的影响降到最低

当然，并非二者之间没有关系，而是垂直相交的两条直线。唯一相关的依赖点是这两条直线的相交点， 即两层之间的协作点。正交的两条直线，无论哪条直线进行延伸，都不会对另一条直线产生任何影响。

架构分隔给高并发/高可用带来什么

异步隔离

时间换空间

把用户请求和处理，通过异步操作隔离开来。帮助软件实现更好效果

隔离熔断

通过架构分层，代码分块，主动适应市场的场景变化 当架构遇到风险冲击时，主动熔断，保障核心模块正常运转。

帮助系统架构实现高可用的效果，案例：微服务熔断

三层架构—给我们架构带来什么

在软件架构中，经典三层架构自顶向下由用户界面层（User Interface Layer）、业务逻辑层（Business Logic Layer）与数据访问层（Data Access Layer）组成。该分层架构之所以能够流行，是有其历史原因的。在提出该分层架构的时代，多数企业系统往往较为简单，本质上都是一个单体架构（Monolithic High）的数据库管理系统。这种分层架构已经是Client-Server架构的进化了，它有效地隔离了业务逻辑与数据访问逻辑，使得这两个不同关注点能够相对自由和独立地演化

阿里系-架构分层隔离

终端显示层：各端模板渲染并执行显示的层。当前主要是 Velocity 渲染，JS 渲染， JSP 渲染，移动端展示等。

开放接口层：将 Service 层方法封装成开放接口，同时进行网关安全控制和流量控制等。

Web 层：主要是对访问控制进行转发，各类基本参数校验，或者不复用的业务简单处理等。

Service 层：业务逻辑层。

Manager 层：通用业务处理层。这一层主要有两个作用，其一，你可以将原先 Service 层的一些通用能力下沉到这一层，比如与缓存和存储交互策略，中间件的接入；其二，你也可以在这一层封装对第三方接口的调用，比如调用支付服务，调用审核服务等

DAO 层：数据访问层，与底层 MySQL、Oracle、HBase 等进行数据交互。

外部接口或第三方平台：包括其它部门 RPC 开放接口，基础平台，其它公司的 HTTP 接口。

DDD领域-高并发场景

领域设计，业务逻辑聚合，业务处理分流

1.业务分流 2. 异步bus 3. domain集群

阿里VPC-服务器高可用

VPC概述：阿里云专有网络，帮助服务器架构高可用 实现弹性伸缩， 实现高并发效果

网络隔离内容：
1.生产环境/测试环境，VPC隔离
2.应用/数据服务器,采用安全组的概念隔离
3.给安全组设置限制规则，梳理常用的端口，给ECS设置IP白名单
4.搭建生产环境，堡垒机隔离，录屏，审计机制
5.搭建ECS服务器和OSS跨地域复制[可选]
6.对VPC搭建DDos高防IP防刷机制，
7.https域名设置。
ps：对于核心不能宕机服务器，需要买一定的DDos防刷流量.

微服务架构—高并发场景

高并发：阿里云slb，网关控制，核心业务冗余，多级缓存。微服务适度拆分。 核心业务，拆分细化，分流

高可用：熔断，nginx负载均衡，降低，CQRS架构，docker集群【反向代理】， docker【监控—杀dokcer---重启docker】【监控—杀domain--重启domain】

高可用—阿里云SLB负载均衡

负载均衡(SLB) 高可用+高并发架构实现 https://www.aliyun.com/product/slb?spm=5176.10695662.1112700.1.10397899RAMKVn

高并发/高可用拓展—中台架构

前台，高可用【slb,nginx】

中台 高可用需求[灾备，微服务]，高并发需求【缓存，ESS，同城双活】

后台 高并发需求，高可用【支付接口，重载】

高并发原则

无状态：应用无状态，配置文件有状态
拆分：系统维度、功能维度、读写维度、AOP维度、模块维度
服务化：进程内服务->单机远程服务->集群手动注册服务->自动注册和发现服务->服务分组/隔离/路由->服务治理（限流/黑名单）
消息队列：实现服务解耦、异步处理、流量削峰/缓冲（需要注意：处理生产消息失败、消息重复接收处理、生产重试；作为大流量缓冲，牺牲强一致性，保证最终一致性；需要数据校对）
数据异构：异构数据形成闭环，数据存储到合适的存储引擎；聚合数据，使前端通过少量调用拿到所需数据；依赖系统出问题，还能正常工作
缓存：

1. 浏览器缓存（时效性不强的数据）
2. APP客户端缓存（大促前提前下发素材到客户端）
3. CDN缓存（把资源推送到离用户最近的CDN节点）
4. 接入层缓存（没有CDN缓存可以考虑使用Nginx搭建一层接入层）
5. 应用层缓存（在应用所在机器上部署一组Redis，直接本机读取数据，多机之间主从同步数据）
6. 分布式缓存（数据量太多，单机存储不了，用分片机制分散流量到多台要，或用分布式缓存实现，
   常见的分片规则：一致性哈希算法）
   并发化