如何制作自己的网站,上海网站建设沪icp备,微信开发公众平台,wordpress弹窗插件微服务架构是一种软件开发模式#xff0c;它将一个复杂的应用程序拆分为多个个独立的、小型的、可复用的服务#xff0c;每个服务负责一个特定的业务功能。 微服务架构有许多优点#xff0c;例如提高系统的可扩展性、可维护性、可测试性和故障容忍性。 但是#xff0c;微服…微服务架构是一种软件开发模式它将一个复杂的应用程序拆分为多个个独立的、小型的、可复用的服务每个服务负责一个特定的业务功能。 微服务架构有许多优点例如提高系统的可扩展性、可维护性、可测试性和故障容忍性。 但是微服务架构也有很多问题需要注意例如如何设计合理的划分服务接口、如何在服务间实现高效通信、如何保证数据一致性等。因此要想成功地使用微服务架构我们需要遵循一些最佳实践。 以下是一些微服务架构的最佳实践我将尽我所了解的知识给大家进行讲解。本文大纲如下 1. 不使用微服务架构 没错我们应该尽量避免使用微服务架构。 认真地说使用微服务架构只能被视为最后的选择。从项目实际应用场景开发少看一些网上关于微服务的吹捧。务实一点根据项目体量、业务复杂度选择一个适合当前项目的架构。 首先尝试构建一个单体的模块化架构而不是一上来就搞微服务架构。 2. 针对失败场景进行处理 在任何使用微服务的分布式系统里面总是有调用失败的可能比如网络分区、某个服务宕机不可用等。
所以我们在系统调用层面针对失败场景的处理应该设计得越早越好。 故障设计最好三个级别 基础设施级别 数据库级别和 单个微服务级别 实际的针对失败场景处理可以使用断路器、服务降级和 隔板模式。 隔板模式在分布式系统中就是指资源隔离在分布式系统里资源隔离通常按业务分为进程级别的隔离和线程级别的隔离某些简单的服务质量要求不高的业务场景下实现进程级别的隔离就够了但是在某些对服务质量要求较高的分布式场景下需要线程级别的细粒度隔离。 3. 构建小型服务 微服务架构中每个服务应该都按单一职责进行设计。 每个微服务应该只负责一个业务领域并且尽量避免涉及其他领域。 这样可以提高代码的可读性、可测试性和可维护性也可以降低系统的复杂度和耦合度。 4. 使用轻量级通信协议 微服务架构中服务之间的通信协议时非常重要的。因为在一些对性能要求较高的场景里选择一个轻量级协议所能带来的 QPS 提升也是非常客观的。 比如服务间可以使用 REST、GRPC 或消息队列等通信协议这样可以尽可能减少服务通信带来的开销并提升性能。 5. 服务发现 微服务架构下服务实例的网络地址是动态分配和变化的因此需要一种机制能够及时获取服务实例的最新的网络地址以便进行服务间通信。 并且服务实例的数量和状态都是随着业务需求和故障情况而变化的还需要有能够及时感知服务实例的上线、下线、故障等情况的能力。 因此我们需要使用服务发现组件它负责自动发现服务实例负载均衡和故障转移。 服务发现组件有 Eureka 、Consul、Nacos 等国内的话推荐大家使用 Nacos。 6. 数据库隔离 微服务架构下每个服务的数据库应该都是单独部署的它们之间相互隔离。 一个服务要操作另一个服务数据库中的数据时都应该只能通过调用另一个服务的接口来实现而不是粗暴的直接访问其他服务的数据库进行读写。 数据库隔离的最终目标就是为了减少服务之间的耦合使它们能够独立发展。 7. 实施弹性模式 为了提高微服务架构中各个服务的弹性我们应该尽量使用弹性模式。 所谓弹性其实就是服务的可用性专业一点的话说就是从某些类型的故障中恢复并保持自身服务的能力。
那么我们应该如何实施实施弹性模式嘞 其实很简单我给大家分成两个部分进行讲解一个是服务内另一个是服务外。 服务内指的是别人调用我们的服务时需要注意的点有 添加缓存 资源隔离 接口限速 服务外指的是我们调用别人的服务时需要注意的点有 调用超时 请求重试 断路器应用 8. 服务监控于链路追踪 有句话说得好在任何分布式系统中会宕机的服务最终都会宕机。 特别是在微服务系统系统间的服务调用链路越长发生异常时的排查难度就越大。 所以为了跟上微服务的步伐我们需要发现各个服务中存在的问题。进一步也就需要针对微服务的性能、状态、异常等指标进行收集、分析、展示和告警。这有助于提高系统的可观察性、可运维性和可靠性。 链路追踪是一种技术用于监控和分析分布式系统中的请求流程以及各个服务之间的调用情况。 在分布式系统中链路追踪就是为每个请求分配一个全局唯一的标识TraceId并在请求在各个服务之间传递时记录每个服务的调用信息SpanId包括调用时间、耗时、状态等。通过收集、存储、展示和分析这些信息就可以还原出请求的完整链路以及各个服务的性能表现。 在如今流行云原生的潮流下推荐使用 Prometheus、Grafana 为微服务构建全面的监控能力使用 Skywalking 为微服务构建一套性能分析以及链路追踪平台。 9. 服务的安全性 微服务架构中各个服务的安全性设计也非常重要。 常见的有如下几种安全性设计的举措 API 网关使用 API 网关作为服务的统一入口对所有进入和离开的请求进行鉴权、路由、负载均衡、限流、缓存等功能提高服务的可用性和性能同时也增加了服务的安全性防止内部服务被直接访问或攻击。 令牌安全使用 JWT、OAuth 2.0 等标准化的令牌格式和协议来实现服务之间或服务与客户端之间的身份验证和授权防止服务被冒充或滥用。 请求过滤对 API 网关所接收到的所有请求数据进行 SQL 注入攻击、XSS 攻击和 CORS 攻击过滤拦截处理。 风控报警在 API 网关添加风控措施针对发起恶意请求的用户做黑名单风控处理针对服务内部的非业务异常进行报警通知。 10. 统一日志采集 分布式系统中各个服务的日志都位于不同的机器上因此机器越多日志统一采集的需求就越强烈。 统一日志采集是微服务架构中的一个重要的运维需求它负责收集和管理分布式系统中的各种日志如运行日志、访问日志、错误日志等以便于进行问题排查、性能分析、数据挖掘等。 推荐使用 ELK 或者 Graylog 搭建一套统一日志采集平台。 因为我使用 Graylog 比较多所以这里给大家推荐了解一波 Graylog 这个统一日志采集平台。 Graylog 是一个开源的集中式日志管理系统它可以收集、存储、分析、展示和告警各种机器数据为开发团队提供安全、应用和 IT 基础设施方面的问题的答案。 Graylog 可以让我们在一个美观的 web ui 界面上组合、关联、查询所有的日志数据。 Graylog 具有以下特点和优势 高性能Graylog 可以处理每秒数百万条日志支持多节点集群实现水平扩展和负载均衡。 易用性Graylog 提供了一个友好的 Web 界面让您可以轻松地构建复杂的查询创建自定义的仪表盘设置灵活的告警规则生成定期的报告等。 灵活性Graylog 支持多种日志来源如文件、网络、数据库、应用程序等可以通过插件和 API 进行扩展和集成满足不同的业务需求和场景。 安全性Graylog 支持使用 HTTPS、SSL/TLS 等加密技术来保护日志数据的传输和存储同时也支持使用 LDAP、OAuth 2.0 等认证和授权机制来控制用户的访问权限。 Graylog 使用教程分析 Azure 网络安全组流日志 - Graylog | Microsoft Learn 最后聊两句 本文为大家介绍了微服务架构中的 10 个最佳实践。包含 1. 不使用微服务架构、2. 针对失败场景进行处理、3. 构建小型服务、4. 使用轻量级通信协议、5. 服务发现、6. 数据库隔离、7. 实施弹性模式、8. 服务监控以及链路追踪、9. 服务安全性、10.统一日志采集。 说了这么多其实还是希望大家结合自身项目背景多多思考不要为了使用微服务而去使用微服务在已经使用了微服务架构中项目能够结合上述最佳实践加上自己对各个服务以及业务上的思考去解决哪些已存在的问题。这样才算是真正学会了微服务。 文章转载自waynaqua 原文链接https://www.cnblogs.com/waynaqua/p/17931758.html 体验地址引迈 - JNPF快速开发平台_低代码开发平台_零代码开发平台_流程设计器_表单引擎_工作流引擎_软件架构
