微服务架构｜ 青训营笔记

繁星点点85
131 阅读8分钟

这是我参与「第五届青训营」伴学笔记创作活动的第 13 天

微服务架构介绍

系统架构演进原因

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

系统架构演变历程

image.png

微服务架构核心三要素

  • 服务治理
  • 可观测性
  • 安全

微服务架构基本原理及特征

基本概念

  • 服务(service)：一组具有相同逻辑的运行实体。

  • 实例(instance)：一个服务中，每个运行实体即为一个实例。

  • 实例与进程的关系：没有必然的对应关系。

  • 集群(cluster)：通常指服务内部的逻辑划分，包含多个实例。

  • 常见的实例承载形式：进程、VM、k8s pod...

  • 有状态 / 无状态服务：服务的实例是否存储了可持久化的数据。

服务间通信

对于单体服务，不同模块通信只是简单的函数调用；

对于微服务，服务间通信意味着网络传输。

image.png

服务注册及发现

在代码层面，如何指定调用一个目标服务的地址？
在之前学习中，我们通常以这样的方式来实现：

// Service A wants to call B
client := grpc.NewClient("10.23.45.67:8080")

一方面，这样写有硬编码的问题，另一方面，一个服务会对应多个实体，这样写的话，如果我们不手动修改ip地址和端口号，我们就只会访问到一个实体，使得负载失去平衡。

image.png

解决思路就是，新建一个统一的服务注册中心，用于存储服务名到服务实例的映射。这类似于一个哈希表。

image.png

如果我们在服务运行时发现其中一个实例出现问题了，需要下线怎么办呢？管理员只需要去服务注册中心将问题实例的记录删除。然后等待一段时间，直到使用问题实例的其他服务都已经退出了，就可以将问题实例下线。

如果想要上线新的服务实例，那可以先新建实例，然后再去服务注册中心将对应服务记录添加到哈希表中。

流量特征

  • 统一网关入口
  • 内网通信多数采用PRC
  • 网状调用链路

核心服务治理功能

服务发布（deployment）：指让一个服务升级运行新的代码的过程

难点：

  • 服务不可用
  • 服务抖动
  • 服务回滚

image.png

蓝绿部署

蓝绿部署中，一共有两套系统：一套是正在提供服务系统(也就是上面说的旧版)，标记为“绿色”；另一套是准备发布的系统，标记为“蓝色”。两套系统都是功能完善的，并且正在运行的系统，只是系统版本和对外服务情况不同。正在对外提供服务的老系统是绿色系统，新部署的系统是蓝色系统。

image.png

蓝色系统不对外提供服务，用来做啥？

用来做发布前测试，测试过程中发现任何问题，可以直接在蓝色系统上修改，不干扰用户正在使用的系统。

蓝色系统经过反复的测试、修改、验证，确定达到上线标准之后，直接将用户切换到蓝色系统, 切换后的一段时间内，依旧是蓝绿两套系统并存，但是用户访问的已经是蓝色系统。这段时间内观察蓝色系统（新系统）工作状态，如果出现问题，直接切换回绿色系统。

当确信对外提供服务的蓝色系统工作正常，不对外提供服务的绿色系统已经不再需要的时候，蓝色系统正式成为对外提供服务系统，成为新的绿色系统。原先的绿色系统可以销毁，将资源释放出来，用于部署下一个蓝色系统。

蓝绿部署特点

  • 蓝绿部署的目的是减少发布时的中断时间、能够快速撤回发布。
  • 两套系统没有耦合的时候才能百分百保证不干扰

注意事项

蓝绿部署只是上线策略中的一种，它不是可以应对所有情况的万能方案。蓝绿部署能够简单快捷实施的前提假设是目标系统是非常内聚的，如果目标系统相当复杂，那么如何切换、两套系统的数据是否需要以及如何同步等，都需要仔细考虑。
当你切换到蓝色环境时，需要妥当处理未完成的业务和新的业务。如果你的数据库后端无法处理，会是一个比较麻烦的问题；

  • 可能会出现需要同时处理“微服务架构应用”和“传统架构应用”的情况，如果在蓝绿部署中协调不好这两者，还是有可能会导致服务停止。
  • 需要提前考虑数据库与应用部署同步迁移 /回滚的问题。
  • 蓝绿部署需要有基础设施支持。
  • 在非隔离基础架构（ VM 、 Docker 等）上执行蓝绿部署，蓝色环境和绿色环境有被摧毁的风险。

灰度发布

灰度发布, 也叫金丝雀发布。是指在黑与白之间，能够平滑过渡的一种发布方式。AB test就是一种灰度发布方式，让一部分用户继续用A，一部分用户开始用B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度，而我们平常所说的金丝雀部署也就是灰度发布的一种方式。

具体到服务器上, 实际操作中还可以做更多控制，譬如说，给最初更新的10台服务器设置较低的权重、控制发送给这10台服务器的请求数，然后逐渐提高权重、增加请求数。一种平滑过渡的思路, 这个控制叫做“流量切分”。

实现过程

  • 准备好部署各个阶段的工件，包括：构建工件，测试脚本，配置文件和部署清单文件。

  • 将“金丝雀”服务器部署进服务器中, 测试。

  • 从负载均衡列表中移除掉“金丝雀”服务器。

  • 升级“金丝雀”应用（排掉原有流量并进行部署）。

  • 对应用进行自动化测试。

  • 将“金丝雀”服务器重新添加到负载均衡列表中（连通性和健康检查）。

  • 如果“金丝雀”在线使用测试成功，升级剩余的其他服务器。（否则就回滚）

流量治理

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

image.png

负载均衡

负载均衡，英文名称为Load Balance，其含义就是指将负载（工作任务）进行平衡、分摊到多个操作单元上进行运行，例如FTP服务器、Web服务器、企业核心应用服务器和其它主要任务服务器等，从而协同完成工作任务。

部署方式

负载均衡有三种部署方式：路由模式、桥接模式、服务直接返回模式。路由模式部署灵活，约60%的用户采用这种方式部署；桥接模式不改变现有的网络架构；服务直接返回（DSR）比较适合吞吐量大特别是内容分发的网络应用。约30%的用户采用这种模式。

1、路由模式（推荐）
路由模式的部署方式，服务器的网关必须设置成负载均衡机的LAN口地址，且与WAN口分署不同的逻辑网络。因此所有返回的流量也都经过负载均衡。这种方式对网络的改动小，能均衡任何下行流量。

2、桥接模式
桥接模式配置简单，不改变现有网络。负载均衡的WAN口和LAN口分别连接上行设备和下行服务器。LAN口不需要配置IP（WAN口与LAN口是桥连接），所有的服务器与负载均衡均在同一逻辑网络中。
由于这种安装方式容错性差，网络架构缺乏弹性，对广播风暴及其他生成树协议循环相关联的错误敏感，因此一般不推荐这种安装架构。

3、服务直接返回模式
这种安装方式负载均衡的LAN口不使用，WAN口与服务器在同一个网络中，互联网的客户端访问负载均衡的虚IP（VIP），虚IP对应负载均衡机的WAN口，负载均衡根据策略将流量分发到服务器上，服务器直接响应客户端的请求。因此对于客户端而言，响应他的IP不是负载均衡机的虚IP（VIP），而是服务器自身的IP地址。也就是说返回的流量是不经过负载均衡的。因此这种方式适用大流量高带宽要求的服务。

稳定性治理

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

  • 限流
  • 熔断
  • 过载保护
  • 降级
avatar
文章
阅读
粉丝