服务拆分和远程调用服务拆分服务间调用在开发过程中，随着代码复杂度的增加，微服务会根据业务功能进行拆分。在单体架构中，比如查询订单详情，而订单详情中还包括用户信息，那么在查询中，根据产品id在数据库中查询产品信息，然后通过用户id获取用户信息，最后返回。但是这在微服务中是不可能的，因为它不足以满足单一的职责。也就是说服务拆分后，用户服务查询用户信息，商品服务查询商品信息，所以商品信息和用户信息都要返回给前端。给产品id，从产品服务中查询产品信息，然后从产品服务中调用用户服务，查询用户信息，即服务间调用。上面的解释是指不同的微服务不要重复开发同一个业务。如果同一个业务逻辑出现在多个服务中，是微服务拆分的不合理消息。如果每个微服务都有自己的数据库，就从根本上消除了不同服务之间业务逻辑相同的问题。如下，我们创建用户服务和订单服务，按照业务逻辑拆分不同的服务，将不同的数据存入数据库。综上所述，微服务需要按照业务模块进行拆分，实现职责单一。不要重复开发相同的业务微服务来暴露业务接口给其他微服务使用。不同的服务应该有自己的数据库服务提供者来消费。在Eureka注册中心的例子中，首先使用RestTemplate硬编码HOST:IP调用服务，会增加人工维护。因此，硬编码的方法是低的。在更复杂的情况下，如果有多个服务提供者，如果使用硬编码的方法，我应该调用哪个？在复杂的情况下，如果一个服务提供者挂掉了，就会以硬编码的方式出现访问这个服务的问题。因此，这里的硬编码方法存在几个问题。服务消费者如何获取服务提供者的地址信息？如果有多个服务提供者，消费者应该如何选择？消费者如何知道服务提供者的健康状况？Eureka可以解决这个问题。它的功能是注册。其他服务是Eureka客户端。对方服务启动时，会向注册中心注册自己的信息。这些信息包括：服务名称服务地址这时候Order服务要访问User，Order就去注册中心获取User信息。如果有三个User实例，则使用负载均衡访问其中一个。并且Eureke可以保证其存储的服务信息是有效信息，由客户端实时发送给注册中心。那么有了Eureka，就可以解决以上三个问题。服务消费者如何获取服务提供者的地址信息？服务提供者在启动时，会向注册中心eureka注册自己的信息，并保存这些信息。消费者会根据服务名拉取服务到eureka。提供者信息如果有多个服务提供者，消费者应该如何选择？服务消费者使用负载均衡算法从服务列表中选择一个消费者。消费者如何知道服务提供者的健康状况？服务提供方会每隔30s向注册中心发送心跳请求上报健康状态。注册中心将更新备案列表信息。如果心跳不正常，就会被踢出去。消费者可以获得最新信息。Rebion是如何做负载均衡的？在发出请求之前，根据域名拦截来自注册中心的请求。获取访问服务的ip，发起ip:port调用服务。Irule中有多种负载均衡策略，你也可以自定义负载均衡策略。可以使用的负载均衡策略有：Nacos注册中心Nacos是SpringCloudAlibaba的产品。比尤里卡强。注册中心动态DNS动态配置服务服务元数据管理Nacos服务分层存储模型防止跨区域访问Nacos还有一个基于区域优先级的负载均衡策略：根据负载均衡服务器设备性能不同的权重，有的实例有更好的表现。其他人都很穷。我们希望性能好的机器能够承受更多的用户请求。Nacos提供权重配置来控制访问频率。权重越大，访问频率越高。以上配置均在Nacos中完成，无需改动代码，因此代码不需要重新启动。权重设置Nacos控制台可以设置实例的权重值，0到1之间，同一个集群中的多个实例，权重越高，访问频率越高注册中心也是数据中心。Namespace的同一个命名空间中还有一个Group，Group下的service/dataNamespace主要用于隔离环境，比如生产环境/开发环境。每个命名空间都有一个唯一的id服务。设置命名空间时，需要写id而不是name。不同命名空间下的服务是相互不可见的。非临时实例的心跳机制不同。非临时实例：nacos主动拉取并发送请求获取服务信息，实例不会被移除，只会标记为不健康主动推送实例信息到实例注释的方式。来源：黑马程序员微服务课程，非常好的课程，你值得拥有。
