垂直架构
随着互联网的发展,用户越来越多,软件技术也得到了很大的发展,人们开始研究一些技术使其与底层硬件交互会更加友好等。
及某系统流量访问某模块占比很高,而其他模块没有什么流量访问,如果都部署到一起占用资源就浪费了,如果分开部署,流量高的部署到一台高性能服务器,而流量低的部署到一台普通的服务器,两个模块之间的交互用webService,RPC等方式进行访问
架构说明:按照业务进行切割,形成小的项目,项目直接通过rpc等方式通信,交换数据等。
架构优点:涵盖了传统架构的优点,另外项目不会无限扩大,技术栈可扩展(不同的系统用不同的编程语言编写)。
架构缺点:1.功能集中在一个项目,不利于开发,扩展,维护。
2.系统扩展只能通过集群的方式。
3.项目之间功能冗余,数据冗余,耦合性强。
面向服务架构
在垂直架构中可以看到,物流系统有用户管理,CRM系统有用户管理,为什么还要重复去写?
人总是聪明的,很快的把一些生活中的例子作为参考去做设计(生活中,人们需要实现某种需求时,通常是去看市场是否有这种工具在售,人们不会去关心这个东西是怎么做成的),把用户管理模块作为一个服务去对外提供。
用户管理模块作为一个服务提供出去,人们怎么去找到这个服务?各系统的用户信息结构可能不一样所接入的接口可能不一样?
交互要经过ESB(企业服务总线),ESB帮助你去找到你所需要的服务,且帮助你寻找到所需要的接口,可以理解为一个过滤和寻址的过程。
架构说明:将重复功能或模块抽取成组件的形式,对外提供服务,在项目与服务之间使用ESB的形式作为通信的桥梁,使用RPC等方式进行通信。
架构优点:1.重复功能或模块抽取为服务,提高开发效率,可重用性高,可维护性高
2.可以针对不同服务制定对应的技术方案
3.接口耦合低
架构缺点:各系统之间业务不同,因此很难确认功能或模块是重复的,不利于开发和维护抽取服务的粒度大,系统和服务之间耦合度高
微服务架构
SOA架构有局限性,就是所有的接口都需要走ESB,如果不同的编程语言开发子系统,而这个编程语言对于某种RCP协议支持是最友好的,而ESB规则限定只能使用ESB规定协议。而这里的网关是用于数据过滤等业务场景。