微服务架构
演进
单体架构==>垂直应用架构==> 分布式架构==>SOA架构==> 微服务架构
单体架构
优势:
- 性能最高
- 冗余小
劣势:
- debug困难
- 模块相互影响
- 模块分工、开发流程
垂直应用架构
按照业务线垂直划分
优势:
- 业务独立开发维护
劣势:
- 不同业务存在冗余
- 每个业务还是单体
分布式架构
抽出业务无关的公共模块
优势:
- 业务无关的独立服务
劣势:
- 服务模块bug可导致全站瘫痪
- 调用关系复杂
- 不同服务冗余
SOA架构
面向服务
优势: 1.服务注册
劣势:
- 整个系统设计是中心化的
- 需要从上至下设计
- 重构困难
微服务架构
彻底的服务化
优势:
- 开发效率
- 业务独立设计
- 自下而上
- 故障隔离
劣势:
- 治理、运维难度
- 观测挑战
- 安全性
- 分布式系统
微服务架构
核心要素
- 服务治理
- 服务注册
- 服务发现
- 负载均衡
- 扩缩容
- 流量治理
- 稳定性治理
- 可观测性
- 日志采集
- 日志分析
- 监控打点
- 监控大盘
- 异常报警
- 链路追踪
- 安全
- 身份验证
- 认证授权
- 访问令牌
- 审计
- 传输加密
- 黑产攻击
原理
实例与进程之间没有必然对应关系，可以一个实例可以对应一个或多个进程(反之不常见)。
服务的实例是否存储了可持久化的数据(例如磁盘文件)。
服务间通信
- 对于单体服务，不同模块通信只是简单的函数调用。
- 对于微服务，服务间通信意味着网络传输。
如何使用代码调用目标服务的地址？
- DNS
- 本地DNS存在缓存，导致延时。
- 负载均衡问题。
- 不支持服务实例的探活检查。
- 域名无法配置端口。
- 服务注册中心 新增一个统一的服务注册中心，用于存储服务名到服务实例的映射。
使用心跳机制不断检测每个实例（服务）的存活。
流量特征
- 统一网关入口
- 内网通信多数采用RPC
- 网状调用链路
核心服务治理
服务发布
服务发布(deployment)，即指让一个服务升级运行新的代码的过程。
服务回滚
蓝绿部署 优点：简单，稳定 缺点：需要两倍资源
灰度发布 优点：不需要耗费过多额外资源 缺点：操作复杂
流量治理
在微服务架构下，我们可以基于地区、集群、实例、请求等维度，对端到端流量的路由路径进行精确控制。
负载均衡
负载均衡(Load Balance)负责分配请求在每个下游实例上的分布。
常见的LB策略
- Round Robin
- Random
- Ring Hash
- Least Request
稳定性治理
线上服务总是会出问题的，这与程序的正确性无关。
- 网络攻击
- 流量突增
- 机房断电
- 光纤被挖
- 机器故障
- 网络故障
- 机房空调故障
常见稳定性治理功能：
- 限流：从系统的流量入口考虑，从进入的流量上进行限制，达到保护系统的作用。
- 熔断：在服务异常或者不可用时，自动切换到备用逻辑（或停止访问），避免大量请求堆积导致系统崩溃。
- 过载保护：当探测到服务器已经处于过载时则主动拒绝请求不进行处理，一般做法是快速返回 error。
- 降级：从系统内部的平级服务或者业务的维度考虑，流量大了，可以干掉一些，保护其他正常使用。
