互联网架构的演进之路
互联网的四个阶段
- web 1.0 时代 传统广告业务化
- web 2.0 时代 内容产业数据化
- 互联网+ 移动互联网时代 生活服务业数据化
- 万物互联 云计算大数据时代 一切产业数据化
1. 第一阶段
单一应用架构
all in one 所有模块集中在一起，不做任何分层!
单机部署所有应用程序和软件，所有代码写在一块 称之为all in one
特点：
- 不具备代码可维护性
- 容错性差 （出错不容易恢复，无法捕获异常，处理异常，出错容易引起宕机）
分层开发
解决方案：
- 分层开发 （提高项目可维护性）【解决容错性】
- MVC 设计模式 （web 应用三层架构）
特点：
- MVC分层开发
- 数据库独立出来
出现问题：
随着用户访问量增长，但应用已经无法满足需求。
解决方案：
集群
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低
集群部署
集群：同一个业务，部署在多个服务器上。
特点：
- 项目采用多台服务器（集群）部署
优点：
- 支持高并发
- 支持高可用
问题：
- Session 如何共享
Redis Cluster 集群方案 - 用户请求如何转发
nginx 做请求分发，负载均衡
注意 ： 好多老公司用这套架构
解决数据库压力
nginx+tomcat 集群有效减少业务层压力，但此时数据库压力增大
1. 读写分离
解决方案：
读写分离，主从复制
主从数据库之间进行数据同步，master负载均衡，slave负载操作。
MySql 本身就提供主从复制功能
问题：
- 数据库本身对模糊查询的功能支持也不是很优秀，即使做了读写分离，也很难解决搜索业务使用搜索引擎缓解数据库访问压力
2. 引入搜索引擎
流行的搜索引擎技术 solr elasticsearch whoosh
引入缓存机制减轻数据库的访问压力
随着访问量的持续增加，数据库的访问压力变的越来越大（虽然做了主从复制）。对于这些热点数据（用户访问频繁的信息），如果每都到数据库中进行查询。（很多通用查询的功能）。
放在内存中又不特别合适。（手机登录验证码操作、为了IP限制频繁访问服务器…) 尝试使用Redis.
3. 数据库拆分
数据库的水平/垂直拆分。
垂直扩展 能力终归还是有限的。
单个表： 1000万–》1个亿数据 （单个表的数据能力终归还是有限的）
表：垂直拆分。
id ,name,age,bire…tel…remark…
热数据/冷数据 --》垂直拆分方案。
表：水平拆分。
按照：时间、地区、（按照业务逻辑进行拆分）。
分库分表：
采用第三方数据库中间件：mycat sharding-jdbc drds(阿里)
当前状态特点：
通过设计保证高可用、高并发。
（不断对服务器进行扩容，支持高并发，高可用）
问题：
- 服务器成本、维护成本，人工成本？
- 可维护性差
- 可扩展性差（组件重用性基本没有）
- 协同开发不方便 （大家都去改相同的业务代码，易发生代码错误/冲突）
- 单体架构（随着业务的不断增加，代码会变得越来越多），导致服务部署时文件越来越大。
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具有以来传递特性，依赖工程所依赖的项目会传递依赖过来，可以在父工程进行版本管理，提高项目规范）
解决问题：
- 模块复用
- 解决服务器部署内容大小
闲置了大量的服务器 （如果用户对某个层访问量过大时，只需要将该业务多部署一些服务即可）
（阿里云、百度云、腾讯云、新浪云、京东云······）
在没有出现云之前：
一些公司需不需要购买服务器+需要运维人员对服务进行维护。
行业：大量Linux 运维工程师
企业： 服务器托管企业
垂直拆分：
将大的单一应用，按功能模块进行拆分
解决问题：
- 可维护性（改需求，只需要改对应模块即可）
- 功能扩展（只需要加新的模块即可）
- 协同开发（不同团队，负责不同业务模块）
- 性能扩展（灵活部署，对访问量大的服务器，多部署）
问题：
- （用户对前端页面要求越来越大，修改越来越频繁）页面变化大，每一个应用从头到尾都是完整的，如果客户要对页面进行修改，整个应用服务都需要重新部署
- 随着业务的不断增加，应用模块会越来越多，各个模块之间一定需要业务交互？
4. 第三阶段
分布式架构
当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐步形成稳定的服务中心。使前端应用快速响应多变的市场需求，此时，用于提高业务复用及整合的分布式服务框架（RPC)是关键
分布式，将一个业务拆分多个子业务，部署不同服务器
针对如上情况
解决问题：
- （用户对前端页面要求越来越大，修改越来越频繁）页面变化大，每一个应用从头到尾都是完整的，如果客户要对页面进行修改，整个应用服务都需要重新部署
前后端分离 【横着拆】 - 随着业务的不断增加，应用模块会越来越多，各个模块之间一定需要业务交互？
- 分析：
以前在同一个服务器上（模块之间的依赖可以完成调用）
通过上图，发现不同的应用部署在不同服务器上，服务和服务之间的调用【进程间调用】
解决方案：
RPC / HTTP(RESTful)
RPC（Remote Procedure Call）- 远程过程调用，他是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。
架构的改变会带来新的技术和新的问题
分布式事务、分布式锁、分布式Session、分布式日志管理
问题：
- 服务和服务之间的调用，会变得非常混乱
- 服务越来越多，容量评估，小服务资源浪费等问题逐渐出现
5. 第四阶段
流动计算架构
当服务越来越多，容量的评估，小服务资源浪费等问题逐渐显现，此时只需要增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率，此时，用于提高机器利用率的资源调度和治理中心（SOA)是关键。
SOA 面向服务架构
功能： 解决多服务混乱问题
服务治理中间件(dubbo / springCloud )
基于访问压力实时管理集群容量，提高集群利用率，提高机器利用率的资源调度和治理中心
微服务架构 = 80%的SOA的服务架构思想 + 100%的组件化架构思想 + 80%的领域建模思想
第五阶段
微服务架构
微服务： 单体应用拆分成互不相干具备原子性的服务，每个小应用叫微服务
问题：
- 构建单体应用时，（SSM、web.xml、需要相应的所有jar、相应的配置文件）
当拆分成多个微服务应用时（需要大量的项目（服务）创建）
springBoot 出现为了简单代码的初始化构建和开发配置
总结：
优点：
- 每个微服务都很小，这样能聚焦一个指定的业务功能或业务需求。
- 微服务能够被小团队单独开发，这个小团队是2到5人的开发人员组成。
- 微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的。
- 微服务能使用不同的语言开发。
- 微服务允许容易且灵活的方式集成自动部署，通过持续集成工具，如Jenkins, bamboo 。
- 一个团队的新成员能够更快投入生产。
- 微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值。
- 微服务允许你利用融合最新技术。
- 微服务只是业务逻辑的代码，不会和HTML,CSS 或其他界面组件混合。
- 微服务能够即时被要求扩展。
- 微服务能部署中低端配置的服务器上。
- 易于和第三方集成。
- 每个微服务都有自己的存储能力，可以有自己的数据库。也可以有统一数据库。
缺点：
- 服务过多，服务管理（治理）成本高
- 不利于部署（Docker 镜像/容器 k8s）
- 技术难点增加（分布式事务、分布式锁、分布式Session、分布式日志）
- 对团队技术能力要求增高（dubbo/springCloud）
当前应用比较广的成熟的架构
传统的比较完善的
