软件技术架构演变历史

时间:2021-12-17 20:40:56

传统架构

传统架构 – 软件架构 – 图一

软件技术架构演变历史


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

软件技术架构演变历史


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

软件技术架构演变历史


为什么早期架构这样设计?

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

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

 

架构说明:

       全部功能集中在一个项目内。

      

架构优点:

       开发效率高、开发周期短。

 

架构缺点:

       技术栈受限,只能使用一种语言开发。

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

 

垂直架构

垂直架构 – 软件架构 – 图一

软件技术架构演变历史

 

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

 软件技术架构演变历史


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

软件技术架构演变历史

 

为什么会出现垂直架构?

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

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

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


架构说明:

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

      

架构优点:

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

 

架构缺点:

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

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

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

 

面向服务架构(SOA)

服务架构 – 软件架构 – 图一

软件技术架构演变历史


 

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

 软件技术架构演变历史

 

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

 软件技术架构演变历史


为什么需要面向服务架构?

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

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

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

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

 

架构说明:

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

      

架构优点:

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

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

       接口耦合度低

 

架构缺点:

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

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

 

 

微服务架构

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

软件技术架构演变历史


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

软件技术架构演变历史

 

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

软件技术架构演变历史

 

有了SOA架构为什么会出现微服务架构?

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

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

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


架构说明:

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

      

架构优点:

       去中心化。

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

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

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

       适用于产品迭代周期短

 

架构缺点:

       粒度太细导致服务太多,维护成本高。

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


补充

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