系统架构演变

系统架构演变

一、集中式架构

 

 

优点：

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