系统架构演变

系统架构演变

一、集中式架构

优点:

1、系统开发速度快

2、维护成本低

3、适用于开发要求较低的系统

缺点:

1、代码耦合度高,后期维护困难

2、无法这针对不同模块进行针对性优化

3、无法水平扩展

4、单点容错率低,并发能力差

二、垂直拆分架构

 优点:

1、系统拆分实现了流量分担,解决了并发的问题

2、可以针对不同的模块进行优化

3、方便水平扩展,负载均衡,容错率提高

缺点:

1、系统间相互独立,会有很多重复开发,影响开发效率

三、分布式服务架构

 优点:将基础的服务进行抽取,系统间相互调用。提高了代码复用和开发效率

缺点:系统间的耦合度变高,调用关系错综复杂,难以维护

四、面向服务架构(SOA)

SOA(service oriented architecture)面向服务架构,它是一种设计模式,其中包含多个服务,服务之间通过互相依赖最终提供一系列的服务功能,一个服务通常以独立的形式存在,各个服务之间通过网络调用。

SOA 使用了ESB ,ESB:简单来说就是一根管道,用来连接各个服务节点,为了集成不同系统,不同协议的服务,ESB做了消息的转化解释和路由工作,让不同的服务互联互通。

缺点:应用服务力度较大,每个产品提供的ESB产品有偏差,自身实现较为复杂;ESB集成了整合所有服务和协议,数据转换使得运维,测试部署困难,所有服务都通过一个通路通信。直接降低了耦合度。

五、微服务架构

 微服务架构是使用了一套小服务来开发单个应用的方式或途径,每个服务基于单一业务能力构建,运行在自己的进程中,并使用轻量级机制通信,通常是Http Api 并能够通过自动化部署机制独立部署,这些服务可以使用不同的编程语言实现,以及不同的数据存储技术,保持最低限度的集中式管理。

Api Gateway网关是一个服务器,是系统的唯一入口,为每个客户端提供一个定制的api,api网关核心是所有的客户端和消费端都通过统一的网关接入微服务,在网关层处理的所有非业务功能。还可有其他职责。比如:身份验证、监控、负载均衡、缓存、请求分片与管理、静态响应处理。通常网关提供RESTFUL/HTTP的方式访问服务,而服务端通过注册中心进行服务注册和管理

特点:微服务中每一个服务对应唯一的业务能力。

2、微:差分力度很小,但“五脏俱全”。

3、面向服务:每个服务都要对外暴露rest风格的api接口。并不关心服务的技术实现。做到了与平台,语言无关。

4、相互独立:

  • 团队独立:每个服务有独立的开发团队。
  • 技术独立:面向服务,提供rest接口。
  • 前后端分离:采用前后端分离开发,提供统一的rest接口。后端不在为pc,移动端开发不同的接口。
  • 数据库分离:每个服务有自己独立的数据源。
  • 部署独立:服务间有调用,但做到服务重启不影响其他的服务,有利于持续集成和持续交付。每个服务都是独立的组件,可复用,可替换,降低耦合,易维护。

服务的调用方式:rpc 或 http

rpc:基于socket,工作在会话层,自定义数据格式。速度快,效率高。代表:webservice、dubbo

http:是一种网络传输协议,基于tcp,工作在应用层,规定了数据传输的格式,现在客户端浏览器与服务之间的通信基本采用http。缺点:消息封装臃肿。优点:对服务提供和调用方没有任何技术限定,自由灵活,更服务微服务理念。

目前热门的rest风格,就可以通过http协议实现。代表:spring cloud

原文地址:https://www.cnblogs.com/lxn0216/p/14061765.html