0x00 我理解的微服务 && 架构
简单一句话概括:微服务架构(Microservices architecture) 就是采用一组松耦合服务的方式架构应用
-
微服务(细粒度)的拆分:每个业务逻辑都被分解为一个微服务,微服务之间通过 REST API 或 RPC 方式通信
-
微服务架构对外暴露的接口:客户端并不能直接访问后台微服务,而是通过 API Gateway 来传递请求。API Gateway 一般负责服务路由、负载均衡、缓存、访问控制和鉴权等任务
-
微服务架构:后台微服务的高可用性保证
0x01 微服务架构的挑战
微服务治理的复杂性问题:如何保证注册和发现;如何保证多机房高可用;如何保证低延迟等等。其次,微服务化以后,服务拆分的比较多,调用链也比较长,调用链很容易受到一个坏节点的影响,导致用户端出现超时的现象。另外,负载不均衡会导致热点问题,并影响资源调度;单个节点不可用,如果限流或者熔断手段做的不好可能有雪崩效应;微服务代理的分布式事务问题和分布式一致性问题,以及编排、日志、链路追踪等问题。
概括起来,微服务架构的挑战有如下几点:
-
业务逻辑应该按照什么规则划分为微服务。有句话个人很认同,微服务是达到目的的手段,而不是目标。微服务的目标是充分分解应用程序,以促进敏捷开发和持续集成部署
-
微服务的分布式特点带来的复杂性及应对。开发人员需要基于 RPC 或者消息实现微服务之间的调用和通信,而这就使得服务之间的发现、服务调用链的跟踪和质量问题变得的十分重要
-
分区的数据库体系和分布式事务的处理。但在微服务架构下,不同服务可能拥有不同的数据库。CAP 原理的约束,使得我们不得不放弃传统的强一致性,而转而追求最终一致性,这个对开发人员来说是一个挑战
-
微服务架构对测试的挑战。传统的单体 WEB 应用只需测试单一的 REST API 即可,而对微服务进行测试,需要启动它依赖的所有其他服务
-
微服务的更新及自动化部署的挑战。比如在传统单体应用中,若有 A、B、C 三个服务需要更改,A 依赖 B,B 依赖 C。我们只需更改相应的模块,然后一次性部署即可。但是在微服务架构中,我们需要仔细规划和协调每个服务的变更部署。我们需要先更新 C,然后更新 B,最后更新 A
0x02 微服务的知识图谱
- 服务拆分模式
- 根据业务能力拆分
- 根据领域的子域拆分
- 数据库模式:描述了服务之间采用独享数据库的方式实现了解耦合
- API 网关模式 定义在微服务架构下客户端访问服务的方式
- 服务发现与负载均衡:用来在微服务架构中把客户端请求路由到一个可用的服务实例上
- 客户端服务发现
- 服务器端服务注册
- 通信方式
- 消息 API
- 远程过程调用 RPC
- 部署策略
- 单主机上部署服务的单个实例
- 单主机上部署服务的多个实例
- 分布式部署
- 解决边界问题的模式
- 微服务的基底模式
- 配置信息外部化
- 可测试性模式
- 服务组件测试
- 服务集成协议测试
- 限流器
- 断路器
- 访问令牌
- 可观测性模式:
- 应用日志
- 应用指标
- 审计日志
- 分布式追踪
- 异常追踪
- 健康检查
- 认证、鉴权、安全
- TLS
- 认证协议
- CGI 签名
- RBAC 模型
0x03 微服务的设计模式
0x04 我的关注点
个人目前对微服务架构的关注点有下面几点:
- 负载均衡
- 前端客户侧的负载均衡
- 微服务间的负载均衡
- 限流
- 限流算法
- 每个用户设置限制
- 客户端侧的节流机制
- 自适应过载保护
- 重试
- 重试策略
- 超时 &&Backoff
- 请求截止
- 超时传递
- 服务(优雅)降级
- 应对连锁故障
- 低质量回复
- 缓存
- 多级缓存
- 微服务缓存模式
过载保护 VS 熔断 VS 限流
通常来说,过载保护在被调方实现,防止被调服务被压跨;熔断在主调方实现,在被调服务节点故障或者网络异常访问不通等情况下,及时将有问题的节点隔离,并且进行探测恢复;而限流既可以在被调方也可在主调方实现,用于请求的被动 / 主动的速率限制。这几种策略可以共同使用,保证服务调用的稳定性。
0x05 Kubernetes + Service Mesh = 完整的微服务框架
一图胜千言,Kubernetes 在微服务架构中的重要性
0x06 参考
转载请注明出处,本文采用 CC4.0 协议授权