应用架构的演变
由于互联网的发展,带动着并发的激增,我们的应用架构也随之进行了升级,这里主要讲几个主要架构类型
通常我们的单体架构都是在一个应用,就是一个服务器(tomcat)上开发部署的,通常有三个组成部分:持久层,业务层,表现层,这种架构模式业务少很方便,但是并发高就负荷很大了
当然单体应用在项目初期也有很多优势,主要有如下表现
☆ 易于开发 :架构简单,技术成本低
☆ 易于测试 :所有功能在一个项目,方便测试
☆ 易于部署 :一个Tomcat就可以实现部署,简单方便
随着项目规模日益变大,我们可以采用集群的手段来出来解决高并发,但包含了所有组成部分的单体应用终归是有许多不足,主要缺点如下
☆代码臃肿不方便开发维护(代码可读性差)
☆代码编译系统启动变慢
☆ 系统扩展性能变差(牵一发而动全身)
☆ 无法针对某一个业务做扩展(集群)
☆ 对大数据量,高并发量的处理不占优势
☆ 技术选型单一
☆ 模块/业务耦合度高
为了防止我们应用工作是出现了单点故障(一个服务器挂了),我们就会对此应用做集群:就是用另一个服务器做相同的任务,如图
但是这种模式会有一个客户端不知道访问哪一个应用的问题,所以就出现了一个可以分发请求的功能组件:负载均衡器,将客户端的请求相对平均的分发多个应用节点上,如图
负载均衡也有自己内置的几种算法(Nginx)
☆轮询(round robin) : 依次将请求分配到各个后台服务器中,默认的负载均衡方式
☆权重(weight) : 根据权重值将请求分配到后台服务器中,权重值越大,分配比例越高
☆IP_HASH:按照ip地址进行hash运算,同一ip的请求会被分配到相同的机器上
☆url_hash : 根据请求的url的hash值将请求分到不同的机器中。
☆fair:根据服务器响应时间来分发请求,时间越短分发的请求越多
微服务架构就是基于分布式架构而来,微服务就是把单一应用进行细粒度的拆分成多个小的服务项,每个服务独立运行,每个服务只需要专注一个业务即可,并且每个服务都可以有自己的数据库(分库),服务之间互协调配合完成整个系统的业务,如图
☆ 由多个服务组成完整的系统
☆ 每个服务都是独立的,有自己的进程
☆ 服务之间使用HTTP协议通信
☆ 不同的服务可以使用不同的编程语言
☆ 不同的服务的数据库可以多样化选择
☆ 微服务是一个分布式系统
在项目规模较大的时候,相对于单体应用来说,微服务具备很多优势,主要体现在如下方面:
☆单个服务业务简单,代码简单方便开发维护
☆服务之间无耦合,服务之间升级维护互不影响
☆轻量级HTTP通信机制,使得的不同的服务可以采用不同的编程语言
☆微服务有极强的扩展能力,业务量大的服务可以再次拆分服务,也可以进行集群部署,剔除服务也很方便
☆更大的系统负载能力和容错能力(集群)
☆对于开发人员来说,通常只需要关注单一服务,新员工上手也比较快
☆微服务架构对现在流行的敏捷开发支持优化
凡是都有双面性,微服务展示出了他都优势之处,同时也有其不足的地方,主要体现如下方面:
☆分布式事务 :服务通信机制增加了事务的复杂性,架构师要选择合适的分布式方案(CAP理论)
☆部署麻烦 :微服务众多,部署麻烦,需要借助容器技术和自动化部署工具,这又增加了开发人员的学习成本。
☆技术成本高 :微服务架构本身比较复杂,技术成本高,开发人员需要花更多的时间学习相关技术。
☆服务通信对性能的损耗 : 微服务架构一定要考虑服务通信延迟对服务调用性能的损耗问题,开发人员需要选择合适的通信方式解决这一问题。