微服务架构| 青训营笔记

这是我参与「第三届青训营 -后端场」笔记创作活动的的第6篇笔记

为什么要有这门课？

微服务架构是当前大多数互联网公司的标准架构

我可以学到什么？

微服务架构的由来及原理

服务治理功能是如何工作的

微服务架构介绍

系统架构演变历史

为什么需要演进？

互联网爆炸发展
硬件的发展
需求的多样化
开发人员增加
计算机理论及技术的发展

演变历史

单体架构->垂直应用架构->分布式架构->SOA架构->微服务架构

单体架构

all in one process

优势：性能最高、冗余小
劣势：debug困难、模块相互影响、模块分工、开发流程

垂直应用架构

按照业务线垂直划分

优势：业务独立开发维护
劣势：不同业务完全独立有冗余

分布式架构

抽出与业务无关的公共模块

优势：业务无关的独立服务
劣势：服务模块bug可导致全栈瘫痪、调用关系复杂、不同服务冗余

SOA架构

面向服务

优势：服务注册
劣势：整个系统设计是中心化的、需要从上至下设计、重构困难

微服务架构

彻底服务化

优势：开发效率、业务独立设计、自下而上、故障隔离
劣势：治理、运维难度、观测挑战、安全性、分布式系统

微服务架构核心要素

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

可观测性：日志采集、日志分析、监控打点、监控大盘、异常报警、链路追踪

安全：身份验证、认证授权、访问令牌、审计、传输加密、黑客攻击

微服务架构原理及特征

基本概念

服务：一组具有相同逻辑的运行实体
实例：一个服务中，每个运行的实体即为一个实例
实例与进程的关系：实例与进程之间没有必然对应关系，可以一个实例对应一个或多个进程（反之不常见）
集群：通常指服务内部的逻辑划分，包含多个实例
常见的实例承载形式：进程、VM、k8s pod
有状态/无状态服务：服务的实例是否存储了可持久化的数据
服务间通信：对于单体服务、不同模块通信只是简单的函数调用，对于微服务，服务间通信意味着网络传输

服务注册及发现

如何指定调用一个目标服务的地址？

使用本地DNS

问题：本地DNS存在缓存，导致延时、负载均衡问题、不支持服务实例的探活检查、域名无法配置端口
引入中间层

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

服务实例上线及下线过程

需要下线一个实例，就从服务注册中心中把这个实例中删掉，上线同理

流量特征

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

核心服务治理功能

服务发布

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

难点：服务不可用、服务抖动、服务回滚

解决方案：蓝绿部署、灰度发布（金丝雀发布）

流量治理

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

负载均衡

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

稳定性治理

线上服务总是会出现问题，这与程序的正确性无关

网络攻击
流量突增
机房端点
光纤被挖
机器故障
网络故障
机房空调故障

解决方案：限流、熔断、过载保护、降级

字节跳动服务治理实践

重试

降低错误率
降低长尾延时
容忍暂时性错误
避开下游故障实例

默认不用重试，为什么呢？

幂等性
重试风暴
超时设置