微服务基础(索引)

我的微服务入门之路

Posted by pandaychen on February 1, 2020

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 模型

image

0x03 微服务的设计模式

image

0x04 我的关注点

个人目前对微服务架构的关注点有下面几点:

  • 负载均衡
    • 前端客户侧的负载均衡
    • 微服务间的负载均衡
  • 限流
    • 限流算法
    • 每个用户设置限制
    • 客户端侧的节流机制
    • 自适应过载保护
  • 重试
    • 重试策略
  • 超时 &&Backoff
    • 请求截止
    • 超时传递
  • 服务(优雅)降级
    • 应对连锁故障
    • 低质量回复
  • 缓存
    • 多级缓存
    • 微服务缓存模式

过载保护 VS 熔断 VS 限流

通常来说,过载保护在被调方实现,防止被调服务被压跨;熔断在主调方实现,在被调服务节点故障或者网络异常访问不通等情况下,及时将有问题的节点隔离,并且进行探测恢复;而限流既可以在被调方也可在主调方实现,用于请求的被动 / 主动的速率限制。这几种策略可以共同使用,保证服务调用的稳定性。

0x05 Kubernetes + Service Mesh = 完整的微服务框架

一图胜千言,Kubernetes 在微服务架构中的重要性 image

0x06 参考

转载请注明出处,本文采用 CC4.0 协议授权