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 协议授权
