微服务带来了什么，又带走了什么。

说起微服务，我只改造过一个springboot程序，然后扔给了公司微服务平台进行部署，除此之外对微服务没有太多的涉猎，因为我当年实习刚学完JVM，打算开始学习微服务的时候，我就成转行去了大数据。但是提到微服务开发，我会脱口而出Spring Cloud和dubbo。

微服务架构已经成为一种流行的设计模式。它将复杂的应用程序拆分成一系列小型、独立的服务，每个服务都专注于完成特定的业务功能。

我们在传统的开发中，我们通常会在一个web服务中实现所有的接口，不同的服务接口我们在不同的controller中定义，或者根据不同路径的rest api进行区分。这样的话，所有接口放在了一个web服务中，如果想要新增一个接口，就需要修改代码，然后再进行上线。

而微服务的出现，首先是可以将一个web服务根据不同的接口，拆分成一个个独立的web服务。但是这是问题就来了，如何去访问这些一个个web服务。我们在访问之前的web服务的时候，根据固定的端口 IP，加上不同接口路径就可以访问到服务。

但是一个端口只能监听一个服务，所以微服务中拆分的众多web服务就只能使用不同的端口，这样调用不同的接口就需要不同的端口，开发者就需要知道服务和端口之间的映射关系，这样无疑增加了开发难度，且不合理。所以，需要统一一个web访问的入口，这个入口就是网关（gateway）。

除了统一入口之外，gateway还具有以下作用：

请求路由和转发：根据指定的规则将请求路由到相应的微服务实例，实现微服务之间的通信
负载均衡：通过集成服务注册中心（如Eureka）实现微服务的负载均衡，根据负载均衡策略将请求分发到不同的微服务实例。‌
熔断和降级：支持熔断器模式，在微服务出现故障或超时时进行熔断，避免故障扩散。同时支持降级策略，当某个微服务出现故障时，通过返回默认值或其他备选方案提供优雅降级。
限流：通过配置限流规则，限制对某个微服务的并发请求量或请求数量，避免微服务被过载。
安全认证：可以集成‌Spring Security等框架，提供安全认证和权限控制的功能
请求过滤：对请求进行过滤，实现请求的验证、鉴权、加密、解密、压缩等功能。‌

说到负载均衡，我们在之前的web开发中通常将相同的程序部署在多个tomcat上，然后使用nginx进行配置进行反向代理，以此来实现负载均衡。

Nginx实现负载均衡的前提是：我们将所有的tomcat的ip和端口，写在了nginx的配置中，这样nginx才能知道web服务在哪里。那么，在微服务中，gateway想要知道服务在哪里，是如何实现的。

在Spring Cloud中，使用Eureka来实现服务发现。我们在部署一个微服务时，通过配置将我们的服务注册在Eureka的服务注册表中，这样Gateway就能知道我们的服务在哪里。

我们在web服务的application.yaml中配置Eureka的服务地址，这样当我们启动服务的时候，服务就会自动注册。

代码语言：yaml复制

eureka:
  client:
    register-with-eureka: true
    fetchRegistry: true
    service-url:
      defaultZone: http://localhost:9001/eureka

这样，web服务就被注册成功了。

从上面的描述来看，感觉微服务架构确实不错。但是在实际中，微服务架构也存在很多的缺点。还记得很多年前在学习微服务的时候，看到过一篇文章，大概是关于为什么很多手游不使用微服务架构的原因。

虽然微服务将服务拆分，但是各个服务之间想要通信必定依赖于网络，这意味着服务间的通信延迟和网络故障可能会对系统的性能和可靠性产生影响，尤其是对于对抗类手游这种对实时性要求极高服务。

同时，由于微服务架构中有多个独立的服务，部署和运维变得更加复杂。每个服务都需要独立部署和监控，而且服务之间的依赖关系需要管理。此外，对于故障排除和性能优化来说，跨多个服务的调试和监控也变得更加困难，可能导致开发团队需要更多的技术和管理能力来处理分布式系统的挑战。

这就是我从Spring Cloud的角度，对于微服务的认识。微服务确实带来的便利，但是也需要根据实际情况评估。

0 人点赞