笔者参加了今年字节跳动举办的后端青训营,在听了其中一节关于微服务介绍的课后,作下本篇笔记。
微服务架构是当前大多数互联网公司的标准架构,通过这份笔记可以了解到:微服务架构的由来及原理、服务治理功能是如何工作的。
文章目录
微服务架构介绍
系统架构的演变历史:
单体架构 → 垂直应用架构 → 分布式架构 → SOA架构 → 微服务架构 → 更加高级的架构(如Service Mesh等)
系统架构的演变
单体架构
优势:
- 性能最高
- 冗余小
劣势︰ - debug困难
- 模块相互影响
- 模块分工、开发流程
垂直应用架构
优势:
- 业务独立开发维护
劣势: - 不同业务存在冗余每个业务还是单体
分布式架构
优势:
- 业务无关的独立服务
劣势∶ - 服务模块bug可导致全站瘫痪
- 调用关系复杂
- 不同服务冗余
SOA架构(Service Oriented Architecture)
优势:
- 服务注册
劣势: - 整个系统设计是中心化的
- 要从上至下设计
- 重构困难
微服务架构
优势:
- 开发效率
- 业务独立设计
- 自下而上
- 故障隔离
劣势: - 治理、运维难度
- 观测挑战
- 安全性
- 分布式系统
微服务架构的核心要素
服务治理
服务治理包含:服务注册、服务发现、负载均衡、扩缩容、流量治理、稳定性治理
可观测性
可观测性:日志采集、日志分析、监控打点、监控大盘、异常报警、链路追踪
安全
安全:身份验证、认证授权、访问令牌、审计、传输加密、黑产攻击
微服务架构原理及特征
基本概念
服务(service):一组具有相同逻辑的运行实体。
实例(instance):一个服务中,每个运行实体即为一个实例。
实例与进程的关系:实例与进程之间没有必然对应关系,可以一个实例可以对应一个或多个进程(反之不常见)。
集群(cluster):通常指服务内部的逻辑划分,包含多个实例。
常见的实例承载形式:进程、VM、k8s pod ……
有状态/无状态服务:服务的实例是否存储了可持久化的数据(例如磁盘文件)。
服务间通信:对于单体服务,不同模块通信只是简单的函数调用。对于微服务,服务间通信意味着网络传输。下图为服务间通信的例子。
服务注册及发现
在代码层面,如何指定调用一个目标服务的地址(ip:port)?
hardcode
// Service A wants to call service B.
client := grpc.NewClient( "10.23.45.67:8080” )
hardcode的缺陷:
服务有多个实例,不能使用 hardcode(记住一个服务的所有实例都是运行同一份代码),服务实例 ip port 本身是动态变化的
DNS
DNS法的缺陷:
- 本地DNS存在缓存,导致延时。
- 负载均衡问题。
- 不支持服务实例的探活检查。
- 域名无法配置端口。
解决思路
新增一个统一的服务注册中心,用于存储服务名到服务示例的映射。(简单来说就是作一个哈希表即map)
服务实例的上线及下线的过程
假设一个场景,此时管理员想下线服务B中的实例3,此时先在服务注册中心中将实例3的记录删除。
调用服务B的服务A对服务发现进行刷新后得知注册中心中实例3已经不存在后,会调用其它实例。此时就没有对实例3的调用了,那么我们就可以将实例3进行删除。
服务的上线过程与下线相反,是先将实例加入,然后再去注册中心注册新的实例。将新实例加入后会有一个健康检查的过程,用来检查新加入的实例是否能正常运作。
之后服务A对服务B的服务发现进行刷新后,发现新加入了实例4,那么就可以调用这个新的实例。
流量特征
- 统一网关入口
- 内网通信多数采用RPC
- 网状调用链路
核心服务治理功能
服务发布
服务发布(deployment),即指让一个服务升级运行新的代码的过程。即假设当前服务运行的是以前的代码,此时让当前服务运行新编写的代码,这个过程就叫服务发布。
服务发布的难点
服务不可用:
服务抖动:
服务回滚:
服务发布的方法
蓝绿部署:
灰度发布(金丝雀发布)
流量治理
在微服务架构下,我们可以基于地区、集群、实例、请求(在下图中从左到右依次举例)等维度,对端到端流量的路由路径进行精确控制。
负载均衡
负载均衡(Load Balance)负责分配请求在每个下游实例上的分布。
常见的LB策略
- Round Robin
- Random
- Ring HashLeast Request
- …
稳定性治理
线上服务总是会出问题的,这与程序的正确性无关。
如有外部因素:
- 网络攻击
- 流量突增
- 机房断电
- 光纤被挖
- 机器故障
- 网络故障
- 机房空调故障
- …
微服务架构中典型的稳定性治理功能:
- 限流
- 熔断
- 过载保护
- 降级