wordpress head文件夹seo关键词查询
1.微服务的拆分原则/怎么样才算一个有效拆分
- 单一职责原则：每个微服务应该具有单一的责任。这意味着每个服务只关注于完成一项功能，并且该功能应该是独立且完整的。
- 最小化通信：尽量减少服务之间的通信，服务间通信越少，系统越简单。
- 可独立部署：服务应该可以独立部署，不应该依赖于其他服务。
- 数据一致性：在设计服务时，要考虑好数据一致性的问题，避免因为服务拆分而带来的一致性挑战。
- 性能考量：在拆分服务时，要考虑到性能的影响，避免不必要的服务拆分导致性能下降。
2.微服务的拆分方式
一般有两种方式：
1.纵向拆分 (垂直拆分)
所谓纵向拆分，就是按照项目的功能模块来拆分。例如商城项目中，就有用户管理功能、订单管理功能、购物车功能、商品管理功能、支付功能等。那么按照功能模块将他们拆分为一个个服务，就属于纵向拆分。这种拆分模式可以尽可能提高服务的内聚性。
2.横向拆分 (水平拆分)
而横向拆分，是看各个功能模块之间有没有公共的业务部分，如果有将其抽取出来作为通用服务。例如用户登录是需要发送消息通知，记录风控数据，下单时也要发送短信，记录风控数据。因此消息发送、风控数据记录就是通用的业务功能，因此可以将他们分别抽取为公共服务：消息中心服务、风控管理服务。这样可以提高业务的复用性，避免重复开发。同时通用业务一般接口稳定性较强，也不会使服务之间过分耦合。（类似于AOP思想）
3.微服务中常用组件
| 组件名称 | 功能概述 | 常用技术栈 |
|---|---|---|
| 服务发现(Service Discovery) | 自动注册和发现微服务实例，支持动态扩展 | Nacos、Consul、Zookeeper |
| API网关(API Gateway) | 统一流量入口，提供路由、限流、认证、监控等功能 | Gateway、Nginx |
| 配置中心(Configuration Management) | 管理分布式配置，支持动态更新与多环境管理 | Spring Cloud Config、Nacos |
| 负载均衡(Load Balancing) | 均衡分发流量，提高系统响应速度 | Ribbon、Nginx |
| 服务调用(Service Invocation) | 微服务间的通信机制，支持同步与异步调用 | Feign、RestTemplate、gRPC |
| 服务熔断(Circuit Breaker) | 保护系统免受故障蔓延，提升容错能力 | Hystrix、Resilience4j、Sentinel |
| 消息队列(Message Queue) | 实现服务的异步通信，解耦系统，提高可扩展性 | Kafka、RabbitMQ、RocketMQ |
| 服务安全(Service Security) | 实现微服务的认证、授权和数据保护 | OAuth2、JWT、Spring Security |
| 分布式事务(Distributed Transaction) | 保证跨服务的事务一致性 | Seata、TCC、Saga |
我自己项目中用到的：
1.注册中心/配置中心：Nacos 2.网关：Gateway、Nginx
3.负载均衡：Ribbon、Nginx 4.服务调用：Feign 5.服务保护：Sentinel
6.消息队列：RabbitMQ、Kafka 7.分布式事务：Seata
4.服务注册和发现是什么意思？如何实现服务注册和发现？
以Nacos为例(Eureka基本一样)
- 服务注册：服务提供者需要把自己的信息注册到nacos，由nacos来保存这些信息，比如服务名称、ip、端口等等。
- 服务发现：消费者向nacos拉取服务列表信息，如果服务提供者有集群，则消费者会利用负载均衡算法，选择一个发起调用
- 服务监控：服务提供者会每隔5秒(默认)向nacos发送心跳，报告健康状态，如果nacos服务15秒(默认)没接收到心跳，从nacos中剔除
追问：nacos和eureka的区别
①Nacos支持服务端主动检测提供者状态：临时实例采用心跳模式(服务向Nacos发送心跳检测)，非临时实例(可以设置)采用主动检测模式(Nacos主动检测非临时实例)
②临时实例心跳不正常会被剔除，非临时实例则不会被剔除
③Nacos支持服务列表变更的消息推送模式，服务列表更新更及时
④Nacos集群默认采用AP方式(高可用)，当集群中存在非临时实例时，采用CP模式(强一致)；Eureka采用AP方式
补：以上是作为注册中心二者的不同点。Nacos还可以作为配置中心！
5.Ribbon实现负载均衡
在服务调用过程中的负载均衡一般使用SpringCloud的Ribbon 组件实现 , Feign的底层已经自动集成了Ribbon , 使用起来非常简单。
当发起远程调用时，Ribbon先从注册中心拉取服务地址列表，然后按照一定的路由策略选择一个发起远程调用，一般的调用策略是轮询。
Ribbon负载均衡策略有哪些 ?
- RoundRobinRule：简单轮询服务列表来选择服务器。
- WeightedResponseTimeRule：按照权重来选择服务器，响应时间越长，权重越小。
- RandomRule：随机选择一个可用的服务器。
- ZoneAvoidanceRule(Ribbon默认策略)：区域敏感策略，以区域可用的服务器为基础进行服务器的选择。使用Zone对服务器进行分类，这个Zone可以理解为一个机房、一个机架等。而后再对Zone内的多个服务做轮询。
如何自定义负载均衡策略
提供了两种方式：
1，创建类实现IRule接口，可以指定负载均衡策略，这个是全局的，对所有的远程调用都起作用。
2，在客户端的配置文件中，可以配置某一个服务调用的负载均衡策略，这个是局部生效，只是对配置的这个服务生效远程调用。
