软件技术架构演变历史

传统架构

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

传统架构 – 硬件架构 – 图二（仅供参考）

传统架构 – 企业组织架构 – 图三（仅供参考）

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

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

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

 

架构说明：

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

      

架构优点：

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

 

架构缺点：

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

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

 

垂直架构

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

 

垂直架构 – 硬件架构 – 图二（仅供参考）

 

垂直架构 – 企业组织架构 – 图三（仅供参考）

 

为什么会出现垂直架构？

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

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

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

架构说明：

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

      

架构优点：

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

 

架构缺点：

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

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

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

 

面向服务架构（SOA）

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

 

服务架构 – 硬件架构 – 图二（仅供参考）

 

 

服务架构 – 企业组织架构 – 图三（仅供参考）

 

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

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

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

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

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

 

架构说明：

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

      

架构优点：

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

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

       接口耦合度低

 

架构缺点：

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

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

 

 

微服务架构

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

微服务架构 – 硬件架构 – 图二（仅供参考）

 

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

 

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

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

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

        （开发效率提升，这些还是要看系统，这些就不谈了。）

架构说明：

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

      

架构优点：

       去中心化。

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

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

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

       适用于产品迭代周期短

 

架构缺点：

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

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

补充

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