什么是微服务
随着应用程序服务数量的增加，服务需要知道彼此的服务实例地址，这是许多大型应用程序无法处理的。因此，我们需要引入服务发现，它负责提供应用程序内所有组件的真实地址。这使您可以轻松地将请求发送到服务发现服务以检索可用服务实例的地址。当应用程序可以包含多个服务时，服务发现是应用程序的重要工具。应用程序服务不需要知道所有服务实例的地址。因此，服务发现引领潮流。
微服务总览
微服务架构模式使用两种不同类型的通信：同步通信和异步通信。
同步通信意味着服务通过HTTP 或GRPC 调用相互调用。
异步通信是指服务通过消息总线或事件总线相互交互。这意味着服务之间没有直接连接。
虽然这种架构允许您同时使用两种通信方法，但它也需要在服务之间使用GRPC 或HTTP 调用来获取响应。这些服务通过事件总线相互交互。此外，如果您需要创建一个允许插入新服务来接收一组特定消息的应用程序，则应使用事件总线。事件总线常用的工具包括RabbitMQ 和Kafka。
微服务构成
使用微服务架构模式时，最好集中服务日志。这些日志用于调试问题并根据类型聚合日志以进行分析。如果您需要调试请求，如果不在一个地方收集服务日志，则可能会遇到问题。您还可以将与特定请求相关的日志与唯一的关联ID 相关联。这意味着来自不同服务的与请求相关的所有日志都可以通过这个关联Id.ToolsElastic Logstash来访问。
Docker
在微服务架构中，如果想要实现可靠的应用程序或服务，则需要监控应用程序的功能、性能、通信等方面，以实现负责任的应用程序。为什么您不仅需要监控服务的整体功能和运行状况，还需要监控性能瓶颈并制定解决计划。通过在关键点定义早期服务警报来减少服务停机时间并优化用户体验。监控整个服务的资源消耗情况，例如服务负载较大时。
API 网关
调试始终是开发人员最关心的问题之一。单一调试非常容易，但在微服务架构中，代码库使调试和跟踪变得困难，因为请求可以通过不同的服务。分布式跟踪工具在这里很有用，因为它们位于一处。
如果没有分布式跟踪工具，几乎不可能跟踪不同服务之间的请求。 OpenTelemetry、Jeager 和Zipkin 等工具提供了丰富的UI 来演示请求过程并轻松跟踪请求和事件。
负载均衡
微服务是一项巨大的技术。一开始可能没有意义，但是一旦你完全使用微服务，那就没问题了。随着时间的推移，您将能够理解为什么微服务需要这些技术。因为每一项技术似乎都是解决一个特定的技术，没有过度工程，一切都就位。
版权声明：本文转载于网络，版权归作者所有。如有侵权，请联系本站编辑删除。