这是我参与「第五届青训营 」伴学笔记创作活动的第 9 天，今天我学习了微服务架构的演变历史、核心要素以及服务注册与发现等等，下面是我的收获

微服务架构原理与治理实践

1.1 微服务架构介绍

1.1.1 系统架构演变历史

系统架构是需要不断演进的，理由如下

• 互联网的爆炸性发展

  • 体量越来越大

• 硬件设施的快速发展

  • CPU、存储、网络等

• 需求复杂性的多样化

  • 从文本到元宇宙的急速发展

• 开发人员的急剧增加

  • 加入这个行业的人越来越多

• 计算机理论及技术的发展

  • 算法、云原生等

架构的演进方向如下

单体架构

即所有业务逻辑都在一个进程里面

• 优势

  • 性能最高
  • 冗余小

• 劣势

  • debug困难
  • 模块相互影响，非核心功能困难导致进程崩溃
  • 模块分工困难，开发流程复杂

垂直应用架构

即按照业务线垂直切分，意思就是将一个业务分为一个个独立的业务分支

• 优势

  • 业务独立开发易维护

• 劣势

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

分布式架构

即抽出业务无关的公共模块

• 优势

  • 业务无关的独立服务能够分布式部署运行

• 劣势

  • 服务模块出问题可导致全站瘫痪
  • 调用关系错综复杂
  • 不同服务依然存在冗余

SOA架构（Service Oriented Architecture）

从这个时候开始引入服务和服务注册的概念

• 优势

  • 服务注册

• 劣势

  • 整个系统设计是中心化的，因为有一个服务注册中心
  • 需要从上至下设计，即还是需要先知道每个层需要哪些组件，才能开始设计
  • 重构极其困难，因为涉及到重新开始从上至下设计

微服务架构

从下至上的设计，将每一个业务彻底的服务化

• 优势

  • 开发效率高
  • 业务独立设计
  • 自下而上设计
  • 故障隔离，服务间故障能做到最小化

• 劣势

  • 治理、运维难度大，因为服务太多
  • 观测挑战
  • 安全性
  • 分布式系统本身的复杂性

1.1.2 微服务架构核心要素

服务治理

• 服务注册
• 服务发现
• 负载均衡
• 扩缩容
• 流量治理
• 稳定性治理

可观测性

• 日志采集
• 日志分析
• 监控打点
• 监控大盘
• 异常报警
• 链路追踪

安全

• 身份验证
• 认证授权
• 访问令牌
• 审计
• 传输加密
• 黑产攻击

1.2 微服务架构原理及特征

1.2.1 基本概念

• 服务

  一组具有相同逻辑的运行实体

• 实例

  一个服务中，每个运行实体即为一个实例

• 实例与进程的关系

  实例与进程之间没有必然对应关系，可以一个实例对应一个或多个进程（反之不常见）

• 集群

  通常指服务内部的逻辑划分，包含多个实例

• 常见的实例承载形式

  进程、VM等

• 有状态/无状态服务

  服务的实例是否存储了可持久化的数据

服务间通信

对于单体服务，不同的模块通信只是简单的函数调用，而对于微服务，服务间通信意味着网络传输

1.2.2 服务注册与发现

以往我们想指定调用一个目标服务地址，有指定ip和端口，以及DNS映射ip，这都是有缺点的，下面介绍另外一种方法

解决思路

新增一个统一的服务注册中心，用于存储服务名到服务实例的映射

服务上线及下线过程

如果直接关闭调用这会引发流量流失，最优解就是去服务注册中心删掉该服务，然后调用方就会失去连接；上线则是在服务注册中心注册服务，然后会自动恢复调用

1.3 核心服务治理功能

1.3.1 服务发布

服务发布，即让一个服务升级运行新的代码的过程，在微服务上这也是一个问题，原因如下

• 服务不可用

  因为服务整体升级，导致整体不可用

• 服务抖动

  因为服务中的部分实例升级，导致调用时好时坏

• 服务回滚

  微服务中升级的服务出bug了，必须回滚到上一个运行正常的版本

解决方法

• 蓝绿部署

  即先升级一半，然后上线，然后再升级一半，再上线，但是需要两倍的资源

• 灰度发布（金丝雀发布）

  即假设一个服务中有三个实例，方一个升级版进去然后拿一个出来，知道三个实例全部升级完成

1.2.3 流量治理

在微服务架构下，可以通过基于地区、集群、请求等维度，对端倒端流量的路由路径进行精确控制

1.2.4 负载均衡

负载均衡就是负责分配请求在每个下游实例上的分布

1.2.5 稳定性治理

通过限流、熔断、过载保护、降级方法，对不同的事故进行处理