一、特点

互联网应用架构具有高并发、大数据、快迭代、高风险等特点。

二、思维

互联网思维讲究“专注、极致、口碑、快”。

（1）“专注”是指技术发展路线专注于行业发展方向，设计上要“高内聚、低耦合”。

（2）“极致”是指互联网架构要对每个环节都做到极致的思考。

（3）“口碑”是指互联网架构一定要具备较高的可靠性和安全性。

（4）“快”是指互联网架构要满足快速开发迭代、快速诊断和部署的要求。

三、目标与度量

要满足低成本、高性能、易扩展、高可用、高安全的目标。

（1）低成本，实现技术架构要尽量控制成本，从时间阶段上可以分为建设成本、维护成本，从支出类型上可以分为硬件成本、商业中间件成本、软件开发成本等。

（2）高性能，网站性能指标具体体现在响应时间、并发数、吞吐量、系统错误率、系统负载等技术指标上。

系统的响应时间是指系统完成某一功能需要使用的时间，也就是从用户发出请求到收到结果所需要的时间，响应时间可能包括网络传输时间、服务处理、数据库处理时间等。
并发用户数是指系统可以同时承载的正常使用系统功能的用户的数量，准确地说是指同时发出请求的用户数。
系统的吞吐量（TPS）是指系统每秒处理的总的用户请求数。在性能测试中，TPS=VU×R/T，其中VU是同时发出请求的虚拟用户数目，R是每个虚拟用户发出的请求数目，T是性能测试所用的时间。
系统错误率是指系统在负载情况下，失败交易的概率。错误率=（失败交易数/交易总数）×100%。稳定性较好的系统，其错误率应该由超时引起，即为超时率。
资源利用率是各种计算机资源的使用情况，包括系统负载（Load）、内存利用率、SWAP内存交换空间利用率、网络I/O、硬盘I/O等。其中系统负载是系统CPU繁忙程度的度量，是指当前正在被CPU执行和等待被CPU执行的进程数目总和。
（3）高可用，系统的可用性（availability）指系统在面对各种异常时可以正确提供服务的能力。在系统测试过程中通过可靠性测试和稳定性测试保障系统的高可用。

可靠性指标：在双机热备、集群、备份和恢复等场景中，模拟主备切换、节点变更、备份与恢复的过程。
稳定性指标：系统按照最大容量的80%或在标准压力（系统的预期日常压力）情况下运行，能够稳定运行的最短时间。
（4）易扩展，系统的扩展性（scalability）指分布式系统通过扩展集群机器规模提高系统性能（吞吐、延迟、并发）、存储容量、计算能力的特性。互联网架构在设计时应支持无限扩展，在实施时可以按单日处理情况的三倍部署，遇重大营销推广活动时需要提前规划准备。

扩展能力的计算公式为：（增加性能/原始性能）/（增加资源/原始资源）×100%。

（5）高安全，系统上线前要使用代码检查工具和漏洞扫描工具对系统进行安全检查。业务场景较重要的，按照行业主管要求，达到三级等保标准，并按等保要求定期开展安全等级评测。

四、方法论

1. CAP模型
   CAP是指任何分布式系统在可用性、一致性、分区容错性方面，不能兼得，最多只能得其二，因此，任何分布式系统的设计只是在三者中的不同取舍而已。

■ C指Consistency，即一致性。

一致性被称为原子对象，任何读写都应该看起来是“原子”的或串行的。写后面的读一定能读到前面写的内容，所有的读写请求都好像被全局排序。即更新操作成功并返回客户端完成后，所有节点在同一时间的数据完全一致。

■ A指Availability，即可用性。

对任何非失败节点都应该在有限时间内给出请求的回应。

■ P指Partition tolerance，即分区容错性。

允许节点之间丢失任意多的消息，当网络分区发生故障时，节点之间的消息可能会完全丢失。即分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务。

要满足分区容错性的分布式系统，只能在一致性和可用性两者中选择一个。

2. CAP应用
   （1）CA：优先保证一致性和可用性，放弃分区容错。

（2）CP：优先保证一致性和分区容错性，放弃可用性。（ZooKeeper）

（3）AP：优先保证可用性和分区容错性，放弃一致性。（NoSQL中的Cassandra）

3. BASE理论
   BASE理论是对CAP理论的延伸，核心思想是即使无法做到强一致性（StrongConsistency，CAP的一致性就是强一致性），但应用可以采用适合的方式达到最终一致性（Eventual Consistency）。

BASE是指基本可用（Basically Available）、软状态（Soft State）、最终一致性（Eventual Consistency）。

基本可用：基本可用是指分布式系统在出现故障的时候，允许损失部分可用性，即保证核心可用。电商大促时，为了应对访问量激增，部分用户可能会被引导到降级页面，服务层也可能只提供降级服务，这就是损失部分可用性的体现。

软状态：软状态是指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。分布式存储中，一般一份数据至少有三个副本，允许不同节点间副本同步的延时就是软状态的体现。

最终一致性：最终一致性是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况。

4. ACID
   关系型数据库的事务操作遵循ACID原则，ACID原则是指在写入/异动资料的过程中，为保证交易正确可靠而必须具备的四个特性。

原子性（Atomicity，又称不可分割性）
在事务中执行的多个操作是原子性的，要么事务中的操作全部执行，要么一个都不执行。

一致性（Consistency）
保证进行事务的过程中整个数据库的状态是一致的，不会出现数据不一致的情况。

隔离性（Isolation，又称独立性）
两个事务不会相互影响，覆盖彼此数据等。

持久性（Durability）
事务一旦完成，那么数据应该被写到安全的、持久化存储的设备上（比如磁盘）。

5. AKF Scale Cube扩展立方体
   模型
   
   （1）X轴扩展
   水平复制，复制同样的工作或数据镜像给多个实体，通过克隆的方式水平扩展。一般是在负载均衡后面放置多个相同的应用服务，如果有N个相同的应用部署，那么每个单独的应用只需要处理1/N份的负载请求。

优点是简单易扩展。

缺点是当单体应用本身的复杂性提高时所带来的管理及运维挑战，例如针对特定事件的处理需要对整个应用进行发布部署，同时数据库的水平复制存在挑战。

（2）Y轴扩展
功能分解，拆分不同的事务进行扩展。针对X轴扩展产生的问题，从Y轴这个方向扩展，将巨型应用拆解，分解为一组不同的服务，把分割的工作职责和数据分配给多个实体，这也是微服务理论诞生的基础。例如将购物应用分解为购物车服务、订单服务、支付服务等。

优点是服务拆解以后便于维护和有针对性的扩展。

缺点是按功能拆解以后，服务数量增多，部署成本增高；服务与服务之间调用传输成本增高；由内存调用转变为网络传输，故障率增高。

（3）Z轴扩展
数据分区，是指按照客户的需求、位置或者价值分割或分配工作职责，一般来说就是对数据的扩展，将事务产生的数据按照一定的特征分区在不同的服务器上。如按照客户ID进行分库分表。

优点是对数据进行隔离，不同数据的请求被分发到不同的服务器上。

缺点是Z轴扩展是所有扩展中复杂度最高的。从传统的巨大的单体结构到如今面向服务的去IOE的架构，互联网核心架构的演变和发展就是在不断应用AKF扩展立方体模型。

三种扩展方式可以根据需要组合使用，但一定要选择与应用规模相符合的架构，例如一个面向小企业的企业内部信息系统就没必要进行Y轴扩展。

互联网架构的演进之路

互联网的四个阶段

1. web 1.0 时代 传统广告业务化

2. web 2.0 时代 内容产业数据化

3. 互联网+ 移动互联网时代 生活服务业数据化

4. 万物互联 云计算大数据时代 一切产业数据化

1. 第一阶段

单一应用架构

all in one 所有模块集中在一起，不做任何分层!

单机部署所有应用程序和软件，所有代码写在一块 称之为all in one

特点：

1. 不具备代码可维护性

2. 容错性差 （出错不容易恢复，无法捕获异常，处理异常，出错容易引起宕机）

分层开发

解决方案：

1. 分层开发 （提高项目可维护性）【解决容错性】
2. MVC 设计模式 （web 应用三层架构）
   

特点：

1. MVC分层开发

2. 数据库独立出来

出现问题：

随着用户访问量增长，但应用已经无法满足需求。

解决方案：

集群

2. 第一阶段 后期

引出问题

1. 高可用

“高可用性”（High Availability）通常来描述一个系统经过专门的设计，从而减少停工时间，而保持其服务的高度可用性。(一直都能用)

2.高并发

高并发（High Concurrency）是互联网分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计保证系统能够同时并行处理很多请求。

高并发相关常用的一些指标有响应时间（Response Time），吞吐量（Throughput），每秒查询率QPS（Query Per Second），并发用户数等。

响应时间：系统对请求做出响应的时间。例如系统处理一个HTTP请求需要200ms，这个200ms就是系统的响应时间。

吞吐量：单位时间内处理的请求数量。

QPS：每秒响应请求数。在互联网领域，这个指标和吞吐量区分的没有这么明显。

并发用户数：同时承载正常使用系统功能的用户数量。例如一个即时通讯系统，同时在线量一定程度上代表了系统的并发用户数。

提升系统的并发能力

提高系统并发能力的方式，方法论上主要有两种：垂直扩展（Scale Up）与水平扩展（Scale Out）。

1.垂直扩展

垂直扩展：提升单机处理能力。垂直扩展的方式又有两种：

（1）增强单机硬件性能，例如：增加CPU核数如32核，升级更好的网卡如万兆，升级更好的硬盘如SSD，扩充硬盘容量如2T，扩充系统内存如128G；

（2）提升单机架构性能，例如：使用Cache来减少IO次数，使用异步来增加单服务吞吐量，使用无锁数据结构来减少响应时间；

在互联网业务发展非常迅猛的早期，如果预算不是问题，强烈建议使用“增强单机硬件性能”的方式提升系统并发能力，因为这个阶段，公司的战略往往是发展业务抢时间，而“增强单机硬件性能”往往是最快的方法。

总结：
不管是提升单机硬件性能，还是提升单机架构性能，都有一个致命的不足：单机性能总是有极限的。所以互联网分布式架构设计高并发终极解决方案还是水平扩展。

2.水平扩展

水平扩展：只要增加服务器数量，就能线性扩充系统性能。水平扩展对系统架构设计是有要求的，难点在于：如何在架构各层进行可水平扩展的设计、可扩展性。

3. 高性能

高性能（High Performance）就是指程序处理速度快，所占内存少，cpu低

集群部署

集群：同一个业务，部署在多个服务器上。

特点：

1. 项目采用多台服务器（集群）部署

优点：

1. 支持高并发

2. 支持高可用

问题：

1. Session 如何共享

   Redis Cluster 集群方案

2. 用户请求如何转发

   nginx 做请求分发，负载均衡

注意 ： 好多老公司用这套架构

解决数据库压力

nginx+tomcat 集群有效减少业务层压力，但此时数据库压力增大

1. 读写分离

解决方案：

读写分离，主从复制

主从数据库之间进行数据同步，master负载均衡，slave负载操作。

MySql 本身就提供主从复制功能

问题：

1. 数据库本身对模糊查询的功能支持也不是很优秀，即使做了读写分离，也很难解决搜索业务使用搜索引擎缓解数据库访问压力

2. 引入搜索引擎

流行的搜索引擎技术 solr elasticsearch whoosh

引入缓存机制减轻数据库的访问压力

随着访问量的持续增加，数据库的访问压力变的越来越大（虽然做了主从复制）。对于这些热点数据（用户访问频繁的信息），如果每都到数据库中进行查询。（很多通用查询的功能）。

放在内存中又不特别合适。（手机登录验证码操作、为了IP限制频繁访问服务器…) 尝试使用Redis.

3. 数据库拆分

数据库的水平/垂直拆分。

垂直扩展 能力终归还是有限的。

单个表： 1000万–》1个亿数据 （单个表的数据能力终归还是有限的）

表：垂直拆分。

id ,name,age,bire…tel…remark…

热数据/冷数据 --》垂直拆分方案。

表：水平拆分。

按照：时间、地区、（按照业务逻辑进行拆分）。

分库分表：

采用第三方数据库中间件：mycat sharding-jdbc drds(阿里)

当前状态特点：

通过设计保证高可用、高并发。

（不断对服务器进行扩容，支持高并发，高可用）

问题：

1. 服务器成本、维护成本，人工成本？
2. 可维护性差
3. 可扩展性差（组件重用性基本没有）
4. 协同开发不方便 （大家都去改相同的业务代码，易发生代码错误/冲突）
5. 单体架构（随着业务的不断增加，代码会变得越来越多），导致服务部署时文件越来越大。

3. 第二阶段

垂直应用架构

当访问量逐渐增大，单一应用架构增加机器带来的加速越来越小，将应用拆成互不相干的几个应用，以提升效率，此时，用于加速前端页面开发的Web框架（MVC)是关键

水平拆分：

将大的单体应用，拆分多个小应用

横着拆 ：

exam-parent

1. exam-common   公共
2. exam-pojo           javaBean
3. exam-mapper     数据库操作
4. exam-service       业务逻辑
5. exam-web            前台
6. exam-admin        后台

利用父工程聚合，把各个层进行拆分，提高复用，需要应用时可以进行依赖注入。（注：Maven具有以来传递特性，依赖工程所依赖的项目会传递依赖过来，可以在父工程进行版本管理，提高项目规范）

解决问题：

1. 模块复用
2. 解决服务器部署内容大小

闲置了大量的服务器 （如果用户对某个层访问量过大时，只需要将该业务多部署一些服务即可）

（阿里云、百度云、腾讯云、新浪云、京东云······）

---

在没有出现云之前：

一些公司需不需要购买服务器+需要运维人员对服务进行维护。

行业：大量Linux 运维工程师

企业： 服务器托管企业

垂直拆分：

将大的单一应用，按功能模块进行拆分

解决问题：

1. 可维护性（改需求，只需要改对应模块即可）
2. 功能扩展（只需要加新的模块即可）
3. 协同开发（不同团队，负责不同业务模块）
4. 性能扩展（灵活部署，对访问量大的服务器，多部署）

问题：

1. （用户对前端页面要求越来越大，修改越来越频繁）页面变化大，每一个应用从头到尾都是完整的，如果客户要对页面进行修改，整个应用服务都需要重新部署
2. 随着业务的不断增加，应用模块会越来越多，各个模块之间一定需要业务交互？

4. 第三阶段

分布式架构

当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐步形成稳定的服务中心。使前端应用快速响应多变的市场需求，此时，用于提高业务复用及整合的分布式服务框架（RPC)是关键

分布式，将一个业务拆分多个子业务，部署不同服务器

针对如上情况

解决问题：

1. （用户对前端页面要求越来越大，修改越来越频繁）页面变化大，每一个应用从头到尾都是完整的，如果客户要对页面进行修改，整个应用服务都需要重新部署

   前后端分离 【横着拆】
   

2. 随着业务的不断增加，应用模块会越来越多，各个模块之间一定需要业务交互？
   
   分析：

以前在同一个服务器上（模块之间的依赖可以完成调用）

通过上图，发现不同的应用部署在不同服务器上，服务和服务之间的调用【进程间调用】

解决方案：

RPC / HTTP(RESTful)

RPC（Remote Procedure Call）- 远程过程调用，他是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。

架构的改变会带来新的技术和新的问题

分布式事务、分布式锁、分布式Session、分布式日志管理

---

问题：

1. 服务和服务之间的调用，会变得非常混乱
2. 服务越来越多，容量评估，小服务资源浪费等问题逐渐出现

5. 第四阶段

流动计算架构

当服务越来越多，容量的评估，小服务资源浪费等问题逐渐显现，此时只需要增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率，此时，用于提高机器利用率的资源调度和治理中心（SOA)是关键。

SOA 面向服务架构

功能： 解决多服务混乱问题

服务治理中间件(dubbo / springCloud )

基于访问压力实时管理集群容量，提高集群利用率，提高机器利用率的资源调度和治理中心

微服务架构 = 80%的SOA的服务架构思想 + 100%的组件化架构思想 + 80%的领域建模思想

第五阶段

微服务架构

微服务： 单体应用拆分成互不相干具备原子性的服务，每个小应用叫微服务

问题：

1. 构建单体应用时，（SSM、web.xml、需要相应的所有jar、相应的配置文件）

   当拆分成多个微服务应用时（需要大量的项目（服务）创建）

   springBoot 出现为了简单代码的初始化构建和开发配置

总结：

优点：

1. 每个微服务都很小，这样能聚焦一个指定的业务功能或业务需求。
2. 微服务能够被小团队单独开发，这个小团队是2到5人的开发人员组成。
3. 微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的。
4. 微服务能使用不同的语言开发。
5. 微服务允许容易且灵活的方式集成自动部署，通过持续集成工具，如Jenkins, bamboo 。
6. 一个团队的新成员能够更快投入生产。
7. 微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值。
8. 微服务允许你利用融合最新技术。
9. 微服务只是业务逻辑的代码，不会和HTML,CSS 或其他界面组件混合。
10. 微服务能够即时被要求扩展。
11. 微服务能部署中低端配置的服务器上。
12. 易于和第三方集成。
13. 每个微服务都有自己的存储能力，可以有自己的数据库。也可以有统一数据库。

缺点：

1. 服务过多，服务管理（治理）成本高

2. 不利于部署（Docker 镜像/容器 k8s）

3. 技术难点增加（分布式事务、分布式锁、分布式Session、分布式日志）

4. 对团队技术能力要求增高（dubbo/springCloud）

当前应用比较广的成熟的架构

传统的比较完善的