架构演变过程

架构的发展演变

1.3.1 单一应用架构(ORM)

当网站流量很小的时候,只需要一个应用,将所有的功能部署在一起,以减少部署节点成本。缺点:单一的系统架构,使得开发过程中,占有的资源越来越多可靠性差随着流量的增加难以维护。
在这里插入图片描述

1.3.2 垂直应用架构(MVC)

解决了单一应用架构所面临的扩容问题(拆分互不相干的几个应用),流量能够分散到各个子系统中,且系统的体积可控,一定程度上降低了开发人员协同维护的成本,提升开发效率。缺点:相同逻辑的代码需要不断复制,不能复用,应用直接不能充分解耦。
在这里插入图片描述

1.3.3 分布式应用架构(RPC)

当垂直应用越来越多,应用之间的交互不可避免,将核心或重复业务抽取出来,作为独立的服务,逐渐形成稳定的共享服务中心。目的是为了系统解耦。
在这里插入图片描述

在这里插入图片描述

存在问题:如果服务提供方发生改变例如部署的机器由106->107,由于支付及订单缓存列表中用的还是106,需要将其修改为107,或者服务的上线及下线操作,手动配置比较麻烦。服务较多时,管理麻烦,服务治理,容错,发现,IP暴露等都是分布式架构遇到的问题。当服务越来越多、容量的评估、小服务资源的浪费等问题逐渐显现,此时增加一个调度中心基于访问压力实时管理集群容量,提供集群利用率。

1.3.4 流动计算架构(SOA)

SOA:面向服务的架构,是一种设计方法,其中包含了多个服务,服务之间通过相互依赖最终提供一系列功能。服务之间通过良好的接口和契约。

ESB:企业服务总线从SOA发展出来,类似服务中介的概念,主要提供一个服务之间的交互及治理,ESB包含功能:负载均衡,流量控制,加密处理,服务监控等等。

在这里插入图片描述

特点:

(1)基于SOA架构思想,将重复公用的功能抽取为组件,以服务的方式向各个系统提供服务

(2)系统与服务之间采用webservice,rpc方式进行通信

(3)ESB企业服务总线作为系统与服务之间的桥梁

优点:

(1)系统与服务之间不直接交互,提高系统的开发效率

(2)可以针对不同的服务的特点进行按需伸缩

(3)ESB可以降低系统之间的耦合度

缺点:

(1)使用了ESB,但是服务之间的协议不固定,种类繁多,不利于系统维护

1.3.5 微服务架构

微服务是基于SOA架构演变出来的,在微服务架构中去除了SOA的架构中ESB消息总线,使用注册中心替代ESB,注册中心相对于ESB更加轻量级,微服务代表技术SpringCloud和Dubbo。

微服务是一种架构风格,一个大型的软件应用,有一个或多个微服务组成,各个服务可以独立部署,各个服务是松耦合的。每个服务专注于一项任务并且很好的完成一项任务。

在这里插入图片描述

特点:

服务内部是高内聚,外部是松耦合,高内聚是每个服务只关注一个功能,松耦合是指服务之间没有直接关联。

微服务强调每个服务都是单独数据库,保证每个服务之间不相互影响,选择不同技术平台,去中心化,发挥各种技术平台的特长。

微服务使用Rest API交互,可以自由选择开发技术,更加灵活。

微服务架构 比SOA架构更适合敏捷开发,产品快速迭代。

重点:将业务彻底的组件化和服务化,原有的单个业务系统拆分成多个可以独立开发、设计、运行的小应用,这些小应用通过服务完成交互或集成。

缺点:

运维成本变高,部署模块成倍增加;

分布式系统的更加复杂,通讯成本增加;

分布式系统引出分布式事务的出现有很多解决方案(各有优缺,按照实际的业务选择);

考虑网络不可靠问题,考虑补偿(Batch或Mq)

功能SOA微服务
组件大小大块业务逻辑单独任务或小块业务逻辑
耦合通常松耦合总是松耦合
公司架构任何类型小型、专注于功能交叉团队
管理着重中央管理着重分散管理
目标确保应用能够交互操作执行新功能、快速拓展开发团队

总结

当然架构是一步一步演变过来的,流量小时,直接放在一个war中开发,所有功能都集成在一起,所以比较重,不能按照业务进行垂直拆分,但是可以通过使用集群方式扩大一部分流量,但是对系统资源浪费比较验证,例如支付系统流量增减,不能只增加支付系统,后续发展成MVC架构,解决的了开发人员协同开发问题,但是一部分核心重复的功能代码需要在多个War包中不断复制,为了系统解耦,将这些重复的功能抽取成服务,后续来到了分布式架构,分布式架构又给运维管理带了一定的压力,故后续又了微服务架构,注册中心自动发现服务,以前的系统都抽取成了服务,前端可任意扩展,例如pc端,APP端,公众号,后台共用的服务时不变的,而且可以横向扩招,和其他不同业务服务接口,如果需要公共的服务通过RPC或HTTP请求来请求,Dubbo和SpringCloud是实现微服务的两种框架,路易斯.詹姆斯微服务论文中并没有说微服务用什么语言来实现,故微服务和语言没有半毛钱关系,微服务是一种架构风格,指明了其中的通信方式是RestFull风格,不同的业务可以使用各种语言来实现,例如支付系统使用java,大数据系统使用python,当然中间件也可以按照各种中间件的优势及业务场景进行随意组合,当然Dubbo之间的通信使用Netty(NIO)底层使用TCP,Dubbo性能相对于SpingCloud的通讯性能要高,但是(2.7之前)不适合异构系统(跨语言)。但是后续2.7之后支持了rest风格,也可使用在异构系统。当然架构没有好坏只有适合不适合公司的发展,适合公司的架构才是最好的系统

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值