33 | 传统的可扩展架构模式:分层架构和SOA
李运华

相比于高性能、高可用架构模式在最近几十年的迅猛发展来说,可扩展架构模式的发展可以说是步履蹒跚,最近几年火热的微服务模式算是可扩展模式发展历史中为数不多的亮点,但这也导致了现在谈可扩展的时候必谈微服务,甚至微服务架构都成了架构设计的银弹,高性能也用微服务、高可用也用微服务,很多时候这样的架构设计看起来高大上,实际上是大炮打蚊子,违背了架构设计的“合适原则”和“简单原则”。
为了帮助你在实践中更好的进行可扩展架构设计,我将分别介绍几种可扩展架构模式,指出每种架构模式的关键点和优缺点。今天我来介绍传统的可扩展模式,包括分层架构和 SOA,后面还会介绍微服务架构。
分层架构
分层架构是很常见的架构模式,它也叫 N 层架构,通常情况下,N 至少是 2 层。例如,C/S 架构、B/S 架构。常见的是 3 层架构(例如,MVC、MVP 架构)、4 层架构,5 层架构的比较少见,一般是比较复杂的系统才会达到或者超过 5 层,比如操作系统内核架构。
按照分层架构进行设计时,根据不同的划分维度和对象,可以得到多种不同的分层架构。
C/S 架构、B/S 架构
划分的对象是整个业务系统,划分的维度是用户交互,即将和用户交互的部分独立为一层,支撑用户交互的后台作为另外一层。例如,下面是 C/S 架构结构图。
公开
同步至部落
取消
完成
0/2000
笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《从 0 开始学架构》,新⼈⾸单¥68
《从 0 开始学架构》,新⼈⾸单¥68
立即购买
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(65)
- 最新
- 精选
- LeeSOA是把多个系统整合,而微服务是把单个系统拆开来,方向正好相反
作者回复: 言简意赅👍
5222 - 辉辉soa是集成的思想,是解决服务孤岛打通链条,是无奈之举。esb集中化的管理带来了性能不佳,厚重等问题。也无法快速扩展。不适合互联网的业务特点
作者回复: 赞同👍
81 - 铃兰Neko尝试说下个人浅见: 为什么互联网不用SOA? 1. 互联网企业, 通常比较年轻, 没有那么多异构系统, 技术是公司的关键; 如果有整合或者服务化的需求, 公司有人也有钱专门搞这个; 拆到重做/重构 很平常; 相反的, 传统企业, 举个例子: 某传统炼钢国企 : 有多个遗留.net系统,有几个实习生做的java系统, 有基于数据库procedure的系统; 有各种已经倒闭了的第三方企业的系统 等等; 企业领导不会有精力和想法全部推倒重来, 只会花钱请第三方 , 成本越低越好; 这个时候就需要ESB这种总线 2. 传统企业IT追求的是"需求灵活,变更快", 而互联网企业追求性能, 传统soa 性能不佳 传统的esb ,说实话, 使用webservice 以及soap这种基于xml的技术; wsdl 这东西是真的难用, 难学难用难维护 ; 结构冗杂; 3. soa 这个东西很多时候只是一个概念, 而不是实践 个人觉得, 现在的微服务 , 更像是 soa 思想的一个落地 (相比esb)
作者回复: 分析的很好,微服务和SOA的关系后面会讲
250 - xxx一直不明白SOA和微服务的具体区别,知道作者讲到了ESB 的功能,原来就是适配各种协议,顿时明白了!SOA是为了适配老系统。
作者回复: 是的,所以SOA不适合创新型的互联网企业,比较适合传统大企业
20 - 赤脚小子回答问题:文中也说了,soa是特定历史条件下的产物,为了适配各种异构的it系统,而有如此多系统的自然是变化减少且稳定的传统企业。互联网企业的特点就是小,新,快。没有历史包袱,变化快,大部分是从单体演进到分布式,技术栈一脉相承或者在分布式之前已经从php,ruby等改造到java等了。而到了分布式之后,面对不断的耦合,系统复杂度的陡增,这时一个soa的特例微服务出现了。 实际上soa的思想还在,只不过实现的方式不一样了。
作者回复: 关于soa和微服务的关系,我会特别讲述
17 - 孙振超在传统企业从原先的手工作业转为采用IT系统作业的过程中,大多是采用向外采购的方式逐步实现的,在这个过程中不同部门采购系统的实现语言、通信协议并不完全相同,但为提升运行效率又要能够做到企业内部信息互通、相互协作,这是soa诞生的背景。 而互联网企业是新创的企业,没有这么多的历史包袱,同时出于快速迭代的要求,有时会自建所需的系统,即使是对外采购,也会选择和已有系统对接方便的系统,从根本上避免了相关问题,因而soa在互联网公司中使用不多。
作者回复: 赞同👍
12 - hellosoa解决的是资源的重复利用,它的拆分粒度比较大,比如财务系统跟oa系统的员工模块。1.互联网企业有几种情况,1.初创公司,这种公司一般会有试错的过程,需要技术快速实现业务落地,这种情况下使用SOA不适合快速敏捷迭代开发。2.对于成熟的互联网业务来说,需要解决的是是高并发,高性能和高存储等一系列问题,对于这类企业来说,使用SOA拆分不能解决太多问题,还得做更加细粒度的拆分。
作者回复: 分析到位👍
12 - 7侠SOA更像一种架构理念,不够具体。在传统企业的IT系统中落地为ESB,主要是为了集成异构系统。因为传统企业特别是大型企业的历史长,在其发展过程中自己开发或采购了不少异构系统。 而互联网企业历史都短(腾讯98年,阿里99年,百度2000年),很少有遗留异构系统(像阿里的系统绝大部分应该都是Java开发的吧?)。像阿里这种互联网大型企业的痛点是随着业务越来越多,整个系统成了个巨无霸(可能是数以千记的模块数),模块之间的调用像蜘蛛网,极大降低了开发、测试、部署、运维的效率,所以把庞大的业务逻辑层又切分成了业务更独立的应用层和公共功能模块组成服务层。接下来一是要提供应用层与服务层之间、服务层内部服务之间的高效通信机制,二是要对大量的服务进行治理,于是分布式服务框架出现了(阿里就出了Dubbo和HSF两个服务框架?)。感觉在大型互联网企业,SOA实际是落地为分布式服务框架,它更像是微服务架构的一个雏形,服务框架提供的功能实际也是微服务架构里必不可少的功能。
作者回复: 确实也有人将SOA理解为一个思想,微服务理解为SOA的具体实现
8 - 何磊soa主要是为了解决历史遗留问题,引入的esb。而互联网企业都年轻,没有历史包袱,另外互联网企业大部分都需要高性能,而esb可能成为瓶颈。 最后想咨询老师一个问题:在分层结构中。同层能不能互相调用?比如:下单时,需要用户信息,此时应该调用同层用户模块来完成,还是如何处理呢?
作者回复: 当然可以互相调用,特别是业务逻辑,如果说同层不能互相调用,这代码没法写
5 - yason li其实,个人理解的传统SOA和ESB在互联网企业之所以不怎么使用主要原因就是中心化的ESB架构会逐渐成为性能、可用性、可扩展性的瓶颈。但是SOA的思想本身是没有什么问题的。互联网企业中用的微服务甚至最近很火的Service Mesh都可以看成是SOA、ESB的变形。比如Service Mesh也可以看成是一个去中心化的ESB。
作者回复: 这也是一种理解方式吧,微服务基础设施做完,确实感觉是做了一个ESB
5
收起评论