微服务架构原理|青训营

189 阅读6分钟

前言

微服务架构是当前大多数互联网公司的标准架构,区别于传统的单体软件架构,是一种为了适应当前互联网后台服务的「三高需求:高并发、高性能、高可用」而产生的的软件架构。

微服务架构介绍

系统架构的演进历史

为什么系统架构需要演进?

  • 互联网的爆炸性发展
  • 硬件设施的快速发展
  • 需求复杂性的多样化
  • 开发人员的急剧增加
  • 计算机理论及技术的发展

系统架构演变史

graph LR
单体架构 --> 垂直应用架构-->分布式架构-->SOA架构-->微服务架构

单体架构

all in one process

与微服务相对的另一个概念是传统的单体式应用程序( Monolithic application ),单体式应用内部包含了所有需要的服务。而且各个服务功能模块有很强的耦合性,也就是相互依赖彼此,很难拆分和扩容。

单体架构的优势
  1. 开发简洁,功能都在单个程序内部,便于软件设计和开发规划。
  2. 容易部署,程序单一不存在分布式集群的复杂部署环境,降低了部署难度。
  3. 容易测试,没有各种复杂的服务调用关系,都是内部调用方便测试。
单体架构的劣势

以下是对文本的要点总结:

  1. 单体程序在项目初期需求少、业务逻辑简单时表现良好,但随着业务迭代更新和系统规模增大,出现了以下问题:

    • 软件维护和迭代更新变得困难和痛苦。
    • 扩展整个应用程序而不是单独扩展某个业务模块,导致资源浪费。
    • 服务之间的紧密度和相依性过高,导致测试和升级困难,开发曲线上升。
  2. 单体式应用程序类似于一个大型容器,包含多个密不可分的服务。

  3. 微服务架构可以解决单体程序的问题,因为它允许将应用程序拆分为多个独立的微服务,每个微服务都可以独立扩展和升级,减少了资源浪费和开发困难。

分布式架构

抽出业务无关的公共模块

所谓分布式系统,是指一个完整的应用系统被拆分后,分别部署到不同的网络节点中,这样的系统往往是一些大型的系统。这种做法的好处是,可以提高系统的运算能力。

分布式架构的优势
  • 业务无关的独立服务
分布式架构的劣势
  • 服务模块BUG可导致全站瘫痪
  • 调用关系复杂
  • 不同服务冗余

SOA架构(Service Oriented Architecture)

面向服务

面向服务的架构(SOA)是一个组件模型,它将应用程序的不同功能单元(称为服务)进行拆分,并通过这些服务之间定义良好的接口和协议联系起来。 接口是采用中立的方式进行定义的,它应该独立于实现服务的硬件平台、操作系统和编程语言。 这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。

SOA架构的优势
  • 注册服务
SOA架构的劣势
  • 整个系统设计是中心化的
  • 需要从上至下设计
  • 重构困难

微服务架构

彻底的服务化

2014年,Martin Fowler 与 James Lewis 共同提出了微服务的概念,定义了微服务是由以单一应用程序构成的小服务,自己拥有自己的行程与轻量化处理,服务依业务功能设计,以全自动的方式部署,与其他服务使用 HTTP API 通信。同时服务会使用最小的规模的集中管理 (例如 Docker) 能力,服务可以用不同的编程语言与数据库等组件实现 。「维基百科」

微服务架构的优势
  1. 开发效率
  2. 业务独立设计
  3. 自下而上
  4. 故障隔离
微服务架构的劣势
  1. 治理、运维难度高
  2. 观测挑战
  3. 安全性
  4. 分布式系统

架构概览

image.png

  • 中间为核心组件
  • 外围分别有服务配置和治理、链路追踪和监控

三大核心要素

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

微服务架构原理及特征

基本组件

  • 服务 (service)
    • 一组具有相同逻辑的运行实体。
  • 实例 (instance)
    • 一个服务中,每个运行实体即为一个实例。
  • 实例与进程的关系
    • 实例与进程之间没有必然对应关系,可以一个实例可以对应一个或多个进程 (反之不常见)。
  • 集群 (cluster)
    • 通常指服务内部的逻辑划分,包含多个实例。常见的实例承载形式进程、VM、k8s pod...
  • 有状态 / 无状态服务
    • 服务的实例是否存储了可持久化的数据(例如磁盘文件)。
  • 服务间通信
    • 对于单体服务,不同模块通信只是简单的函数调用
    • 对于微服务,服务间通信意味着网络传输

工作原理

image.png

流量特征

  • 统一网关入口
  • 内网通信多数采用RPC
  • 网状调用链路 image.png

核心服务治理功能

服务发布

服务发布(deployment),即指让一个服务升级运行新的代码的过程。

  • 服务发布难点
    • 服务不可用
    • 服务抖动
    • 服务回滚
  • 蓝绿部署
    • image.png
  • 灰度发布(金丝雀发布)

金丝雀(canary)对瓦斯极其敏感,17世纪时,英国矿工在下井前会放入一只金丝雀,来检验矿井中是否有瓦斯。image.png

image.png

流量治理

在微服务架构下,我们可以基于地区、集群、实例、请求等维度,对端到端流量的路由路径进行精确控制。 image.png

负载均衡

负载均衡 (Load Balance) 负责分配请求在每个下游实例上的分布。 image.png

  • 常见的 LB 策略
    • Round
    • RobinRandomRing
    • HashLeast
    • Request

稳定性治理

线上服务总是会出现问题的,这与程序的正确性无关。

网络攻击、流量突增、机房断电、光纤被挖、机器故障、网络故障、机房空调故障...

微服务架构中典型的稳定性治理功能

  • 限流 image.png
  • 熔断 image.png
  • 过载保护 image.png
  • 降级 image.png