微服务作为近几年出现的词,一出现就受到了公司的一致好评。前几年找工作还没有微服务这个概念,现在找工作没有微服务可就很难了。那么接下来就来了解一下微服务架构是怎么样的。

1 微服务架构介绍

1.1 系统架构演变历史

首先我们先了解一下:为什么系统架构需要演进?

  • 互联网的爆炸性发展
  • 硬件设施的快速发展
    • 硬件:包括 CPU、MEM、存储、网络
  • 需求复杂性的多样化
    • 文本、图片、音频、视频、VR
  • 开发人员的急剧增加
    • 早期的精英程序猿,如今的开发平台
  • 计算机理论及技术的发展
    • 算法(Paxos Raft)NoSQL大数据

下图就是系统架构的演变历史进程:
在这里插入图片描述

  1. 单体架构:
    all in one process
    优势:

    • 性能最高
    • 冗余小

    劣势

    • debug 困难
    • 模块相互影响
      • 非核心功能导致程序崩溃
    • 模块分工、开发流程
      在这里插入图片描述
  2. 垂直应用架构
    按照业务线垂直划分

    优势

    • 业务独立开发维护

    劣势

    • 不同业务存在冗余
    • 每个业务还是单体

    不同业务线的模块存在冗余,无法复用
    在这里插入图片描述

  3. 分布式架构
    抽出业务无关的公共模块

    优势

    • 业务无关的独立服务

    劣势

    • 服务模块 bug 可导致全站瘫痪
    • 调用关系复杂
    • 不同服务冗余
      在这里插入图片描述
  4. SOA架构(Service Orriented Architecture)
    面向服务

    优势

    • 服务注册

    劣势

    • 整个系统设计是中心化的
    • 需要从上至下设计
    • 重构困难
      在这里插入图片描述
  5. 微服务架构
    彻底的服务化

    优势

    • 开发效率
    • 业务独立设计
    • 自下而上
    • 故障隔离

    劣势

    • 治理、运维难度增加
    • 观测挑战
    • 安全性
    • 分布式系统本身的复杂性
      在这里插入图片描述

1.2 微服务架构概览

微服务架构大体全貌
在这里插入图片描述

1.3 微服务架构核心要素

  • 服务治理
    • 服务注册
    • 服务发现
    • 负载均衡
    • 扩缩容
    • 流量治理
    • 稳定性治理
  • 可观测性
    • 日志采集
    • 日志分析
    • 监控打点
    • 监控大盘
    • 异常报警
    • 链路追踪
  • 安全
    • 身份验证
    • 认证授权
    • 访问令牌
    • 审计
    • 传输加密
    • 黑产攻击

2.微服务架构原理及特征

2.1 基本概念

  • 服务(service):一组具有相同逻辑的运行实体
  • 实例(instance):一个服务中,每个运行实体即为一个实例。
  • 实例与进程的关系
    • 实例与进程之间没有必然对应关系,可以一个实例可以对应一个或多个进程(反之不常见)
  • 集群(cluster):通常指服务内部的逻辑划分,包含多个实例。
  • 常见的实例承载形式:进程、VM、K8s pod…
  • 有状态/无状态服务:服务的实例是否存储了可持久化的数据(例如磁盘文件)。
    在这里插入图片描述
    例子:
    如果把 HDFS 看作一组微服务
    在这里插入图片描述

服务间通信:

  • 对于单体服务,不同模块通信只是简单的函数调用。
  • 对于微服务,服务间通信意味着网络传输。
    在这里插入图片描述

2.2 服务注册与发现

问题:在代码层面,如何指定调用一个目标服务的地址(ip:port)?

对于网络通信功能(不管是 http 还是rpc),我们指导需要指定远程的 ip port。
既然服务之间存在通信关系,在实际代码层面,如何写通信地址。

  1. 如果是 hardcode 的方式指定下游实例地址有什么问题?
    在这里插入图片描述
    服务有多个实例,没法 hardcode (记住一个服务的所有实例都是运行同一份代码)
    服务实例 ip port 本身是动态变化的。

  2. DNS

    • 本地 DNS 存在缓存,导致延时
    • 负载均衡问题
    • 不支持服务实例的探活检查
    • 域名无法配置端口
      在这里插入图片描述
      DNS 的思想是:中间层

通过上述的问题我们知道:
解决思路:新增一个统一的服务注册中心,用于存储服务名到服务实例的映射。
在这里插入图片描述

服务实例上线及下线过程

知道了服务发现的基本机制,接下来查看基于服务发现来实现平滑无损的服务实例上下线流程。因为我们不能直接下线,因为还有流量存在。

下面就是一个服务实例下线的过程
:首先会先从注册中心中去除,在服务B中去掉,之后流量没有后直接从服务B中就没有了。图示如下。
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

此时服务B只有两个实例,压力有点大,重新添加一个实例

上线一个服务和之前的类似:我们可以看下面的图解。
:首先会线到服务B,并进行 health check。之后上线到服务中心
在这里插入图片描述
ok之后将其注册到服务注册中心中
在这里插入图片描述
在这里插入图片描述

2.3 流量特征

从流量的视角看看微服务架构的全貌

  • 统一网关入口
  • 内网通信多数采用RPC
  • 网状调用链路
    在这里插入图片描述
    弱化连接的概念,强调的是请求。
Logo

权威|前沿|技术|干货|国内首个API全生命周期开发者社区

更多推荐