传统架构（单点应用）-->分布式架构（以项目进行拆分）-->SOA架构(面向服务架构)
项目表达的意思：包含业务逻辑层和视图层，项目包含：前台项目（提供给用户）和后台项目（维护管理）
服务表达的意思：只包含业务逻辑层，没有视图层。
传统架构
1.单体应用架构
2.集群应用架构
把同一个业务部署在不同的服务器上
特点：项目采用多台服务器（集群）部署
优点：
支持高可用
支持高并发
问题1：session如何共享？
使用Redis Cluster集群方案
问题2：这些集群的服务器，用户的请求该怎么转发？
使用nginx服务器来完成分发请求，实现负载均衡策略。
3.高并发架构
数据库压力变大：集群方案nginx+tomcat将应用层的性能进行有效的提升，但是数据库负载压力慢慢增加，如何来减轻数据库访问压力？
解决方案：
1.读写分离
主从数据库之间进行数据同步。master负载增删改操作，slave负载读操作。mysql本身就提供了master-salve的方式完成主从复制功能。
2.使用搜索引擎缓解数据库的访问压力和提高能力
数据库做读库的情况下，数据库本身对模糊查询的功能支持不是特别优秀，像电商类的网站，搜索是非常核心的功能模块。即使做了读写分离。这个问题也不能有效解决电商网站查询（分词技术）等。针对该问题，有必要引入搜索引擎技术。
3.使用缓存技术
随着访问量的持续增加，数据库的访问压力变得越来越大（虽然做了主从复制）。对于这些热点数据（用户访问频繁的信息），如果每次都到数据库中进行查询。（很多通用查询的功能）。放在内存中又特别不合适。（手机登录验证码操作，为了IP限制频繁访问服务器。。。）尝试使用Redis
4.数据库的水平/垂直拆分
垂直扩展能力终归还是有限的。
单个表：1000万->1个亿数据（单个表的数据能力终归还是有限的）
表：垂直拆分。
id,name,age,bire....表中的字段（按字段拆分）
热数据/冷数据-->垂直拆分方案。
表：水平拆分
按照：时间、地区、（业务逻辑进行拆分）
分库分表：
采用第三方中间件:mycat/sharding-jdbc/drds
当前状态的特点：
通过设计保证高可用、高并发（不断对服务器进行扩容。。。）
问题1：各方面的成本不断增加
问题2：可维护性差
问题3：可扩展性差
问题4：协同开发不方便。（大家都去改相同的业务代码，容易发生代码冲突）
问题5：单体架构（随着业务的不断增加，代码会变得越来越多）。导致服务部署时，文件变得越来越大。
4.垂直应用架构
当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。此时，用于加速前端页面开发的web框架（mvc）是关键。
水平拆分：
把一个大的单体应用，拆分成多个小应用。
横着拆：
exam: exam-pojo、exam-mapper、exam-service、exam-web
解决的问题：
1.模块复用
2.解决服务器部署的内容变小
闲置了大量服务器（如果用户对某个层访问量过大，只需要把该层业务多部署下服务即可）
垂直拆分：
将一个大的应用拆成互不相关的几个小应用，每个应用是独立部署的。
解决问题：
问题2：可维护性（如果想做需求变更，只需要调整某个应用模块即可）
问题3：可扩展性（随着业务的不断增加，只需要创建新的应用即可）
问题4：协同开发方便（不同团队修改不同的业务）
问题5：性能扩展/部署内容大小（只需要对访问量大的服务器多部署几台）
问题1：
（客户对页面的要求变得越来越高，修改会越来越频繁）页面变化大，每一个应用从头到尾都是完整的，如果客户要对页面进行修改，这个应用就要重新部署。
问题2：
随着业务的不断增加，应用模块越来越多，每个模块之间一定需要业务进行交互
=========================================================================================================================================
分布式架构
分布式：每一个业务拆分成多个子业务，部署在不同的服务器上。
针对如上情况：
问题1：（客户对页面的要求变得越来越高，修改会越来越频繁）页面变化大，每一个应用从头到尾都是完整的，如果客户要对页面进行修改，这个应用就要重新部署。
答：界面+业务逻辑实现分离（前后端分离开发）【横着拆，水平拆分】
问题2：随着业务的不断增加，应用模块越来越多，每个模块之间一定需要业务进行交互
分析：
以前如果在同一台服务器上，（模块的依赖进程来完成调用）
通过上图发现，不同的应用部署在不同的服务器上，服务和服务之间调用【进程间调用】
答：
架构的改变一定会带来一些新的技术和新的问题
分布式事务、分布式锁、分布session问题、分布式日志管理。
问题1：服务越多服务和服务之间的调用会变得非常混乱。
问题2：服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现（因为无法确定访问量对应的服务的情况）
加入会议管理功能访问量小，但部署了100台服务器。支付管理功能访问量大，但只部署了20台服务器。
总结：分布式架构和传统架构的区别
分布式的项目粒度分的更加细、逐步适合于互联网公司规模人数开发，耦合度降低。
问题：Maven聚合项目是不是分布式项目？答案：不一定。
解释：将传统的项目以maven聚合方式分为3个项目：itmayiedu_web、itmayiedu_service、itmayiedu_dao。最终打成一个war包，区别在于打成的是jar包还是war包，如果打成单个则非分布式。否则打成多个，多个jvm相互通讯，因此就是分布式。
=========================================================================================================================================
SOA架构
SOA架构代表面向服务架构，它也是基于分布式架构演变来的，俗称服务化，可以理解为面向于业务逻辑开发层。把共同的业务代码进行抽取出来的，然后提供给其他接口进行调用。服务于服务之间采用RPC远程调用技术。它可以解决分布式之出现的混乱调用问题。
服务概念：将共同的业务逻辑进行拆分、拆分成独立一个项目进行部署，没有视图层。服务概念可以理解为接口。
服务治理中间件：基于访问压力实时管理集群容量，提高集群利用率，提高机器利用率的资源调度和治理中心。
SOA的通俗理解：
=========================================================================================================================================
微服务架构
微服务：单体应用拆分成多个互不相干的小应用，每个小应用称为微服务。
微服务架构产生的原因
首先微服务架构基于SOA架构演变来的。
SOA架构缺点：
1.依赖于中心化服务发现机制
2.因为SOA架构采用SOAP协议（Http+XML），因为XML传输协议比较占用宽带，整个XML报文中有非常大冗余数据，所以在微服务架构中以json轻量级方式代替xml报文传输。
3.服务管理非常混乱、缺少服务管理和治理设施不完善。
微服务架构模式
微服务架构基于SOA架构演变来的，比SOA架构上粒度上更精细。让更专业的人做更专业的事情，目的是为了提高效率。每个服务与服务之间互不影响，每个服务必须独立部署（独立数据库、独立redis等），微服务架构更加体现轻量级，采用restful风格提供API，也就是Http协议+JSON格式，更加轻巧，更加适合于互联网公司敏捷开发、快速迭代产品。
微服务架构和SOA架构的区别
1.微服务架构基于SOA架构演变来的，继承SOA架构的优点，在微服务架构中去除SOA架构中的ESB消息总线，采用http+json（restful）进行传输。
2.微服务架构比SOA架构粒度会更加精细，让更专业的人做更专业的事情，目的是为了提高效率。每个服务与服务间互不影响，在微服务架构中，每个服务必须独立部署，微服务架构更加轻巧、轻量级。
3.SOA架构中可能数据库存储会发生共享，微服务强调每个服务都是单独数据库，保证每个服务间不相互影响。
4.项目体现特征：微服务架构比SOA架构更加适合于互联网公司敏捷开发、快速迭代版本，因为粒度非常精细。