这是我参与【第五届青训营】伴学笔记创作活动的第9天，
微服务架构介绍
系统架构演进：硬件设施的快速发展以及用户越来越多
由最开始的单体架构演变到垂直应用架构再到分布式架构，然后到SOA架构，再到如今的微服务架构
单体架构：所有的项目在一个模块里面，性能最高，冗余小，但是模块相互影响，debug困难，模块分工困难
垂直应用架构：按照业务垂直划分，业务独立开发维护，但是有重复部分
分布式架构：抽查业务无关的公共模块，业务无关的独立服务，但是单个问题可能会导致全站出问题
SOA架构：面向服务
微服务架构：彻底的服务化，开发效率提高，业务独立设计，自上而下，可以故障隔离，但是治理和运维难度上升、安全性方面有较大问题
微服务架构概览
核心要素：
- 服务治理
- 可观测性
- 安全
原理及特征
基本概率：
-
服务：一组运行相同代码的多种实体
-
实例：一种服务中，每一个运行实体就是一个实例
对于单体服务，不同模块通信只是简单的函数调用
服务注册及发现：新增一个统一的服务注册中心，用于存储服务名到服务实例的映射
流量特征：
- 统一网关人口
- 内网通信多数采用RPC
- 网状调用链路
核心服务治理功能
服务发布
让一个服务升级运行新的代码的过程
服务发布的难点：
-
服务不可用
-
服务抖动
-
服务回滚
服务发布：
-
蓝绿部署：简单，但是需要两倍资源
-
灰度发布
流量治理
在微服务架构下，可以基于地区、集群、实例、请求等维度，对端对端流量的路由路径进行控制
负载均衡（LB）
负责分配请求在每个下游实例上的发布
稳定性治理
线上服务总会出问题的，这与程序的正确性无关，有可能是网络攻击、流量突增、机房断电、光纤被挖、机器故障.....
为此微服务架构提出了稳定性治理功能
-
限流
-
熔断
-
过载保护
-
降级
服务治理实践
重试的意义：重试可以避免偶发的错误，提高SLA；降低错误率；降低长尾延时；容忍暂时性错误；避开下游故障实例
重试的难点：
-
幂等性
-
重试风暴（雪崩）
-
超时设置
重试策略：
-
限制重试比例
-
防止链路重试
-
Hedged requests（对冲请求）
