系统架构演变
随着互联网的发展,网站应用的规模也在不断的扩大,进而导致系统架构也在不断的进行变化。
从互联网早起到现在,系统架构大体经历了下面几个过程: 单体应用架构--->垂直应用架构--->分布
式架构--->SOA架构--->微服务架构,当然还有悄然兴起的Service Mesh(服务网格化)。
接下来我们就来了解一下每种系统架构是什么样子的, 以及各有什么优缺点。
单体应用架构
互联网早期,一般的网站应用流量较小,只需一个应用,将所有功能代码都部署在一起就可以,这样可以减少开发、部署和维护的成本。比如说一个电商系统,里面会包含很多用户管理,商品管理,订单管理,物流管理等等很多模块,我们会把它们做成一个web项目,然后部署到一台tomcat服务器上。
优点:
- 项目架构简单,小型项目的话, 开发成本低
- 项目部署在一个节点上, 维护方便
缺点:
- 全部功能集成在一个工程中,对于大型项目来讲不易开发和维护
- 项目模块之间紧密耦合,单点容错率低
- 无法针对不同模块进行针对性优化和水平扩展
垂直应用架构
随着访问量的逐渐增大,单一应用只能依靠增加节点来应对,但是这时候会发现并不是所有的模块都会有比较大的访问量.还是以上面的电商为例子, 用户访问量的增加可能影响的只是用户和订单模块, 但是对消息模块的影响就比较小. 那么此时我们希望只多增加几个订单模块, 而不增加消息模块. 此时单体应用就做不到了, 垂直应用就应运而生了.所谓的垂直应用架构,就是将原来的一个应用拆成互不相干的几个应用,以提升效率。比如我们可以将上面电商的单体应用拆分成:
- 电商系统(用户管理 商品管理 订单管理)
- 后台系统(用户管理 订单管理 客户管理)
- CMS系统(广告管理 营销管理)
这样拆分完毕之后,一旦用户访问量变大,只需要增加电商系统的节点就可以了,而无需增加后台和CMS的节点。
优点:
- 系统拆分实现了流量分担,解决了并发问题,而且可以针对不同模块进行优化和水平扩展
- 一个系统的问题不会影响到其他系统,提高容错率
缺点:
- 系统之间相互独立, 无法进行相互调用
- 系统之间相互独立, 会有重复的开发任务
SOA架构
在分布式架构下,当服务越来越多,容量的评估,小服务资源的浪费等问题逐渐显现,此时需增加 一个调度中心对集群进行实时管理。此时,用于资源调度和治理中心(SOA Service Oriented Architecture,面向服务的架构)是关键
SOA是一种粗粒度、松耦合服务架构,服务之间通过简单、精确定义接口进行通讯,不涉及底层编程接口和通讯模型。特点:
- 基于SOA的架构思想将重复公用的功能抽取为组件,以服务的方式提供给各个系统
- 各个项目(系统)与服务之间采用webservice、rpc等方式进行通信。
- ESB企业服务总线作为项目与服务之间通信的桥梁。
这样拆分完毕之后,一旦用户访问量变大,只需要增加电商系统的节点就可以了,而无需增加后台和CMS的节点。
优点:
- 将重复的功能抽取为服务,提高开发效率,提高系统的可重用性、可维护性。
- 可以针对不同服务的特点制定集群及优化方案。
- 采用ESB减少系统中的接口耦合。
缺点:
- 系统与服务的界限模糊,不利于开发及维护。
- 虽然使用了ESB,但是服务的接口协议不固定,种类繁多,不利于系统维护。
- 抽取的服务的粒度过大,系统与服务之间耦合性高。
微服务架构
特点:
- 面向服务:将系统服务层完全独立出来,并将服务层抽取为一个一个的微服务。
- 职责单一:微服务遵循单一原则。
- 微服务之间采用RESIful等轻量协议传输。
优点:
- 服务拆分粒度更细,有利于资源重复利用,提高开发效率。
- 可以更加精准的制定每个服务的优化方案,提高系统可维护性。
- 微服务架构采用去中心化思想,服务之间采用RESTful,等轻量协议通信,相比ESB更轻量。
- 适用于互联网时代,产品迭代周期更短。
缺点:
- 微服务过多,服务治理成本高,不利于系统维护。
- 分布式系统开发的技术成本高(容错、分布式事务等),对团队挑战大。