java架构相关
计算机知识思维导图：java架构相关。网页展示前三层结构，可在线查看完整脑图并下载 GoMind 文件。
2026-08-25
## java架构相关 ### java架构相关 #### 概述 ##### 三个纬度：演化、模式、要素 ##### 五个要素： 性能，可用性，伸缩性，扩展性，安全 #### 架构演化历程(环境) ##### 初始阶段的网站架构：一台服务器，上面同时拥有应用程序，数据库，文件，等所有资源。例如 LAMP 架构 ##### 应用和数据服务分离：三台服务器（硬件资源各不相同），分别是应用服务器，文件服务器和数据库服务器 ##### 使用缓存改善网站性能：分为两种，缓存在应用服务器上的本地缓存和缓存在专门的分布式缓存服务器的远程缓存 ##### 使用应用服务器集群改善网站并发处理能力：通过负载均衡调度服务器来将访问请求分发到应用服务器集群中的任何一台机器 ##### 数据库读写分离：数据库采用主从热备，应用服务器在写数据时访问主数据库，主数据库通过主从复制机制将数据更新同步到从数据库。应用服务器使用专门的数据访问模块从而对应用透明 ##### 使用反向代理和 CDN 加速网站响应：这两者基本原理都是缓存。反向代理部署在网站的中心机房，CDN 部署在网络提供商的机房 ##### 使用分布式文件系统和分布式数据库系统：数据库拆分的最后手段，更常用的是业务分库 ##### 使用 NoSQL 和搜索引擎：对可伸缩的分布式有更好的支持 ##### 业务拆分：将整个网站业务拆分成不同的应用，每个应用独立部署维护，应用之间通过超链接建立联系/消息队列进行数据分发/访问同一数据存储系统 ##### 分布式服务：公共业务提取出来独立部署 ##### 总结 #### 架构模式(方法) ##### 拆分(分层/分割) ##### 集群 ##### 分布式 ##### 缓存 ##### 异步 ##### 冗余 ##### 自动化 ##### 安全 #### 核心要素(目标) ##### 高性能 ##### 可用性(Availability)-高可用 ##### 伸缩性(Scalability) ##### 扩展性(Extensibility) ##### 安全性 #### 术语 ##### 面向服务的架构(SOA) #### 关键字 ##### 三个纬度：演化、模式、要素 ##### 五个要素： 性能，可用性，伸缩性，扩展性，安全 ##### 架构演化历程 ##### 架构模式 ##### 拆分(分而治之) ##### 冗余 ##### 异步/队列 ##### 性能 #### 参考 ##### ★ 大型网站技术架构-入门梳理 ##### 架构设计基础知识整理 ##### 一种适合创业公司的技术架构方案 ##### 大型网站架构技术一览 ##### ★ 各大互联网公司架构演进之路汇总 ##### 大型网站架构演化历程-HollisChuang's Blog ##### 白话网站架构演进 - 简书 ##### 软件架构模式 ##### 架构笔记-Q1n6 #### 主题资讯 ##### 掘金-标签-架构 ##### 推酷-主题-架构 ##### 推酷-站点-架构 ##### 架构师之路-微信公众号 ##### TechTarget SOA - 企业级面向服务架构专业SOA网站 - TechTarget中国 ##### 架构 & 设计 - infoQ.com ## 架构模式 ### 架构模式 #### 网站架构模式 ##### 1. 分层(横向) ##### 2. 分割(纵向) ##### 3. 分布式(横向/纵向) ##### 4. 集群 ##### 5. 缓存 ##### 6. 异步 ##### 7. 冗余 ##### 8. 自动化 ##### 9. 安全 #### 定义 ##### 分布式服务：可以将应用系统中共用的业务提取出来，独立部署。 ##### 软件架构：有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。 ##### 软件架构：性能、可用性、伸缩性、扩展性和安全性。 ##### 可用性 ##### 伸缩性 ##### 扩展性 #### 软件架构模式 ##### 分层架构 (Layered Architecture) ##### 污水池反模式（architecture sinkhole anti-pattern） ##### 巨石应用（Monolith） ##### 事件驱动架构 (Event-Driven Architecture) ##### 微内核架构 (Microkernel Architecture) ##### 微服务架构(Microservices architecture) ##### 基于空间的架构 (Space-Based Architecture) #### 软件架构模式2 ##### 八种架构设计模式及其优缺点概述 (上) ##### 八种架构设计模式及其优缺点概述(中) ##### 八种架构设计模式及其优缺点概述(下) #### 设计架构 ##### 服务层 ##### 前端 ##### 后端 ##### 其它 #### 参考 ##### 大型网站架构演化技术架构：核心原理与案例 - 推酷 ##### 软件架构模式 ##### 大型网站架构演化历程-HollisChuang's Blog ##### 如何设计一个牛掰的大型项目架构？ ##### 大型网站架构演化技术架构：核心原理与案例 ##### Web 前端项目的演进过程 ##### 从持续集成到弹性缩扩容：一个容器案例落地问题的思考 ##### 京东618：商城交易平台的高可用架构之路 ## 系统分层架构 ### 系统分层架构 #### 1.前端架构 ##### 浏览器优化技术 ##### CDN ##### 动静分离，静态资源独立部署 ##### 图片服务 ##### 反向代理 ##### DNS #### 2.应用层架构 ##### 开发框架 ##### 页面渲染 ##### 负载均衡 ##### Session管理 ##### 动态页面静态化 ##### 业务拆分 ##### 虚拟化服务器 #### 3.服务层架构 ##### 分布式消息 ##### 分布式服务 ##### 分布式缓存 ##### 分布式配置 #### 4.存储层架构 ##### 分布式文件 ##### 关系数据库 ##### NoSQL数据库 ##### 数据同步 #### 5.后台架构 ##### 搜索引擎 ##### 数据仓库 ##### 推荐系统 #### 6.数据采集与监控 ##### 浏览器数据采集 ##### 服务器业务数据采集 ##### 服务器性能数据采集 ##### 系统监控 ##### 系统报警 #### 7.安全架构 ##### Web攻击 ##### 数据保护 #### 8.数据中心机房架构 ##### 机房架构 ##### 机柜架构 ##### 服务器架构 #### 参考 ##### 大型网站架构技术一览 ## 分布式 ### 分布式 #### 分布式锁 ##### redis ##### zookeeper ##### 基于Consul的分布式锁实现 #### 分布式事务 ##### CAP定律 ##### JTA事务 ##### 分布式事务:两段式提交(最终一致性) #### 分布式消息队列(MQ框架) ##### Redis ##### zeromq ##### kafka ##### 阿里开源的RocketMQ ##### RabbitMQ ##### ActiveMq ##### 文章 ##### 比较 #### dubbo ##### DUBBO是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，是阿里巴巴SOA服务化治理方案的核心框架，每天为2,000+个服务提供3,000,000,000+次访问量支持，并被广泛应用于阿里巴巴集团的各成员站点。 #### 常见的分布式应用架构风格有三种 ##### 分布式对象（Distributed Objects，简称DO） ##### 远程过程调用（Remote Procedure Call，简称RPC） ##### 表述性状态转移（Representational State Transfer，简称REST） ##### DO和RPC这两种架构风格在企业应用中非常普遍，而REST则是Web应用的架构风格，它们之间有非常大的差别 #### 特性 ##### 分布式系统间的通讯接口,怎么防止外部调用 #### 以交易系统为例，看分布式事务架构的五大演进 ##### 单数据库事务 ##### 基于后置提交的多数据库事务 ##### 两段式事务 ##### TCC事务 #### 参考 ##### 理解本真的REST架构风格 ##### 基于Consul的分布式锁实现 ##### 分布式锁的三种实现方式 - 推酷 ##### Redis分布式锁----悲观锁实现,以秒杀系统为例 ##### Redis分布式锁----乐观锁的实现，以秒杀系统为例 - 推酷 ## 应用构建 ### 应用构建 #### 选型范围 ##### Dubbo ##### Spring Cloud #### 微服务 ##### 技术 ##### 关注 ##### 优点 ##### 缺点 ##### SOA比较 ##### 参考 #### 练习 ##### dubbo demo · 搜索 - 码云 - 开源中国 ##### dubbo · 搜索 - 码云 - 开源中国 #### 设计原则 ##### 隔离 ##### 自治 ##### 单一职责 ##### 有界上下文 ##### 异步通信 ##### 位置独立 ##### 参考 #### Dubbo-关键字 ##### 分布式服务框架 ##### RPC远程服务调用方案 ##### 软负载均衡及容错机制 ##### 自动发现 ##### Zookeeper #### 微服务-关键字 ##### 负载均衡与扩展(运营认识) ##### 服务发现 ##### 监控(服务扩容,缩容) ##### 持续交付(自动化流程) ##### 参考 #### 参考 ##### 秒杀系统的架构解决之道 - 推酷 ##### 基于Spring Boot和Spring Cloud实现微服务架构学习(四)-Spring Cloud总结 - zeb_perfect的专栏 - 博客频道 - CSDN.NET ##### SpringBoot之SpringCloud体验 - 王念博客 ##### 微服务架构的责任困境 ##### 入门 ##### Dubbo基于注解方式的配置 - _执着_的博客 - 博客频道 - CSDN.NET ##### 微服务架构的基础框架选择：Spring Cloud还是Dubbo？ ##### 关于dubbo的一切：生态圈 ##### 每天都在谈SOA和微服务，但你真的理解什么是服务吗？ ##### 微服务与SOA之间差了一个ESB ## 虚拟化 ### 虚拟化 #### 选型范围 ##### 物理机->虚拟机->Docker三层架构来实现虚拟化 #### 参考 ##### 秒杀系统的架构解决之道 - 推酷 ## 消息队列 ### 消息队列 #### 选型范围 ##### 阿里开源的RocketMQ #### 参考 ##### 秒杀系统的架构解决之道 - 推酷 ## 系统高可用架构 ### 系统高可用架构 #### 总结 ##### 高可用HA（High Availability）是分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计减少系统不能提供服务的时间。 ##### 方法论上，高可用是通过冗余+自动故障转移来实现的。 ##### 整个互联网分层系统架构的高可用，又是通过每一层的冗余+自动 故障转移 来综合实现的 #### 方法 ##### （1） 客户端层 到 反向代理层 的高可用，是通过反向代理层的冗余实现的，常见实践是keepalived ##### （2） 反向代理层 到 站点层 的高可用，是通过站点层的冗余实现的，常见实践是nginx与web-server之间的存活性探测与自动故障转移。 ##### （3） 站点层 到 服务层 的高可用，是通过服务层的冗余实现的，常见实践是通过service-connection-pool来保证自动故障转移。 ##### （4） 服务层 到 缓存层 的高可用，是通过缓存数据的冗余实现的，常见实践是缓存客户端双读双写，或者利用缓存集群的主从数据同步与sentinel保活与自动故障转移；更多的业务场景，对缓存没有高可用要求，可以使用缓存服务化来对调用方屏蔽底层复杂性。 ##### （5） 服务层 到 数据库“读” 的高可用，是通过读库的冗余实现的，常见实践是通过db-connection-pool来保证自动故障转移。 ##### （6） 服务层 到 数据库“写” 的高可用，是通过写库的冗余实现的，常见实践是keepalived #### 关键字 ##### 系统分层 ##### 冗余 ##### 自动故障转移 #### 参考 ##### 互联网高可用架构技术实践 ## 性能 ### 性能 #### 视角 ##### 1. 用户视角的网站性能 ##### 2. 开发人员视角的网站性能 ##### 3.运维人员视角的网站性能 主要优化手段 #### 性能测试指标 ##### 1. 响应时间 ##### 2. 并发数 ##### 3. 吞吐量 ##### 4. 性能计数器 #### 性能测试方法 ##### 性能测试：以系统设计初期规划的性能指标为预期目标，对系统不断施加压力，验证系统在资源可接受范围内，是否能达到性能预期 ##### 负载测试：对系统不断地增加并发请求以增加系统压力，直到系统的某项或多项性能指标达到安全临界值。 ##### 压力测试：查过安全负载的情况下，对系统继续施加压力，直到系统崩溃或不能再处理任何请求，以此获得系统最大压力承受能力。 ##### 稳定性测试：被测试系统在特定硬件、软件、网络环境条件下，给系统加载一定业务压力，使系统运行一段较长时间，以此检测系统是否稳定。 #### 性能测试报告 ##### 性能优化策略 #### 提高性能方向 ##### 方法 ##### 软件 ##### 硬件 ##### 总结 ##### 参考 #### 参考 ##### 大型网站架构演化技术架构：核心原理与案例 - 推酷 > 仅展示前三层结构；请在线查看完整脑图或下载 GoMind 文件。
java架构相关
java架构相关
三个纬度：演化、模式、要素
五个要素： 性能，可用性，伸缩性，扩展性，安全
概述
初始阶段的网站架构：一台服务器，上面同时拥有应用程序，数据库，文件，等所有资源。例如 LAMP 架构
应用和数据服务分离：三台服务器（硬件资源各不相同），分别是应用服务器，文件服务器和数据库服务器
使用缓存改善网站性能：分为两种，缓存在应用服务器上的本地缓存和缓存在专门的分布式缓存服务器的远程缓存
使用应用服务器集群改善网站并发处理能力：通过负载均衡调度服务器来将访问请求分发到应用服务器集群中的任何一台机器
数据库读写分离：数据库采用主从热备，应用服务器在写数据时访问主数据库，主数据库通过主从复制机制将数据更新同步到从数据库。应用服务器使用专门的数据访问模块从而对应用透明
使用反向代理和 CDN 加速网站响应：这两者基本原理都是缓存。反向代理部署在网站的中心机房，CDN 部署在网络提供商的机房
使用分布式文件系统和分布式数据库系统：数据库拆分的最后手段，更常用的是业务分库
使用 NoSQL 和搜索引擎：对可伸缩的分布式有更好的支持
业务拆分：将整个网站业务拆分成不同的应用，每个应用独立部署维护，应用之间通过超链接建立联系/消息队列进行数据分发/访问同一数据存储系统
分布式服务：公共业务提取出来独立部署
单机含库-单机分库-缓存改善-集群负载-读写分离-服务分布式&MQ-数据库分布式&中间件-微服务&zk
总结
架构演化历程(环境)
拆分(分层/分割)
负载均衡
集群
分层：结构分层
分割：业务分割,后分离
分布式
本地
远程
缓存
异步
冗余
自动化
安全
架构模式(方法)
响应时间：指应用执行一个操作需要的时间
并发数：指系统能够同时处理请求的数目
吞吐量：指单位时间内系统处理的请求数量
性能计数器：描述服务器或者操作系统性能的一些数据指标
指标
web前端性能
应用服务器性能
存储服务器性能
分类
性能优化：软(带宽限制,停顿发现,缓存,提前计算,事务降级,jvm,软均衡) ,硬
缓存机制：中层响应,下层模拟再同步,热点提取,内存提速 /缺点:牺牲一致性
最高性能的缓存应该在客户端,由于容量,范围等原因,每层都缓存的不同意义
第一级别的缓存是Session级别的缓存，它是属于事务范围的缓存。这一级别的缓存由hibernate管理
Session内置不能被卸载，Session的缓存是事务范围的缓存（Session对象的生命周期通常对应一个数据库事务或者一个应用事务）
持久化类的每个实例都具有唯一的OID
理解：事务间的save并未提交,而是放入一级缓存,再查询时可从缓存中提取。事务结束,session结束时同步数据库
session(连接会话)的缓存
下层模拟再同步
一级
第二级别的缓存是SessionFactory级别的缓存，它是属于进程范围或群集范围的缓存
SessionFactory对象的生命周期和应用程序的整个过程对应
Hibernate二级缓存是进程范围或者集群范围的缓存，有可能出现并发问题
需要采用适当的并发访问策略，该策略为被缓存的数据提供了事务隔离级别
SessionFactory的缓存(可选)
中层响应
二级
Hibernate中一级缓存和二级缓存使用详解
java框架篇---hibernate之缓存机制
mybatis的缓存机制（一级缓存二级缓存和刷新缓存）和mybatis整合ehcache
Hibernate缓存机制和MyBatis缓存机制 - 坦GA的博客 - 博客频道 - CSDN.NET
参考
Hibernate缓存
高性能
灾备：容灾备份
高可用的网站架构
幂等
无状态
异步(消息队列，削峰作用)
高可用的应用
冗余
高可用的服务
高可用的数据
快速定位、排查问题，并做出应急响应
核心业务指标变化
业务层面
实例、集群、机房等进行逐级汇总计算
JVM GC
满足百分之九十九的网络请求所需要的最低耗时
TP99
满足千分之九百九十九的网络请求所需要的最低耗时
TP999
TP99甚至TP999任何一指标低于预设阈值都会触发报警
调用链条薄弱环节的快速发现，快速解决
RPC服务之间、访问缓存、访问数据库
系统层面
带宽、丢包率、重传、连通性，CPU、内存、磁盘
网络质量和机器健康度/内网
基础设施
监控
可用性(Availability)-高可用
不同功能进行物理分离实现伸缩
单一功能通过集群规模实现伸缩
网站架构的伸缩性设计
http,DNS,反向代理,ip负载均衡
应用服务器集群的伸缩性设计
一致性Hash算法
分布式缓存集群的伸缩性设计
关系数据库集群
nosql数据库弹性伸缩
数据存储服务集群的伸缩性设计
伸缩性(Scalability)
构建可扩展的网站架构
利用分布式消息队列降低耦合性
利用分布式服务打造可复用的业务平台
可扩展的数据结构(如 ColumnFamily 设计)
利用开放平台建设网站生态圈
扩展性(Extensibility)
XSS 攻击
注入攻击
CSRF 攻击
其他攻击和漏洞：注释,文件上传,路径遍历
攻击与防御
单向散列加密
对称加密
非对称加密
密钥安全管理
信息加密技术及密钥安全管理
分类算法
黑名单
信息过滤与反垃圾
安全性
核心要素(目标)
面向服务的架构(SOA)
术语
三个纬度：演化、模式、要素
五个要素： 性能，可用性，伸缩性，扩展性，安全
架构演化历程
负载均衡
集群
分层：结构分层
分割：业务分割,后分离
分布式
本地
远程
缓存
异步
冗余
自动化
安全
架构模式
应用：前端,应用,服务
数据库：读写分离
横拆(上下分)
业务
竖切(左右分)
dubbo
Spring Cloud
拆分部署 = 分布式
拆分(分而治之)
容灾
高可用
集群
冗余
阿里开源的RocketMQ
消息队列
线程池
异步/队列
视角
指标
测试方法
性能
关键字
★ 大型网站技术架构-入门梳理
备份地址
架构设计基础知识整理
一种适合创业公司的技术架构方案
大型网站架构技术一览
★ 各大互联网公司架构演进之路汇总
单机含库-单机分库-缓存改善-集群负载-读写分离-服务分布式&MQ-数据库分布式&中间件-微服务&zk
大型网站架构演化历程-HollisChuang's Blog
白话网站架构演进 - 简书
软件架构模式
伸缩性和扩展性区别
大型网站技术架构读书笔记-伸缩性和扩展性架构
大型网站技术架构读书笔记-高可用架构
大型网站技术架构读书笔记-高性能架构
架构笔记-Q1n6
参考
掘金-标签-架构
推酷-主题-架构
推酷-站点-架构
架构师之路-微信公众号
TechTarget SOA - 企业级面向服务架构专业SOA网站 - TechTarget中国
【迷你书】 架构 & 设计 - infoQ.com
架构 & 设计 - infoQ.com
主题资讯
架构模式
架构模式
视图层（美工负责）
业务逻辑层（工程师负责）
（1）应用层
数据接口层（适配各种输入和输出的数据格式）
（2）服务层
1. 分层(横向)
如果说分层是将软件在横向方面进行切分，那么分割就是在纵向方面对软件进行切分
业务切分(微服务)
2. 分割(纵向)
对于大型网站，分层和分割的一个主要目的是为了切分后的模块便于分布式部署
即将不同模块部署在不同的服务器上，通过远程调用协同工作。 分布式解决网站高并发带来问题
（1）.分布式意味着服务调用必须通过网络，这可能对性能造成比较严重的影响。
（2）.服务器越多，服务器宕机的概率也就越大，一台服务器宕机造成的服务器不可用可能会导致很多应用不可访问，使网站可用性降低。
（3）.数据在分布式环境中保持数据一致性也非常困难。
（4）分布式导致网站依赖错综复杂，开发管理维护困难。
1.分布式应用和服务：将分层和分割后的应用和服务模块分布式部署
2.分布式静态资源：网站的静态资源独立分布式部署，并采用独立的域名，“动静分离”
3.分布式数据和存储：传统关系数据库和各种NoSQL几乎都是分布式的。
4.分布式计算：目前网站普遍使用Hadoop及其MapReduce分布式计算框架
5.分布式配置：支持网站线上服务器配置实时更新
6.分布式锁：分布式环境下实现并发和协同
7.分布式文件：支持云存储
分布式方案
3. 分布式(横向/纵向)
使用分布式已经将分层和分割后的模块独立部署，对于用户访问集中的模块（如网站首页），还需要将独立部署的服务器集群化
即多台服务器部署相同应用构成一个集群，通过负载均衡设备共同对外提供服务
4. 集群
缓存就是将数据存放在距离计算最近的位置以加快处理速度。缓存是改善软件性能的第一手段。
（1）.CDN
（2）.反向代理
（3）.本地缓存
（4）分布式缓存
途径
数据访问热点不均衡，某些数据会被更频繁的访问，这些数据应该放在缓存中
数据在某个时间段内有效，不会很快过期，否则缓存的数据会因已经失效而产生脏读，影响结果的正确性
使用缓存两个前提条件
5. 缓存
系统解耦的手段除了分层、分割、分布等，还有异步
业务之间的消息传递不是同步调用，二十将一个业务操作分成多个阶段，每个阶段之间通过共享数据的方式异步执行进行协作
（1）在单一服务器内通过多线程共享内存队列的方式实现异步。
（2）在分布式系统中多个服务器集群通过分布式消息队列实现异步，分布式消息队列可看做内存队列的分布式部署。
两者不存在直接调用，只要保持数据结构不变，彼此功能实现可以随意变化而不互相影响
异步架构是典型的生产者消费者模式
（3）提高系统可用性：消费者服务器发生故障，数据会在消息队列服务器中存储堆积，生产者服务器可以继续处理业务请求，系统整体表现无故障。消费者服务器回复正常后，继续处理消息队列中的数据。
（4）加快网站响应速度：处在业务处理前端的生产者服务器在处理完业务请求后，将数据写入消息队列，不需要等待消费者服务器处理就可以返回，响应延迟减少。
消除并发访问高峰：使用消息队列将突然增加的访问请求数据放入消息队列中，等待消费者服务器依次处理，就不会对整个网站造成太大压力。
6. 异步
访问和负载很小的服务也必须部署至少两台服务器构成一个集群，母的是通过冗余实现服务器高可用
数据库除了定期备份，存档保存，实现冷备份外，为了保证在线业务高可用，还需要对数据库进行主从分离，实时同步实现热备份。
7. 冗余
发布过程自动化
自动化代码管理
自动化测试
自动化安全检测
自动化部署
自动化监测
自动化报警
自动化失效转移
自动化失效恢复
自动化降级
自动化分配资源
8. 自动化
通过密码和手机校验码进行身份认证
登录、交易等操作需要对网络通信进行加密
防止机器人程序攻击网站，使用验证码识别
对于常见的用于攻击网站的XSS攻击、SQL注入等相应处理
对于垃圾信息、敏感信息进行过滤
对交易转账等重要操作根据交易模式和交易信息进行风险控制
会话,接口,网络攻击,业务风控
总结
9. 安全
网站架构模式
分布式服务：可以将应用系统中共用的业务提取出来，独立部署。
软件架构：有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。
软件架构：性能、可用性、伸缩性、扩展性和安全性。
网站高可用框架设计的前提是必然会出现服务器宕机，而高可用设计的目标就是当服务器宕机的时候，服务或者应用依然可用
网站高可用的主要手段是冗余，应用部署在多台服务器上同时提供访问，数据存储在多台服务器上互相备份，任何一台服务器宕机都不会影响应用的整体可用，也不会导致数据丢失
可用性
伸缩性是指通过不断向集群中加入服务器的手段来缓解不断上升的用户并发访问压力和不断增长的数据存储需求
是否可用多台服务器构建集群
是否容易向集群中添加新的服务器
衡量架构伸缩性的主要标准
应用服务器集群、缓存服务器集群、关系数据库、NoSQL数据库
伸缩性
衡量网站架构扩展性好坏的主要标准就是在网站增加新的业务产品时，是否可以实现对现有产品透明无影响，不需要任何改动或者很少改动既有业务功能就可以上线新产品
1. 事件驱动架构：通常利用消息队列实现
2.分布式服务：将业务和可复用服务分离开，通过分布式服务框架调用
3.开放平台接口：吸引第三方开发者，调用网站服务，使用网站数据开发周边产品
扩展性
定义
分层隔离有利于降低整个应用程序的复杂度
分层架构 (Layered Architecture)
大部分的请求都是仅仅穿过层，不做逻辑操作
污水池反模式（architecture sinkhole anti-pattern）
部署在一个web容器中运行的系统就叫做巨石型应用
DE都是为开发单个应用设计的、容易测试
在本地就可以启动完整的系统、容易部署
直接打包为一个完整的包，拷贝到web容器的某个目录下即可运行
巨石型应用有很多好处
要修改一个地方就要将整个应用全部部署
编译时间过长；回归测试周期过长；
开发效率降低等。
巨石应用不利于更新技术框架，除非你愿意将系统全部重写（代价太高你愿意老板也不愿意）
缺点
巨石应用（Monolith）
由高度解耦的，单一目的的事件处理组件组成，可以异步地接收和处理事件
调停者拓扑（Mediator Topology）
代理者拓扑（Broker Topology）
分布式异步架构模式
事件驱动架构 (Event-Driven Architecture)
也被称为插件架构（plugin architecture）模式
微内核架构 (Microkernel Architecture)
替代整体应用和面向服务架构（SOA）
核心概念是具备高可伸缩性、易于部署和交付的独立部署单元
最重要的概念是包含业务逻辑和处理流程的服务组件
应用拆分 xyz
实现方式 REST
基于HTTP协议的同步机制（REST、RPC）
基于消息队列的异步消息处理机制
内部服务之间的通信
关注
微服务架构(Microservices architecture)
基于云的架构
处理单元processing unit
虚拟化中间件virtualized middleware
模式有两个组件
基于空间的架构 (Space-Based Architecture)
软件架构模式
单库单应用模式：最简单的，可能大家都见过
内容分发模式：目前用的比较多
查询分离模式：对于大并发的查询、业务
微服务模式：适用于复杂的业务模式的拆解
多级缓存模式：可以把缓存玩的很好
分库分表模式：解决单机数据库瓶颈
弹性伸缩模式：解决波峰波谷业务流量不均匀的方法之一
多机房模式：解决高可用、高性能的一种方法
架构模式
单库单应用模式、 内容分发模式
八种架构设计模式及其优缺点概述 (上)
查询分离模式、 微服务模式、 多级缓存模式
八种架构设计模式及其优缺点概述(中)
分库分表模式 、 弹性伸缩模式 、 多机房模式
八种架构设计模式及其优缺点概述(下)
软件架构模式2
集群-提供伸缩性,性能可提高,容灾能力|弹性伸缩可结合虚拟化技术docker+监控
分布式-横向拆分：前后端分离,api分离/竖向拆分:(业务能力划分服务) SOA,微服务思想 取决于服务模式
冗余-高可用支持
服务层
自主的工程化策略,整体架构角度关注流量,缓存/cdn
前端
使用一些分布式框架和中间件,支撑开发的效率运作和高性能高可用目标支持
性能上关注缓存和异步还能解耦
一致性上关注事务和并发
可用性上适当冗余保障服务可用。弱可用上关注监控,快速恢复的能力(自动化)
后端
架构5要素为指导
方法还是分布式,异步通用的计算机结构思想
数据库,存储,安全,机房
监控：业务,系统,设施/数据指标阈值观察(业务数据,jvm gc,调用链)
其它
设计架构
大型网站架构演化技术架构：核心原理与案例 - 推酷
分层-巨石-事件MQ-服务化SOA-微服务-云服务-无服务
软件架构模式
单机含库-单机分库-缓存改善-集群负载-读写分离-服务分布式&MQ-数据库分布式&中间件-微服务&zk
大型网站架构演化历程-HollisChuang's Blog
单服务,数据库分离,缓存,集群,MQ,读写分离,分布式,数据拆分
如何设计一个牛掰的大型项目架构？
大型网站架构演化技术架构：核心原理与案例
简单-复杂-多页-单页-前后分离-模块化-工程化
Web 前端项目的演进过程
从持续集成到弹性缩扩容：一个容器案例落地问题的思考
京东618：商城交易平台的高可用架构之路
参考
系统分层架构
系统分层架构
浏览器优化技术
CDN
动静分离，静态资源独立部署
图片服务
反向代理
DNS
1.前端架构
开发框架
页面渲染
负载均衡
Session管理
动态页面静态化
业务拆分
虚拟化服务器
2.应用层架构
分布式消息
分布式服务
分布式缓存
分布式配置
3.服务层架构
分布式文件
关系数据库
NoSQL数据库
数据同步
4.存储层架构
搜索引擎
数据仓库
推荐系统
5.后台架构
浏览器数据采集
服务器业务数据采集
服务器性能数据采集
系统监控
系统报警
6.数据采集与监控
Web攻击
数据保护
7.安全架构
机房架构
机柜架构
服务器架构
8.数据中心机房架构
大型网站架构技术一览
参考
分布式
分布式
redis
zookeeper
基于Consul的分布式锁实现
分布式锁
CAP定律
JTA事务
分布式事务:两段式提交(最终一致性)
分布式事务
基于Key-Value对的NoSQL数据库，开发维护很活跃
Redis
号称最快的消息队列系统，尤其针对大吞吐量的需求场景
zeromq
高吞吐量的分布式发布订阅消息系统
非常特殊的消息机制，不同于传统的mq
kafka
捐apache
阿里开源的RocketMQ
使用Erlang编写的一个开源的消息队列
RabbitMQ
高性能跨语言分布式发布/订阅消息队列系统，而Jafka是在Kafka之上孵化而来的，即Kafka的一个升级版
ActiveMq
RabbitMQ、ActiveMQ、ZeroMQ、Kafka之间的比较汇总
rabbitMQ、activeMQ、zeroMQ、Kafka、Redis 比较 - 二郎神 - 博客园
关于消息队列的使用----ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，RocketMQ
文章
如果你用kafka做通讯总线那绝对的不会快只能更慢；
kafka在乎的是性能，速度
你想要rabbitmq实现分布式，那真的是难为它
rabbitmq追求的是灵活
如果你拿zeromq来做大数据量的传输功能，不是生产者的内存“爆掉”就是消费者被“压死”
zeromq追求的是轻量级、分布式
有无broker(中间商)
zeroMq 不支持 ， activeMq 和 rabbitMq 都 支持
持久化消息
RabbitMq最好，ActiveMq次之，ZeroMq最差
技术点：可靠性、灵活的路由、集群、事务、高可用的队列、消息排序、问题追踪、可视化管理工具、插件系统、社区
比较
分布式消息队列(MQ框架)
DUBBO是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，是阿里巴巴SOA服务化治理方案的核心框架，每天为2,000+个服务提供3,000,000,000+次访问量支持，并被广泛应用于阿里巴巴集团的各成员站点。
dubbo
架构实例有CORBA/RMI/EJB/DCOM/.NET Remoting等等
分布式对象（Distributed Objects，简称DO）
架构实例有SOAP/XML-RPC/Hessian/Flash AMF/DWR等等
远程过程调用（Remote Procedure Call，简称RPC）
架构实例有HTTP/WebDAV
表述性状态转移（Representational State Transfer，简称REST）
DO和RPC这两种架构风格在企业应用中非常普遍，而REST则是Web应用的架构风格，它们之间有非常大的差别
常见的分布式应用架构风格有三种
ip限制
appid+appsecret => token
分布式系统间的通讯接口,怎么防止外部调用
特性
单数据库事务
基于后置提交的多数据库事务
prepare预提交与commit确认提交
两段式事务也就是著名的XA事务
XA是由X/Open组织提出的分布式事务的规范
两段式事务
TCC事务的全称为：Try-Confirm/Cancel，翻译成中文即：尝试、确定、取消
TCC事务是一种编程模式，如果SOA接口的提供者与调用者都遵从TCC编程模式，那么就能最大限度的保证数据一致性
非TCC模式的扣除金币操作，接口提供者只需要提供一个SOA接口即可，接口的作用就是扣除金币
扣除金币Try接口，尝试扣除金币
扣除金币Confirm接口，确定扣除金币
扣除金币Cancel接口，取消扣除金币
而TCC模式的扣除金币操作，接口提供者针对扣除金币这一操作需要提供三个SOA接口
差异
TCC事务
以交易系统为例，看分布式事务架构的五大演进
常见的分布式应用架构风格有三种
理解本真的REST架构风格
基于Consul的分布式锁实现
分布式锁的三种实现方式 - 推酷
Redis分布式锁----悲观锁实现,以秒杀系统为例
Redis分布式锁----乐观锁的实现，以秒杀系统为例 - 推酷
参考
应用构建
应用构建
Zookeeper 注册中心
Zookeeper和Dubbo本来没什么关系，只不过Dubbo可以用Zookeeper做注册中心
有了注册中心，就不用像CXF那样，要配置服务端和客户端的url了
注册中心充当了一个中介的作用，注册服务和订阅服务只要找注册中心就可以了
Zookeeper作为Dubbo服务的注册中心，Dubbo原先基于数据库的注册中心，没采用Zookeeper，Zookeeper一个分布式的服务框架，是树型的目录服务的数据存储，能做到集群管理数据 ，这里能很好的作为Dubbo服务的注册中心，Dubbo能与Zookeeper做到集群部署
Dubbo和Zookeeper的关系
Provider: 暴露服务的服务提供方。
Consumer: 调用远程服务的服务消费方。
Registry: 服务注册与发现的注册中心。
Monitor: 统计服务的调用次调和调用时间的监控中心。
Container: 服务运行容器
节点角色说明
Dubbo
Spring Cloud
选型范围
快速构建并运行 Spring 应用程序
Spring Boot
分布式系统的一套工具，可用于构建微服务
Spring Cloud
spring For all
ESB（企业数据总线）
我们开始一个项目整个开发环境就要搭建一个很长的时间，期间如果加入更多的特性时还要更麻烦，spring boot把大量的常见组件都组合了起来，比如 hibernate jdbc mongodb jmx等等很多很多，只要引入相关的组件基本上就是零配置就可以用了
一种是为了搭建一个服务用的，比如hibernate jpa，比如 message。
另外一种含有cloud关键字的，是为了各个spring boot之前管理和使用的包
spring boot的官方的包分为两类
无聊的家伙
使用spring 家族一系列的技术，需要一个一个的搞配置，然后还有个版本兼容性问题，其实挺麻烦的，偶尔也会有小坑出现，其实蛮影响开发进度，spring boot 就是来解决这个问题，提供了一个解决方案吧
三流程序员
Spring cloud 是一套微服务框架
Spring boot 是 Spring 的一套快速配置脚手架
Spring cloud 基于 Spring boot 这套快速脚手架，加快初始配置时间
如果对 Spring 理解够深的话，不用 Spring boot 也能玩转，就是太繁琐了。配置太多
一个写代码的男人
网友见解
Spring Boot
spring Cloud是一个基于Spring Boot实现的云应用开发工具，它为基于JVM的云应用开发中的配置管理、服务发现、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等操作提供了一种简单的开发方式
spring Cloud
Untitled node
Spring Cloud与Dubbo对比
api风格(RPC/REST)：面向操作与资源,定义操作语义,动作局限,资源访问约定,演化
想染指系统架构？看这篇就够了 - 推酷
更多见：
RPC vs REST
阿里巴巴的hsf、dubbo（开源）
Facebook的thrift（开源）
Google grpc（开源）
Twitter的finagle
选择
技术
分布式（微服务天生就是分布式的）
基础设施：扩缩容的设备配合,高度复杂的自动化流程
负载均衡和扩展：与巨石应用相比,增加了更多的分层分片的维度
zeekeeper / redis
Eureka 作为服务发现工具
Eureka 是 Netflix 贡献出来的开源中间层负载均衡和服务发现的工具
处理 RPC 调用的软负载均衡
Ribbon 作为负载均衡
Netflix
跨语言服务端调用的解决方案
ZeroC Ice
可伸缩的跨语言服务开发框架
传输数据采用二进制格式
Apache Thrift - Facebook
跨语言
服务发现：
开发模式的转变,团队的适应
关注
每个服务足够内聚，足够小，代码容易理解、开发效率提高
服务之间可以独立部署，微服务架构让持续部署成为可能;
每个服务可以各自进行x扩展和z扩展，而且，每个服务可以根据自己的需要部署到合适的硬件服务器上;
容易扩大开发团队，可以针对每个服务(service)组件开发团队;
提高容错性(fault isolation)，一个服务的内存泄露并不会让整个系统瘫痪;
系统不会被长期限制在某个技术栈上。
总结：蚂蚁吃大象(拆分),服务治理(监控,伸缩),容错(部件失效不影响全局)
开发团队是自主的，围绕着交付业务价值而不是技术特性来组织。
优点
开发人员要处理分布式系统的复杂性;开发人员要设计服务之间的通信机制，对于需要多个后端服务的user case，要在没有分布式事务的情况下实现代码非常困难;涉及多个服务直接的自动化测试也具备相当的挑战性;
服务管理的复杂性，在生产环境中要管理多个不同的服务的实例，这意味着开发团队需要全局统筹(PS：现在docker的出现适合解决这个问题)
应用微服务架构的时机如何把握?对于业务还没有理清楚、业务数据和处理能力还没有开始爆发式增长之前的创业公司，不需要考虑微服务架构模式，这时候最重要的是快速开发、快速部署、快速试错。
容器化&容器编排系统
运营成本的增加
你的应用会被拖慢
本地开发变得更加困难
难以伸缩
先决条件可以说是技术领域的能力成熟度模型
够了，不要一上来就把微服务说的神乎其神
总结：开发模式的变化,自动化要求,团队的契合
缺点
通过服务的组合和编排来实现上层的业务流程
作用：简化维护,降低整体风险,伸缩灵活
SOA[组装服务/ESB企业服务总线]
SOA到微服务架构的演进过程
作用：各服务可独立应用，组合服务也可系统应用(巨石应用[monolith]的简化实现策略-平台思想)
微服务[找到服务/微服务网关open API]
服务组合集成部署/服务发现独立部署
总结
SOA比较
基于微服务的软件架构模式
敏捷性-组织更迅速地适应他们业务环境的改变
灵活性 - 在 SOA 中坚持良好的软件工程实践能够提高 IT 对业务需求的响应
优点
组织结构的改变
监控复杂性
缺点
转变并不容易
文化改变
可能无法实现统一
糟糕
SOA 的优点、缺点与糟糕之处
Netflix如何在上万台机器中管理微服务？
参考
微服务
zookeeper的安装和启动 - 飞龙在天001 - 博客园
dubbo demo · 搜索 - 码云 - 开源中国
dubbo · 搜索 - 码云 - 开源中国
练习
服务间相互隔离工作
隔离
各服务,自主自治
自治
服务必须设计为高度凝聚
单一职责
领域驱动设计（DDD）建模方法
有界的上下文是关于微服务将提供其服务功能的上下文
有界上下文
跨边界的服务通信必须是异步的
异步通信
虚拟化环境或docker容器中部署
位置独立
微服务设计原则 - 推酷
参考
设计原则
分布式服务框架
RPC远程服务调用方案
软负载均衡及容错机制
自动发现
Zookeeper
Dubbo-关键字
负载均衡与扩展(运营认识)
服务发现
监控(服务扩容,缩容)
持续交付(自动化流程)
为什么说微服务并不适合每个人？ - 推酷
参考
微服务-关键字
秒杀系统的架构解决之道 - 推酷
基于Spring Boot和Spring Cloud实现微服务架构学习(四)-Spring Cloud总结 - zeb_perfect的专栏 - 博客频道 - CSDN.NET
SpringBoot之SpringCloud体验 - 王念博客
微服务架构的责任困境
分布式服务框架 dubbo/dubbox 入门示例
Dubbo分布式服务框架入门（附工程）
阿里巴巴dubbo《用户指南》
Dubbo初探 - 推酷
一个简单的 dubbo 服务 - 推酷
dubbo 简介与 dubbo demo 运行
入门
Dubbo基于注解方式的配置 - _执着_的博客 - 博客频道 - CSDN.NET
微服务架构的基础框架选择：Spring Cloud还是Dubbo？
关于dubbo的一切：生态圈
每天都在谈SOA和微服务，但你真的理解什么是服务吗？
微服务与SOA之间差了一个ESB
参考
虚拟化
虚拟化
物理机->虚拟机->Docker三层架构来实现虚拟化
选型范围
秒杀系统的架构解决之道 - 推酷
参考
消息队列
消息队列
阿里开源的RocketMQ
选型范围
秒杀系统的架构解决之道 - 推酷
参考
系统高可用架构
系统高可用架构
高可用HA（High Availability）是分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计减少系统不能提供服务的时间。
方法论上，高可用是通过冗余+自动故障转移来实现的。
整个互联网分层系统架构的高可用，又是通过每一层的冗余+自动 故障转移 来综合实现的
总结
virtual IP自动故障转移。
（1） 客户端层 到 反向代理层 的高可用，是通过反向代理层的冗余实现的，常见实践是keepalived
（2） 反向代理层 到 站点层 的高可用，是通过站点层的冗余实现的，常见实践是nginx与web-server之间的存活性探测与自动故障转移。
（3） 站点层 到 服务层 的高可用，是通过服务层的冗余实现的，常见实践是通过service-connection-pool来保证自动故障转移。
（4） 服务层 到 缓存层 的高可用，是通过缓存数据的冗余实现的，常见实践是缓存客户端双读双写，或者利用缓存集群的主从数据同步与sentinel保活与自动故障转移；更多的业务场景，对缓存没有高可用要求，可以使用缓存服务化来对调用方屏蔽底层复杂性。
（5） 服务层 到 数据库“读” 的高可用，是通过读库的冗余实现的，常见实践是通过db-connection-pool来保证自动故障转移。
virtual IP自动故障转移
（6） 服务层 到 数据库“写” 的高可用，是通过写库的冗余实现的，常见实践是keepalived
方法
系统分层
冗余
自动故障转移
关键字
互联网高可用架构技术实践
参考
性能
性能
1. 用户视角的网站性能
2. 开发人员视角的网站性能
3.运维人员视角的网站性能 主要优化手段
视角
1. 响应时间
2. 并发数
3. 吞吐量
4. 性能计数器
性能测试指标
性能测试：以系统设计初期规划的性能指标为预期目标，对系统不断施加压力，验证系统在资源可接受范围内，是否能达到性能预期
负载测试：对系统不断地增加并发请求以增加系统压力，直到系统的某项或多项性能指标达到安全临界值。
压力测试：查过安全负载的情况下，对系统继续施加压力，直到系统崩溃或不能再处理任何请求，以此获得系统最大压力承受能力。
稳定性测试：被测试系统在特定硬件、软件、网络环境条件下，给系统加载一定业务压力，使系统运行一段较长时间，以此检测系统是否稳定。
性能测试方法
检查请求处理的各个环节的日志，分析哪个环节响应时间不合理、超过预期。
检查监控数据，分析影响性能的主要因素是内存、磁盘、网络、还是CPU，是代码问题还是架构设计不合理，或者系统资源确实不足
1. 性能分析
Web前端性能优化
应用服务器性能优化
存储服务器性能优化
Web前端性能优化
2. 性能优化
1. 减少http请求
2. 使用浏览器缓存
3. 启用压缩
4. CSS放在页面最上面、JavaScript放在页面最下面
5. 减少Cookie传输
CDN加速
浏览器访问优化
性能优化策略
性能测试报告
性能测试诊断
netstat,tcpdump抓包
工具：火焰图、perf、perf-map-java
jvisualvm,jconsole,gc,jstack,Memory dump
方法
web容器http连接数,超时时间
应用程序连接数
数据库连接数
带宽限制放开
锁停顿优化(不锁,异步)
DB停顿优化(cache)
停顿发现
内核参数-内存分配,回收
服务器优化-linux
客户端cache
网络cdn cache
web容器cache
server服务cache
数据 cache
缓存cache
ram优化
GC优化
jvm优化
集群
nginx负载均衡
软件
集群
F5负载均衡
CPU,io,ram
硬件
软件(带宽限制,停顿发现,缓存,内核参数,jvm,软均衡) 硬件(F5,扩容)
总结
万亿级数据洪峰下的分布式消息引擎
10+倍性能提升全过程--优酷账号绑定淘宝账号的TPS从500到5400的优化历程
参考
提高性能方向
大型网站架构演化技术架构：核心原理与案例 - 推酷
参考