这是我参与「第五届青训营」笔记创作活动的第8天。
之前在架构初探课中讲到，由于负载增加，功能复杂，系统架构不断水平垂直切分，从最初的单体架构，演变到分布式架构，再到现在的微服务架构。如今，微服务架构被大多数互联网公司所采用。本节课中主要学习了微服务架构的相关知识。
架构的演变：
单体架构 -> 垂直应用架构 -> 分布式架构 -> SOA架构 -> 微服务架构
微服务架构使系统彻底的服务化
- 优势:
- 1.高开发迭代效率
- 2.业务独立设计
- 3.自下而上
- 4.故障隔离可控
- 劣势:
- 1.治理、运维难度增加
- 2.观测挑战
- 3.安全性
- 4.分布式系统本身的复杂性
微服务的核心要素：
服务治理（服务注册、发现、负载均衡）
可观测性（日志、监控、异常追踪）
安全（身份验证、传输加密）
微服务架构原理及特征
一些概念
服务(service) 一组具有相同逻辑的运行实体。如用户服务、商品服务、订单服务。
实例(instance) 一个服务中,每个运行实体即为一个实例。
集群(cluster) 通常指服务内部的逻辑划分，一个集群可能包含多个实例。
常见的实例承载形式 进程、VM、k8s pod 等（实例和进程没有必然对应关系，一个实例一般对应一个或多个进程，反之则不常见）
有状态/无状态服务 判断依据主要是服务的实例是否存储了可持久化的数据，例如磁盘文件
服务注册与发现
问题：服务间要互相通信，代码中如何指定一个要调用的目标服务的地址和端口号
- hardcode写死： 不好，如果被调用的服务如果有多个实例，写死ip和端口做不到负载均衡
- DNS 不好：
- 本地有DNS缓存，可能访问到旧地址，调用失败
- DNS尽管可以一个域名对应多个ip，但是还是无法负载均衡
- 不支持实例探活
- 域名无法配置端口
- 新增一个服务注册中心：服务调用时，先按服务名查服务注册中心，得到服务的地址和端口再调用
（感觉就是新增一个根据需求改进的DNS服务，可以自己写一些负载均衡，探活等功能）
服务实例上线和下线
问题：实例故障，需要下线实例，换新实例
- 直接下线： 不行，还有流量，流量会失败
- 正解：
- 先从服务注册去掉实例，再下掉实例
- 先启动新实例 实例启动后，加到服务注册中心
流量特征
弱化连接，强调请求
客户端侧请求用http，经过负载均衡、API网关等到服务侧。服务侧内部呈网状，使用rpc通信
服务治理核心功能
服务发布
蓝绿部署：
例：一个服务有两个集群AB，更新时先下掉A，断掉其流量，进行更新。A更新完上线观察，若A无异常则更新B，若A异常则A下线回滚。
灰度（金丝雀）部署：
类似蓝绿，但是从实例维度。先下线一个实例更新，上线观察，有异常则回滚。
稳定性治理
限流：服务定义一个rate limit，QPS过高则reject
熔断：若调用下游异常，断开连接，不断重试
过载保护：CPU等资源占用过高，拒绝一些请求
降级：负载过高时，优先处理重要服务的请求
