这是我参与「第五届青训营 」伴学笔记创作活动的第 8 天，对于微服务架构体系有了基本的了解，同时涉及到的相关基础知识点也有点比较好的认识。
一、系统架构演变历史
单体架构
优势
- 性能最高
- 冗余小
劣势
- debug困难
- 模块相互影响
- 模块分工
- 开发流程
垂直业务架构（按照业务线垂直划分）
优势
- 业务独立开发维护
劣势
- 不同业务存在冗余
- 每个业务还是单体
分布式架构（抽出业务无关的公共模块）
优势
- 业务无关的独立服务
劣势
- 服务模块bug会导致全站瘫痪
- 调用关系复杂
- 不同服务冗余
SOA架构（面向服务）
优势
- 服务注册
劣势
- 整个系统设计是中心化的
- 需要从上至下设计
- 重构困难
微服务架构（彻底的微服务）
优势
- 开发效率
- 业务独立设计
- 自下而上
- 故障隔离
劣势
- 治理、运维难度
- 观测挑战
- 安全性
- 分布式系统
二、微服务架构
服务：一组相同逻辑（一个服务运行同一份代码）的运行实体
实例：一个服务中，每个运行实体即为一个实例
实例与进程：通常一个实例可以对应一个或多个进程（没有必然对应关系）
集群：通常指服务内部的逻辑划分，包含多个实例
常见的实力承载形式：进程、VM、k8s pod等
有状态/无状态服务：服务的实例是否存储了可持久化的数据
代码层面，执行调用一个目标服务的地址（ip:port)?
hashcode
- 一份代码，只能指定一个固定的地址
DNS
- 本地DNS存在缓存，导致延时
- 负载均衡问题
- 不支持服务实例的探活检查
- 域名无法配置端口
最佳解决：增加一个统一的服务注册中心----用来存储服务名到服务实例的映射
流量治理：在微服务架构下，基于地区、集群、实例、请求等维度，对端到端流量的路由路径进行精确控制。
负载均衡：负责分配请求在每个下有实例上的分布。
稳定性治理：限流、熔断、过载保护、降级。
