服务架构发展历程
目录
第一时期
第二时期
第三时期
第四时期
第一时期
1、分层开发
2、MVC架构
3、服务器分离部署
特点：
1、MVC分层开发（提高了维护性、解决了容错性问题）
2、数据库和项目分离部署
问题：
随着用户访问量持续增加，单台应用服务器已无法满足需求。（高并发问题）
解决方案：
集群（集群方案解决）
会出现的如下问题：
高并发、高可用、高性能
提高系统的并发能力：
集群操作：
集群：同一个业务，部署在多个服务器上
特点：
项目采用集群（多台服务器部署）
解决：
支持高并发、支持高可用
问题：
1、用户的请求该往哪里进行转发？、
通过nginx提供一个统一的服务入口，并通过nginx的负载均衡转发给服务器
2、Session如何共享？
通过Redis Cluster(Spring session+Redis)实现
问题：
数据库压力变大
我们通过nginx+redis集群方案 支持高并发（应用的性能进行提升访问），但是数据库的负载能力慢慢增加。
怎么提高数据库层面的访问压力？
解决方案;
1、读写分离
主从数据库之间进行数据同步。master主要负责增删改操作。slave负责读（查询）操作
mysql本身就支持master-slave的功能（主从复制）。
使用搜索引擎缓解数据库的访问压力+能力
数据库本身对大数据量查询效率慢，对模糊查询支持不是特别优秀，像电商类网站。搜索是非常核心的功能。（即使做了数据库读写分离），很多功能也不能有效解决（分析技术），针对该问题，有必要引入全文检索服务器功能。
目前市场上主流的搜索引擎技术：
Solr
ElasticSerach （对实时的性能比solr好一点）
whoosh（基于python的）
引入缓存机制减轻数据库的访问压力
随着访问能量的持续增加，（数据库的访问压力持续增加，甚至无法满足需求）。（虽然做了主从复制）。对于热点数据，如果每次都从数据库中查询，数据库无法应对，导致无法对外提供服务。
最佳解决方案：Redis
1、读写性能非常好（基于内存的 ）
2、提供了丰富 的数据类型。
3、原子性
数据库的表进行水平/垂直拆分
一张表中有1千条数据，查询效率很高
如果有100万条数据，查询性能很慢
单个表性能做提升。（垂直能力终归有限）
表为主
垂直：
假设一张表里面 用户表（有30个字段）
热数据/冷数据
拆成两个表
水平拆分：
按需求进行拆分。
分库分表:
采用第三方数据库中间件：mycat sharding-jdbc drds（阿里巴巴）
当前设计特点：
通过设计保证高并发、高可用（不断的对服务器进行扩容）
当前很多公司用的这种架构
问题：
1、服务器价钱？服务器越多，成本越高【服务器维护、人工成本】大量的运维工程师
2、可维护性差（一个服务器上的服务改动了，其他服务器也要改动）
3、可扩展性差（服务器）
4、协同开发不方便（大家都去修改相同业务代码，易发生代码冲突问题
5、单体架构（随着业务需求的不断增加，应用代码会变得越来越多）导致服务器部署时占用的硬盘也大。
第二时期
垂直应用架构
当访问量逐渐增大，单一应用架构机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。此时，用于加速前端页面开发的Web框架（MVC）是关键。
水平拆分：（横着拆）
将一个大的应用拆分成多个小应用
解决问题：
1、模块复用
2、减少了服务器内容部署变小
垂直拆分：（竖着拆）
按功能拆分 ：
将一个大的应用按照功能拆分成多个互不相干的小应用。每个应用都是独立的WEB的应用程序（分布式）
解决问题：
1、维护性能（如果发生需求变更，只需要调整某个应用模块即可）
2、功能扩展（随着业务的不断增加，只需要创建新的WEB程序即可）
3、协同开发方便（不同的团队修改不同的代码）
4、部署内容大小（性能扩展），如果哪台访问量大，只需要对该服务多部署几台即可。
此时，用于加速前端页面开发的web框架（MVC）是关键。
问题：
1、客户对页面 的要求越来越高？（修改频繁）需要重新部署后台应用程序？（每一个应用从头到尾都是完整的）。
2、随着业务的需求不断增增加，需要很多个互不相干应用部署？这些应用之间一定会需要业务交互？
第三时期
分布式服务架构：
当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使其那段应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的分布式服务框架（RPC）是关键。
分布式：将一个业务拆分成多个子业务，部署在不同的服务器上。
1、客户对页面 的要求越来越高？（修改频繁）（每一个应用从头到尾都是完整的）。
答：页面+业务代码（前后端分离）
2、随着业务的需求不断增增加，需要很多个互不相干应用部署？这些应用之间一定会需要业务交互？
架构的改变一定会带来一定的技术和新的问题
问题:
分布式事务、分布式锁、分布式session、分布式日志
第四时期
流动计算架构
