分布式基本架构！

面向服务架构(SOA)

基于分布式架构模式演变而来，俗称服务化，也就是面向接口开发(服务开发)。

将共同存在的业务逻辑抽取成一个共同的服务，提供给其他的服务接口实现调用。

  • 服务与服务之间通讯采用RPC远程调用技术，可以解决代码冗余性问题。

采用SOAP协议实现传输。

  • 在高并发情况下会存在大量的冗余性传输，非常占用带宽，所以微服务框架用JSON替代了XML。

实现方案为WebService或者是ESB企业服务总线，底层通讯协议SOAP协议（HTTP+XML）实现传输。

  • 采用SOAP协议实现通讯，XML传输非常重，效率比较低，而且很占带宽。

微服务架构

微服务架构基于SOA架构演变过来的。

比SOA架构模式对服务拆分粒度更加精细，采用前后端分离的架构模式。

  • 让专业的人去做专业的事，目的可以实现高效率的开发。

微服务架构中，每个服务都是独立部署、独立运营，之间互不影响。

服务与服务之间通讯的协议采用Restful形式，数据交换格式采用HTTP+JSON格式实现传输。

  • 整个传输过程中，采用二进制，可以实现跨语言。

SOA架构中可能数据库存储会发生共享，微服务强调独每个服务都是单独数据库，保证每个服务于服务之间互不影响。

Serverless

基于 Serverless 开发者就只需要关心业务逻辑的开发。

进行应用部署时也不再需要关心服务器，不需要关心后续的运维，应用也天然具备了弹性伸缩的能力。

  • 并且实现了按需使用，按量付费，也更能进一步节省成本。

Sidecar设计模式

Sidecar，也就是边车模式，是一种分布式服务架构的设计模式。

边车模式中的边车，实际上就是一个 Agent，微服务的通信可以通过 Agent 代理完成。

在部署时，需要同时启动 Agent，Agent 会处理服务注册、服务发现、日志和服务监控等逻辑。

  • 这样在开发时，就可以忽略这些和对外业务逻辑本身没有关联的功能，实现更好的内聚和解耦。

ServiceMeh服务网格

Service Mesh 基于边车模式演进，通过在系统中添加边车代理，也就是 Sidecar Proxy 实现。

Service Mesh 服务网格抽象出专门的一层，提供服务治理领域所需的服务注册发现、负载均衡、熔断降级、监控等功能。

  • Service Mesh统一管理微服务与上层通信的部分，接管各种网络通信、访问控制等。

我们的业务代码只需要关心业务逻辑就可以，简化开发工作。

image-20231012113713037

Service Mesh 和 API 网关的区别：

部署方式不同，在整体系统架构中的位置不一样。

API 网关通常是独立部署，通过单独的系统提供服务，为了实现高可用，还会通过网关集群等来管理。

而服务网格通常是集成在应用容器内的，服务网格离应用本身更近。

Service Mesh 解决方案：

目前两款流行的 Service Mesh 开源软件分别是 Istio 和 Linker。