软件技术架构演变历史

软件技术架构演变历史

参考链接:https://blog.csdn.net/Su_Levi_Wei/article/details/80629737

1、https://www.boxuegu.com/news/3098.html

2、https://www.zhihu.com/tardis/landing/m/360/art/136587858

3、https://www.zhihu.com/tardis/landing/m/360/art/136587858

4、分布式架构的由来与SOA_liangweibeijing的博客-CSDN博客_分布式架构与soa
一、传统架构(单体架构)
传统架构 – 软件架构 – 图一

传统架构 – 硬件架构 – 图二(仅供参考)

传统架构 – 企业组织架构 – 图三(仅供参考)

 

为什么早期架构这样设计?
       这个就要从历史上去说了,在计算机发展过程中,计算机慢慢的渗透进个人、企业等用户的场景中,但那时计算机价格昂贵,对使用者有一定的门槛要求。

        使计算机普及率并不高,而计算机更多的是用于打字、运算等操作,只在部分领域内普及,且受限于硬件技术(集成电路技术刚发展也没多少年)与软件技术(编程语言等)的局限,使当时的程序员可选择性的设计不多,局限性太多,也没有多少人料到计算机的发展的如此之快,即便料到,在当时的环境下(各种标准规范未同一,系统平台混乱等等…)考虑更多的是把程序制作出来,用户可以正常使用才是最重要。(不讨论从第一台电脑造到集成电路发展的历史,有兴趣自己去查资料。)

架构说明:
       全部功能集中在一个项目内。

架构优点:
       开发效率高、开发周期短。

架构缺点:
       技术栈受限,只能使用一种语言开发。

       导致不易于扩展,因每次一更改等需要重新更新/打包整个项目,导致维护困难。

二、垂直架构(分布式架构)
垂直架构 – 软件架构 – 图一

垂直架构 – 硬件架构 – 图二(仅供参考)

垂直架构 – 企业组织架构 – 图三(仅供参考)

为什么会出现垂直架构?
       随着互联网的发展,用户越来越多,软件技术也得到了很大的发展,人们开始研究一些技术使其与底层硬件交互会更加友好等。

        及某系统流量访问某模块占比很高,而其他模块没有什么流量访问,如果都部署到一起占用的资源就浪费了,如果分开部署,流量高的部署到一台高性能服务器,而流量低的部署到一台普通的服务器,两个模块之间的交互用WebService、RPC等方式进行访问。

       那样就可以解决上述传统架构的缺点问题


架构说明:
       按照业务进行切割,形成小的项目,项目直接通过RPC等方式通信,交换数据等。

架构优点:
       涵盖了传统架构的优点,另外项目不会无限扩大,技术栈可扩展(不同的系统用不同的编程语言编写)

架构缺点:
        功能集中在一个项目中,不利于开发、扩展、维护。

       系统扩张只能通过集群的方式。

       项目之间功能冗余、数据冗余、耦合性强。

三、面向服务架构(SOA)
服务架构 – 软件架构 – 图一

服务架构 – 硬件架构 – 图二(仅供参考)

服务架构 – 企业组织架构 – 图三(仅供参考)


为什么需要面向服务架构?
       在垂直架构中可以看到,物流系统有用户管理,CRM系统有用户管理,为什么还要重复去写?

       人总是聪明的,很快的把一些生活中的例子作为参考去做设计(生活中,人们需要实现某种需求时,通常是去看市场是否有这种工具在售,人们不会去关心这个东西是怎么做成的),把用户管理模块作为一个服务去对外提供,。

       用户管理模块作为一个服务提供出去,人们怎么去找到这个服务呢?各系统的用户信息结构可能不一样所接入的接口可能不一样?

       服务交互都要经过ESB(企业服务总线),ESB帮助你去寻找到你所需要的服务,且帮助你寻找到所需要的接口,可以理解为一个过滤和寻址的过程。

架构说明:
       将重复功能或模块抽取成组件的形式,对外提供服务,在项目与服务之间使用ESB(企业服务总线)的形式作为通信的桥梁,使用RPC等方式进行通信。

架构优点:
       重复功能或模块抽取为服务,提高开发效率、可重用性高、可维护性高。

       可以针对不同服务制定对应的技术方案。

       接口耦合度低

架构缺点:
各系统之间业务不同,因此很难确认功能或模块是重复的,不利于开发和维护

抽取服务的粒度大,系统和服务之间耦合度高

四、微服务架构
微服务架构 – 软件架构 – 图一

微服务架构 – 硬件架构 – 图二(仅供参考)

微服务架构 – 企业组织架构 – 图三(仅供参考)

有了SOA架构为什么会出现微服务架构?
       SOA架构有局限性,就是所有的接口都需要走ESB,如果不同的编程语言开发子系统,而这个编程语言对于某种RCP协议支持是最友好的,而ESB规则限定其只能使用ESB的规定协议。

       而这里的网关是用于数据过滤等业务场景。

        (开发效率提升,这些还是要看系统,这些就不谈了。)

架构说明:
       在服务治理架构上延伸,抽取的粒度更细,尽量遵循单一原则,采用轻量级框架协议传输。

架构优点:
       去中心化。

        粒度更细,有利于提高开发效率。

       可以针对不同服务制定对应的技术方案。

       去中心化的思想,不在使用ESB作为通信的桥梁,服务、系统之间可以相互访问。

       适用于产品迭代周期短

架构缺点:
       粒度太细导致服务太多,维护成本高。

       负载均衡、事务等问题对技术团队的挑战及成本问题。

补充
       其实观察一下,不止是企业、架构的发展是如此,计算机硬件也是如此,从一开始的运算器不断的发展到系统总线、寄存器、缓存、主存等,不断的越来越细粒度。
 

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值