微服务配置中心（微服务配置中心作用举例）



有不少小伙伴完成了项目单体结构的学习与设计，想要入门微服务，但是对微服务还没有概念，不知道有什么用。本文通过一些通俗易懂的小问题、小例子来带动思维转变，不深入剖析，点到即止。

1. 什么是微服务？为什么要引入微服务？

这个问题，用一个简单的商城系统来解释一下。首先在传统的单体架构中，所有的业务都是耦合在一起的，比如订单、商品、购物车、用户、管理员等，这样设计是很容易上手的。假设你完成了这个项目并上线，部署到服务器上进行营业。如果某一天你需要修改一下订单表结构，就是修改一下订单实体类的字段，是不是修改完之后就要重启服务器才能生效？虽然重启服务器解决了这个问题，但与此实体无关的其他业务，比如用户、购物车等，也由于服务器的停止运行而停止，受到了不必要的影响。

因此，为了降低业务之间的耦合性（也就是减少被其他无关业务的干扰），可以将这些业务拆分出来进行分别部署。比如拆成订单模块、商品模块、购物车模块······，每个模块即是一个微服务，服务之间互不干扰，于是只用重启订单微服务即可，其他大部分模块还能正常工作。

2. 客户端发送请求给服务器，请求中指定了服务器的IP，如果服务器有很多怎么办？如果用户根据服务器IP直接攻击服务器呢？

首先，服务器有很多，如果直接在前端指定，那可能需要用一个列表来保存所有服务器的地址，每次发起请求都会向列表中的某个服务器IP发起请求，这样很是麻烦。并且服务器IP暴露给了客户端，客户端可以直接攻击服务器，难以保护。

为了解决这个问题，可以通过一个中间的代理服务器，客户端只需将请求发送给这个代理服务器，由这个代理服务器将请求转发给后端服务器即可。即：在代理服务器的配置文件中指定所有服务器的IP地址，客户端发送请求给代理服务器之后，代理服务器会拉取后端服务器的某个IP发送请求，隐藏了后端服务器的真实地址，起到了保护后端服务器的作用。

不知道小伙伴还有没有这个疑问：那如果我后端服务器有很多，并且它们的配置不同，有的内存大，有的内存小，有的单核，有的多核，如何才能让请求更多的分发给性能好的服务器呢？

当有这个疑问的时候，恭喜你学会了负载均衡的思想。所谓负载均衡，就是可以根据一定的策略，来设置每个服务器处理请求的频率。反向代理服务器可以同时进行负载均衡配置，解决上述问题。如今常见的反向代理服务器有：Nginx、Apache等，感兴趣的小伙伴可以自行了解。

3. 既然微服务架构中每个服务都可以分别部署，那如果每个服务都有多个实例，反向代理服务器又如何知道发给哪个实例呢？

这个问题需要通过后端服务器的网关来解决。所谓网关，简单来说，就是反向代理服务器将请求发送给对应服务器的网关之后，网关可以将请求发送给对应的微服务。如果该微服务有多个实例，网关会拉取这些实例的地址，进行负载均衡，将请求发送给对应的实例即可。

所以说，反向代理服务器实际上并不知道，也不需要知道每个微服务的地址，只需要将请求丢给网关，由网关继续转发请求即可。

4. 微服务之间如何通信？

既然前面有说过，每个微服务之间互不干扰，那如果我有其中一个服务需要调用另一个服务的接口怎么办（在开发中，通常数据库都是分离的，每个微服务管理不同的数据库），比如我的管理员需要管理用户的信息，那当然要能使用用户服务的某些功能。

其实解决方法有不少，这里简单介绍两个：

• 第一种，调用者直接发送网络请求给被调用者（POST, GET, PUT, DELETE等）。这种很容易理解，因为接口本身就是要通过网络请求发起调用，那我直接模拟客户端的请求也不是不行。但是，这种方法比较繁琐，需要手动构建URL，请求头，处理响应等，并且可能不同服务调用逻辑出现重复代码，维护成本高。
• 第二种，使用Feign客户端。只需要引入相应的依赖和进行简单配置，直接指明目标微服务的名称，使用目标微服务提供的接口方法即可对目标接口发起请求，使用简单，在多数情况下使用，容易维护。

对此感兴趣的小伙伴可以自行了解。

5. 如何简化每个服务的配置管理？

如果每个服务的配置文件有相同的部分，手动维护十分麻烦，还容易出错。通过Nacos可以让信息共享更简单。以下是Nacos的使用介绍：

Nacos 是一个强大的注册中心和配置中心。作为配置中心，它能将各微服务中的相同配置抽取并保存，每个微服务只需在加载时从配置中心加载对应文件即可。

配置中心的优点

• 减少冗余：相同配置只需保存一次，修改时也只需在配置中心改动，不需要每个微服务单独修改。
• 简化维护：集中管理，提高配置的一致性和准确性。

服务注册和发现

Nacos还可以帮助管理微服务的注册和发现。通过Nacos，微服务能够自动注册并被网关发现，大幅减少手动配置的复杂性和错误风险。

6. 为什么要引入缓存？

假设你有一个商城系统，用户频繁查询某个热门商品的信息。如果每次都从数据库获取数据，效率会非常低。通过将这些常用数据缓存到内存中，可以快速返回结果，减轻数据库压力，提升用户体验。常用的缓存工具有Redis等。

7. 什么是消息队列？为什么要引入消息队列？

消息队列是一种用于在系统中解耦生产者和消费者的机制。假如你有一个订单服务和一个库存服务，用户下订单时，需要同时更新库存。如果直接调用，可能会因为网络或服务器问题而失败，影响用户体验。通过引入消息队列，订单服务将消息放入队列，库存服务异步处理这些消息，确保系统的可靠性和可扩展性。常用的消息队列有RabbitMQ、Kafka等。

8. 分布式保护

分布式保护措施有多种，这里简单引入一下服务限流，服务熔断和服务降级。

假设你有一个商城系统，在促销活动中，突然大量用户涌入，系统可能会被请求冲击而崩溃。通过限流机制，可以控制每秒接收的请求数量，保护系统稳定运行。例如，你可以设置限流策略，让每秒最多处理100个请求，超出部分直接返回错误或稍后再试。

假设你的商城有一个推荐服务，该服务从第三方数据源获取商品推荐。如果第三方数据源出现问题，响应时间过长或不可用时，而用户还在等待推荐结果。通过熔断机制，可以暂时停止调用，并且返回默认的推荐列表给用户，给用户友好的体验界面。

假设你使用一个新闻网站，该网站有评论功能。当网站的访问量过大时，比如突发新闻事件，评论功能的数据库负载过高，响应速度变慢。通过降级机制，可以暂时关闭评论功能或仅显示缓存的评论数据，而不允许新增评论。这样可以确保核心功能的稳定性，提升整体用户体验。

版权声明：

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！

转载请注明出处，原文链接：https://www.xkablog.com/hd-wfwjg/47525.html