微服务架构

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

1.微服务架构介绍

为什么要演进架构

互联网爆炸发展
硬件发展
需求复杂多样性
开发人员剧增
计算机理论技术发展

演变

单体
- 优势：
  - 性能最高
  - 冗余小
- 劣势：
  - debug困难
  - 模块相互影响
  - 模块分工、开发流程
垂直应用架构——按照业务线垂直划分
- 优势：
  - 业务独立开发运维
- 劣势：
  - 不同业务存在冗余
  - 每个业务还是单体
分布式——抽出业务无关公共模块
- 优势：
  - 业务无关的独立服务
- 劣势：
  - 服务模块bug可导致全站瘫痪
  - 调用关系复杂
  - 不同服务冗余
SOA——面向服务
- 优势：
  - 服务注册
- 劣势：
  - 整个系统设计中心化
  - 需要从上至下设计
  - 重构困难
微服务——彻底服务化
- 优势：
  - 开发效率
  - 业务独立
  - 从下而上
  - 故障隔离
- 劣势：
  - 治理、运维难度
  - 观测挑战
  - 安全性
  - 分布式系统

微服务架构核心要素

服务治理

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

可观测性

包括日志采集、分析；监控打点、监控大盘、异常报警、链路追踪...

安全

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

2. 微服务架构原理及特征

基本概念

服务：一组具有相同逻辑的运行实体
实例：一个服务中，每个运行实体即为一个实例
集群：通常指服务内部的逻辑划分，包含多个实例
常见实例承载：进程、VM、k8s pod...... 有状态/无状态服务：服务的实例是否存储了可持久化数据。

服务间通信

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

服务注册与发现

问题：代码层面，指定一个目标服务地址（ip:port）？

client:=grpc.NewClient("10.23.45.67:8080")

缺点：ip会变；只返回一个实例

用DNS

net.Dial("b.service.org:8080")

缺点：本地DNS缓存，延时；负载均衡问题；不支持服务实例探活检查；无法配置端口。

服务注册

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

流量特征

统一网关入口
内网通信多采用RPC
网络调用链路

3. 核心服务治理

服务发布

让一个服务升级运行新的代码的过程

难点：
- 服务不可用
- 服务抖动
- 服务回滚
方式：
- 蓝绿部署：简单稳定；需要两倍资源
- 灰度发布：精细切分流量很困难；回滚困难

流量治理

基于地区、集群、实例、请求等纬度，对端到端流量的路由路径进行精确控制

负载均衡

负责分配请求在每个上下游实例上的分布

稳定性治理

线上问题：
- 网络攻击
- 流量突增
- 机房断点
- 光纤被挖
- 机器故障
- 网络故障
- 机房空调故障
- ......
应对
- 限流
- 熔断
- 过载保护
- 降级

4. 字节服务治理实践

重试

本地函数和远程函数调用异常对比，重试对于远程函数调用有一定意义。，可以避免掉偶发的错误，提高SLA(Service-Level Agreement)；降低错误率；降低长尾延时；容忍暂时性错误；避开下游故障实例。

微服务架构 | 青训营笔记