服务架构演变

单体架构

单体架构：将业务的所有功能集中在一个项目中开发，打成一个包部署。

image.png

优点：

  • 架构简单
  • 部署成本低：单体架构打成一个包往tomcat一部署，用户就可以访问了，用户多了就可以再增加机器形成负载均衡集群

image.png
这样的架构比较适合于面向一些企业内部使用的一些简单项目，因为单体架构有一个严重的缺陷，那就是耦合度高。

所有代码写在一个项目里，如果大型的互联网项目：拼多多、淘宝，那这业务可就不是两三个模块了，往往就会有几十甚至上百的模块，代码量非常巨大。这个时候，这个代码光编译、打包可能就得花上十几分钟。

分布式架构

耦合度高其实是不利于大型项目开发的。那么大型项目一定会做分布式架构。

分布式架构：根据业务功能对系统进行拆分，每个业务模块作为独立项目开发，称为一个服务。

比如下面商城，它里边有四个业务模块，那我就会按照业务拆分拆成四个独立的项目。
image.pngimage.png
image.png

服务治理

因为做了服务的拆分，那么服务拆分的越多，将来部署各方面也会越复杂，而且在拆分的过程中也会有一些问题。服务拆分是一方面，将来拆分好的机器，你是不是为了保证高可用还要做集群？

将来一旦拆分就会产生一个新的问题：原来是单体项目的时候，各种服务可以相互调用service一起协作，然而做了服务拆分后就不行了。因为不同服务时部署在独立的机器上的。那么这时候就需要远程调用。
image.png

微服务

微服务是一种经过良好架构设计的分布式架构方案，微服务架构特征：
image.png、

微服务结构

image.png
不管是springCloud 还是阿里巴巴Dubbo，既然都是微服务方案的实现，所以他们所包含的组件实现的功能基本是一致的。首先他们都需要去做微服务的拆分、形成微服务集群，而集群中的每个服务都要遵循单一职责的原则，并且要面向服务、都要暴露接口，这样服务之间就可以做一些相互的调用了。只不过不同技术实现这些接口的时候可能会有差异。

不管是哪一种技术，服务之间的这种调用关系错综复杂，一定需要我们去维护，但是你靠人维护肯定不行，太复杂了。所以在微服务流都会有一个注册中心，它可以去维护微服务里面每个节点的信息，并且去监控这些节点的状态。

另外将来微服务越来越多，如果说将来有一些配置需要去做修改，我们手动的去微服务里改，这显然不现实。那因此在微服务里边往往还会有配置中心，可以统一的去管理整个微服务群的配置。如果将来有变更，我们也可以利用通知的方式去让对应的服务监控配置的变化，从而实现配置的热更新。

将来微服务一旦部署上线，用户是不是要访问？那如此之多的微服务用户，怎么知道该访问哪一个呢？所以微服务群往往还需要有一个统一的网关作为入口。那么用户可以去访问它，然后由网关再把请求路由到我们的微服务群。在路由的过程中，还可以去做负载均衡，并且路由的时候或者服务之间调用的过程中，我们还要做好服务的容错处理，避免因为服务故障带来级联失败，还要做好服务保护、隔离、降级等等这些措施。

微服务技术对比

image.png

企业需求

image.png

SpringClound

SpringCloud,是目前国内使用最广泛的微服务框架。官网地址：https://spring.io/projects/spring-cloud。

SpringCloud集成了各种微服务功能组件，并基于Spring Boot3实现了这些组件的自动装配，从而提供了良好的开箱即用体验：
image.png
image.png