微服务架构原理及特征
-
系统架构的演变历史
- 原因:互联网爆炸性发展,硬件设施快速发展,需求复杂性多花化等
- 历史:单体架构,垂直应用架构,分布式架构,SOA,微服务
-
单体架构
- 优势:性能最高,冗余小
- 劣势:debug困难,模块相互影响,模块分工,开发流程
-
垂直架构-按照业务线垂直划分
- 优势:业务独立开发维护
- 劣势:不同业务存在冗余,每个业务还是单体
-
分布式架构-抽出业务无关的公共模块
- 优势:业务无关的独立服务
- 劣势:服务模块bug可导致全栈瘫痪,不同服务冗余,调用关系复杂
-
SOA架构-面向服务
- 优势:服务注册
- 劣势:整个系统的设计是中心化的,需要从上至下设计,重构困难
-
微服务架构-彻底的服务化
- 优势:开发效率,业务独立设计,自下而上,故障隔离
- 劣势:治理、运维难度，观测挑战,安全性,分布式系统
-
核心要素
- 服务治理
- 服务发现
- 服务注册
- 负载均衡
- 扩容缩
- 流量治理
- 稳定性治理
- 可观测性
- 日志分析
- 日志采集
- 监控大盘
- 异常报警
- 链路追踪
- 安全
- 身份授权
- 认证授权
- 访问令牌
- 审计
- 传输加密
- 黑产攻击
- 服务治理
-
基本概念
-
服务
- 一组具有相同逻辑的运行实体
-
实例
- 一个服务中,每个运行实体即为一个实例
-
实例与进程的关系
- 实例与进程之间没有必然的对应关系,可以一个实例对应一个或多个进程
-
集群
- 通常指服务内部的逻辑划分,包含多个实例
-
常见的实例承载形式
- 进程
- VM
- k8s pod
-
有服务/无服务状态
- 服务的实例是否存储了可持久化的数据
-
服务间通信
- 对于单体服务,不同模块通信只需要简单的函数调用
- 对于微服务,服务间通信意味着网络传输
- HTTP,GRPC,Thrift,other...
-
-
服务注册及发现
- 代码层面,如何指定调用一个目标服务的地址(ip:port)?
client:=grpc.NewClient("10.23.45.67.8080") //问题分析,服务地址是不固定的- 用DNS?
net.Dial("b.service,org:8080") //问题:本地DNS存在缓存,导致延迟,负载均衡问题 //不支持服务实例的探活检查,域名无法配置端口- 解决思路:新增一个统一的服务注册中心,用于存储服务名到服务实例的映射
- 服务实例的上线及下线过程
- 下线先去服务注册中心删掉该服务
- 上线先加服务并health check,之后去注册中心添加
-
流量特征
- 统一网关入口
- 内网通信多数采用rpc
- 内网调用链路
-
服务发布
- 定义
- 让一个服务升级运行新的代码的过程
- 定义
-
流量治理
- 在微服务架构下,我们可以基于地区,集群,实例,请求等维度,对端到端流量的路由路径处理进行分流
-
负载均衡
- 负责分配请求在每个下游实例上的分布
- 常见LB策略
- Round Robin
- Random
- Ring Hash
-
稳定性治理
- 线上服务总是会出问题的,这与程序的正确性无关
- 网络攻击,流量突增,机房断电,光纤被挖,机器故障,网络故障,机房空调故障
- 治理措施
- 限流
- 熔断
- 过载保护
- 降级
- 线上服务总是会出问题的,这与程序的正确性无关
