这是我参与「第五届青训营 」伴学笔记创作活动的第 13 天
1. 微服务架构介绍
1.1 系统架构演变历史
为什么系统架构需要严禁？
- 互联网的爆炸性发展
- 硬件设施的快速发展
- 需求复杂性的多样化
- 开发人员的急剧增加
- 计算机理论及技术的发展
单体架构
- 优势：性能最高 冗余小
- 劣势：debug困难 模块相互影响 模块分工、开发流程
垂直应用架构：按照业务线垂直划分
- 优势：业务独立开发维护
- 劣势：不同业务存在冗余、每个业务还是单体
分布式架构：抽出业务无关的公共模块
- 优势：业务无关的独立服务
- 劣势：服务模块bug可导致全站瘫痪、调用关系复杂、不同服务冗余
SOA架构：面向服务
- 优势：服务注册
- 劣势：整个系统设计是中心化的、需要从上至下设计、重构困难
微服务架构：彻底的服务化
- 优势：开发效率、业务独立设计、自上而下、故障隔离
- 劣势：治理、运维难度、观测挑战、安全性、分布式系统
1.2 微服务架构概述
1.3 微服务架构核心要素
服务治理：
服务注册、服务发现、负载均衡、扩缩容、流量治理、稳定性治理
可观测性：
日志采集、日志分析、监控打点、监控大盘、异常报警、链路追踪
安全： 身份验证、认证授权、访问令牌、审计、传输加密、黑产攻击
2. 微服务架构原理及特征
2.1 基本概念
服务(service)：
一组具有相同逻辑的运行实体。
实例(instance)：
一个服务中，每个运行实体即为一个实例。
实例与进程的关系：
实例与进程之间没有必然对应关系，可以一个
实例可以对应一个或多个进程(反之不常见)
集群(cluster)：
通常指服务内部的逻辑划分，包含多个实例。
常见的实例承载形式：
进程、VM、k8s pod.....
有状态/无状态服务：
服务的实例是否存储了可持久化的数据
(例如磁盘文件)。
服务间通信： 对于单体服务。不同模块通信只是简单的函数调用。对于微服务。服务间通信意味着网络传输。
2.2 服务注册及发现
问题： 在代码层面如何调用一个目标服务的地址（ip:port）?
client:=grpc.NewClient("10.23.45.57:8080")
- 本地DNS存在缓存，导致延时
- 负载均衡配置
- 不支持服务实例的探活检查
- 域名无法配置端口
解决思路： 新增一个统一的服务注册中心，用于存储服务到服务实例的映射。
2.3 流量特征
- 统一网关入口
- 内网通信多数采用RPC
- 网状调用链路
3. 核心服务治理功能
3.1 服务发布
概念：
服务发布，即指让一个服务升级运行新的代码的过程。
服务发布的难点：
- 服务不可用
- 服务抖动
- 服务回滚
蓝绿部署
3.2 流量治理
在微服务架构下，我们可以基于地区、集群、实例、请求等维度，对端到端的路由路径
3.3 负载均衡
负载均衡负责分配请求在每个下游实例上的分布。
常见的LB策略
- Round Robin
- Random
- Ring Hash
- Least Request
3.4 稳定性治理
线上服务总是会出现问题的，这与程序的正确性无关。
- 网络攻击
- 流量突增
- 机房断电
- 光纤被挖
- 机器故障
- 网络故障
- 机房空调故障
方法：限流、熔断、过载保护、降级
