微服务开发，这10个点你要知道

微服务架构是一种软件开发模式，它将一个复杂的应用程序拆分为多个个独立的、小型的、可复用的服务，每个服务负责一个特定的业务功能。

微服务架构有许多优点，例如提高系统的可扩展性、可维护性、可测试性和故障容忍性。

但是，微服务架构也有很多问题需要注意，例如如何设计合理的划分服务接口、如何在服务间实现高效通信、如何保证数据一致性等。因此要想成功地使用微服务架构，我们需要遵循一些最佳实践。

以下是一些微服务架构的最佳实践，我将尽我所了解的知识给大家进行讲解。本文大纲如下，

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 使用教程：https://learn.microsoft.com/zh-cn/azure/network-watcher/network-watcher-analyze-nsg-flow-logs-graylog

最后聊两句

本文为大家介绍了微服务架构中的 10 个最佳实践。包含 1. 不使用微服务架构、2. 针对失败场景进行处理、3. 构建小型服务、4. 使用轻量级通信协议、5. 服务发现、6. 数据库隔离、7. 实施弹性模式、8. 服务监控以及链路追踪、9. 服务安全性、10.统一日志采集。

说了这么多，其实还是希望大家结合自身项目背景，多多思考，不要为了使用微服务而去使用微服务，在已经使用了微服务架构中项目，能够结合上述最佳实践，加上自己对各个服务以及业务上的思考，去解决哪些已存在的问题。这样才算是真正学会了微服务。

关注公众号【waynblog】每周分享技术干货、开源项目、实战经验、国外优质文章翻译等，您的关注将是我的更新动力！