微服务学习笔记

Eureka

Ribbon负载均衡

用服务提供者的服务名称远程调用,而返回实际ip端口

Ribbon 负载均衡规则

• 规则接口是 IRule

• 默认实现是 ZoneAvoidanceRule ，根据 zone 选择服务列表，然后轮询（Zone 可以理解为 一个机房、一个机架等)

饥饿加载

• Ribbon 默认是采用懒加载，即第一次访问时才会去创建 LoadBalanceClient ，请求时间会很长。

• 而饥饿加载则会在项目启动时创建，降低第一次访问的耗时

Nacos

注册中心

隔离与服务分级存储

Nacos 环境隔离

1. 每个 namespace 都有唯一 id

2. 服务设置 namespace 时要写 id 而不是名称

3. 不同 namespace 下的服务互相不可见

   Nacos 中服务存储和数据存储的最外层都是一个名为 namespace 的东西，用来做最外层隔离

Nacos 服务分级存储模型

1. 一级是服务，例如 userservice

2. 二级是集群，例如杭州或上海

3. 三级是实例，例如杭州机房的某台部署了 userservice 的服务器

Nacos 与 Eureka 的区别

1. Nacos 支持服务端主动检测提供者状态：临时实例采用心跳模式，非临时实例（亲儿子）采用主动检测模式

2. 临时实例心跳不正常会被剔除，非临时实例则不会被剔除

3. Nacos 支持服务列表变更的消息推送模式，服务列表更新更及时，Eureka心跳检测时间间隔更长，更容易出问题

4. Nacos 集群默认采用 AP（可用性） 方式，当集群中存在非临时实例时，采用 CP（可靠性） 模式； Eureka 采用 AP 方式

配置管理

• bootstrap.yml优先级大于application.yml

配置自动刷新（热更新）

1. 在 @Value 注入的变量所在类上添加注解 @RefreshScope

2. 使用 @ConfigurationProperties 注解

多服务共享配置

1. [ 服务名 ]-[spring.profile.active].yaml：环境配置

2. [ 服务名 ].yaml：默认配置，多环境共享

• 提问

• 整体式架构有什么坏处？

  答：1.耦合度高，难以管理；2.修改的成本高，费时费力；3.开发和测试不灵活；4.使实施新概念变得困难

  gpt补充：技术选型的限制：由于整个应用程序都是使用相同的技术栈构建的，因此难以引入新的技术或更新现有技术

• 微服务架构是怎么解决这些“坏处”的？

  答：将应用程序拆分为小型服务，每个服务都有自己的代码库和数据库。1.这样可以降低耦合度，使得修改和维护变得更加容易。2.并且由于微服务是相互独立的，因此一个服务的故障不会影响整个系统的可用性，系统具有更高的容错性。3.可以更灵活地选择技术和工具

  微服务具有自主性和专用性，关于专用性，如果开发人员逐渐将更多代码增加到一项服务中并且这项服务变得复杂，那么可以将其拆分成多项更小的服务。

• 那同时，微服务架构带来了什么问题，对于微服务架构的（）特性，我们得解决哪些以前整体式架构不用考虑的问题？

  答：微服务架构中涉及多个服务、多个组件，并且每个微服务都有自己的数据存储，它们分布在不同的服务器甚至不同的数据中心中。因此，必须处理分布式系统的各种复杂性，也需要有效的监控和调试工具来跟踪整个系统的运行状态。 gpt: 微服务架构中的服务之间需要通过网络进行通信，可能会增加延迟和网络开销

  对于自主性： 各个组件之间的任何通信都是通过明确定义的 API 进行的，需要解决服务发现、服务注册、负载均衡、服务监控等问题，以确保每个服务能够自主地运行并与其他服务协作。

• 为了解决上面提到的问题，微服务带来的新的技术（中间件、组件）有哪些？

  答：服务注册与发现： ◦ Consul： 提供服务发现和服务健康检查功能，用于发现和管理微服务。 ◦ etcd： 分布式键值存储系统，也用于服务发现和配置管理。 2. 负载均衡： ◦ Nginx： 开源的反向代理服务器，用于负载均衡和请求转发。 ◦ HAProxy： 高性能的负载均衡器，支持TCP和HTTP应用层负载均衡。 3. 消息队列/事件总线： ◦ Kafka： 高吞吐量的分布式消息队列，用于实时数据流处理。 ◦ RabbitMQ： 开源的消息代理，用于支持异步消息传递和事件驱动架构。 4. API网关： ◦ Kong： 开源的API网关和微服务管理层，提供路由、认证、访问控制等功能。 ◦ Netflix Zuul： Netflix开源的API网关，可用于动态路由、负载均衡等。 5. 分布式追踪： ◦ Jaeger： 分布式追踪系统，用于跟踪和监控微服务架构中的请求路径和性能。 ◦ Zipkin： 分布式的实时追踪系统，用于跟踪请求的路径和性能指标。 6. 容器化和编排： ◦ Docker： 容器化平台，用于打包、发布和运行应用程序。 ◦ Kubernetes： 自动化容器编排工具，用于管理容器化应用程序的部署、扩展和运维。 7. 分布式数据库： ◦ Cassandra： 分布式NoSQL数据库，具有高可扩展性和高可用性。 ◦ MongoDB： 面向文档的NoSQL数据库，适用于处理大量数据和快速迭代。

• 尝试用venn图画出微服务架构和分布式架构的关系