架构设计系列（七）：微服务架构_微服务代码结构-优快云博客

本文链接：https://blog.youkuaiyun.com/qq_31366767/article/details/145879960

一、概述

随着业务规模的不断扩大，开发团队不断扩张，传统的单体服务会出现团队协助和系统性能上的问题。例如：

部署效率低：代码越来越多，所依赖的资源不断增长，导致打包部署的时间越来越长。
团队开发效率低：随着团队的扩张，多人协同在同一个分支同一个模块中编写代码，增大了代码冲突的概率，就算是细微的修改也需要重启服务，在不断重启中浪费测试资源，导致开发效率低。
系统可用性差：由于所有的业务都在服务中，一旦有功能模块出现故障，则整个服务都将无法使用。

基于以上的痛点，微服务在业务开发上的应用越来越广。其实在初期的技术选型上，是选用微服务还是使用单体，需要根据当时的团队规模，业务量等综合因素作为评估。而不是一股脑的拍板新的就是好的。

二、微服务架构组成

我们经常说的微服务，并不是单单指的是业务服务，它是一个整体的概念，总得来说可以分成两类，基础组件和业务服务。基础组件是处理一些非业务逻辑及整个系统的管理和监控（服务自治）而业务服务则复杂整体的业务实现。

在这里插入图片描述

下图展示了一个典型的微服务架构体系：

负载均衡器 (Load Balancer)：负责将传入流量分发到多个后端服务。
内容分发网络 (CDN)：由地理分布的服务器集群组成，用于缓存静态内容以加速交付。客户端会首先在CDN中查找所需内容，如果未找到，才会进一步访问后端服务。
API网关 (API Gateway)：处理传入请求并将其路由至相应服务。其功能包括与身份提供者交互以及执行服务发现。
身份提供者(Identity Provider)：负责用户的身份认证（Authentication）和授权（Authorization）。
服务注册与发现 (Service Registry &Discovery)：微服务的注册和发现均在此组件完成，API网关通过此组件定位需要通信的目标服务。
管理组件(Management)：负责服务的监控与管理。
业务服务(Microservices)：按不同业务域设计和部署的独立服务。每个业务域拥有专属数据库。API网关通过RESTAPI或其他协议与微服务通信，而同一业务域内的微服务之间则通过RPC（远程过程调用）进行交互。

三、微服务最佳实践

在这里插入图片描述
在开发微服务时，我们需要遵循以下最佳实践：

为每个微服务使用独立的数据存储：
每个微服务拥有专属数据库（如 MySQL、PostgreSQL），避免跨服务直接访问数据。数据所有权明确，确保服务间解耦。
保持代码的成熟度一致：
确保所有微服务的代码质量、测试覆盖率和文档水平处于相近水平。避免因部分服务技术债务过高而影响整体系统稳定性。
为每个微服务独立构建：
每个微服务拥有独立的代码库与构建流水线（CI/CD Pipeline）。支持独立部署与版本管理，避免服务间耦合。
为每个微服务分配单一职责：
每个微服务专注于单一业务功能（如支付、用户管理）。避免服务功能过重（Monolithic Service）导致维护困难。
容器化部署：
使用 Docker 将微服务打包为容器镜像，确保环境一致性。通过 Kubernetes 实现自动化部署、扩缩容与滚动更新。
设计无状态服务：
服务不保存客户端会话状态，所有状态信息存储于外部（如 Redis、数据库）。支持水平扩展，提升系统弹性。
采用领域驱动设计（DDD）：
通过事件风暴（Event Storming）明确业务边界（Bounded Context）。
使用聚合根（Aggregate Root）管理领域对象的一致性。
设计微前端架构：
将前端应用拆分为多个独立模块，每个模块对应一个微服务。
支持独立开发、测试与部署。
微服务编排
使用编排工具（如 Kubernetes、Docker Compose）管理服务依赖与生命周期。
支持服务发现、负载均衡与故障恢复。