前言：
目前是在职的状态，每天利用空余时间来拓展自己的技术栈，在这个专栏下，我尽量的保证一天一更的总结我学习的内容，如果有总结不对的地方，请大佬评论区留下留言或者私信我，恳请您的斧正。在学习之前，我用的开发语言是GO语言，在后端举例子的时候，也自然会用到GO语言。今天就浅浅的了解一下微服务吧。
什么是微服务？
微服务就是将一个服务拆分为多个小型的、独立服务的设计风格(架构风格)，每一个服务都运行在独立的进程之中，一般采用轻量级的通讯机制( 通常是 HTTP 或 gRPC ，通讯机制我们以后会讲)相互关联，并且他们可以通过自动化的方式进行部署。
** **
什么是单体架构？
单体架构就是一个服务之中，多个业务模块作为该服务的一部分存在同一个进程之中(这个与微服务不同，微服务是将一个服务的多个业务模块抽离出来作为多个独立的小型服务，因此是多个进程)，多个业务模块通过方法调用的方式进行通信。
两者的区别：
| 对比项 | 微服务框架 | 单体框架 |
|---|---|---|
| 架构方式 | 将应用拆分为多个独立服务 | 业务逻辑、数据库、UI 等都在一个整体应用中 |
| 部署方式 | 每个服务单独部署，独立扩展 | 整个应用作为一个整体部署 |
| 技术栈 | 每个微服务可以使用不同的技术栈 | 只能使用统一的技术栈 |
| 数据库管理 | 每个服务可以有独立数据库 | 共享一个数据库 |
| 开发和维护 | 各个团队可以独立开发不同服务 | 需要协调多个团队一起修改 |
| 扩展性 | 按需扩展单个服务，提高效率 | 需要整体扩展，资源浪费 |
| 故障隔离 | 一个服务崩溃不会影响整个系统 | 一个模块崩溃可能导致整个系统宕机 |
| 复杂性 | 需要解决分布式通信、数据一致性、运维管理等 | 结构简单，适合小型应用 |
什么时候选择微服务？
适合微服务的情况
- 业务复杂，多个模块需要独立开发和维护
- 需要高可用性，不能因单个模块故障影响整个系统
- 需要高扩展性，如某些功能需要更强的计算能力
- 需要不同的技术栈（如部分用 GO，部分用 JAVA）
- 团队规模较大，多个团队需要并行开发
适合单体架构的情况
- 业务简单，开发团队规模小
- 需要快速开发 MVP（最小可行产品）
- 没有复杂的扩展需求，系统访问量较低
- 维护成本较低，不需要微服务的额外基础设施
微服务整体框架
核心组件组成
- API 网关：统一入口、身份认证、限流
- 服务注册与发现：动态管理微服务实例
- 配置管理：集中管理配置
- 服务通信：HTTP、gRPC、消息队列
- 负载均衡：均衡流量，保障高可用
- 熔断与限流：防止雪崩，保护系统稳定
- 日志与链路追踪：故障排查和监控
- 分布式事务：保证数据一致性
- 安全：身份认证、访问控制
服务调用依赖的几个基本的组件
1. 服务描述
服务描述 是指对微服务的功能、接口、输入输出等信息的定义与说明。这有助于各个微服务之间通过标准化的接口相互调用，并保证数据交换的正确性。通常通过 API 文档、接口描述语言（如 OpenAPI/Swagger）来定义服务。
2. 注册中心
注册中心 是服务注册和发现的核心组件。微服务启动时会将自身的地址、端口等信息注册到注册中心，其他服务可以通过注册中心查找到所需服务的位置。常用的注册中心组件有 Consul、Eureka、Zookeeper、ETCD 等。
3. 服务框架
服务框架 提供了构建、部署和运行微服务的基础结构。它通常负责服务的创建、调用、负载均衡、熔断等功能。服务框架通过定义标准化的服务通信方式（如 HTTP、gRPC）来简化服务之间的调用。典型的服务框架包括 go-micro 、Dubbo 等。
4. 服务监控
服务监控 主要用于实时监控微服务的运行状态和性能指标（如响应时间、请求量、CPU/内存使用情况等）。通过服务监控，运维团队可以及时发现并解决问题，确保系统的稳定性和高可用性。常见的监控工具有 Prometheus、Grafana、ELK 等。
5. 服务追踪
服务追踪 是微服务架构中的关键组件，能够对微服务调用链路进行跟踪和分析。它帮助开发者和运维人员了解一个请求在多个微服务之间的流转过程，从而快速定位性能瓶颈或故障。常用的服务追踪工具有 Jaeger、Zipkin 等。
6. 服务治理
服务治理 涉及对微服务生命周期（包括注册、发现、路由、负载均衡、熔断、限流等）的管理与控制。它确保服务在各种运行环境下稳定、可靠地运行，并且能够适应动态的网络环境。服务治理工具包括 Istio、Envoy、Linkerd 等。
总结：
这篇文章只是对微服务的一个简单概述，核心组件组成和服务调用依赖的几个基本组件出现了内容重复，这个我们以后在具体的讲到每一个组件的时候在详细的展开。
