传统架构(单点应用)-->分布式架构(以项目进行拆分)-->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架构更加适合于互联网公司敏捷开发、快速迭代版本,因为粒度非常精细。