这是我参与「第三届青训营 -后端场」笔记创作活动的第6篇笔记
架构演变历史
单体架构
所有的功能都在一个机器里。
优点是性能好，冗余小。缺点是系统增大到一定规模后debug非常困难，模块间相互影响。
垂直应用架构
按照业务线垂直划分。优点是业务独立开发维护。缺点是不同的业务存在冗余功能，每个业务还是单体架构
分布式架构
抽出了业务无关的公共模块作为服务。优势是业务无关的独立服务，缺点是服务模块bug可能导致网站瘫痪，调用关系复杂，不同服务也可能存在冗余。
SOA架构
面向服务。优势是服务的注册和发现，缺点是整个系统是中心化的，需要从上至下设计，重构困难
微服务架构
彻底的服务化。优点是，开发效率高，业务独立设计，自下而上，故障隔离。缺点是，治理运维难，观测服务状态难，安全性，以及分布式系统的复杂性。
微服务核心要素
- 服务治理。包括服务注册，服务发现，负载均衡，扩缩容，流量治理，稳定性治理。
- 可观测性。包括日志采集，日志分析，监控打点，监控大盘，异常报警，链路追踪。
- 安全性。包括身份验证，认证授权，访问令牌，审计，传输加密，黑产攻击
微服务架构原理和特征
服务注册与发现
- ip+port？ip和port是动态的，而且需要硬编码，同时不利于理解。
- 域名+端口？dns缓存问题，如何负载均衡？
- 注册中心，存储服务名到地址的映射。
流量调整
- 统一网关入口
- 内网通信多数采用RPC
- 网状调用链路。
核心治理功能
服务发布
难点
- 导致服务不可用
- 导致服务抖动
- 发布失败需要回滚 策略
- 蓝绿部署。先在一部分机器上发布新版本，此时把流量切换到另外一部分机器上。部署完后，把流量恢复。确认新版本没有问题后，就把另外一部分做同样的发布过程。
- 灰度发布。一次发布一小部分机器。
流量治理
微服务架构下，可以基于地区，集群，实例，请求等维度，对端到端的流量路由路径进行精确控制
负载均衡
负责分配请求分发到哪个下游实例 策略：轮询，源地址hash，随机，权重轮询，
稳定性治理
限流，熔断，过载保护，降级（拒绝部分服务）。
重试
重试的意义
降低错误率，降低长尾延时（对于偶尔耗时较长的请求，重试有机会更快的返回），容忍暂时性的错误，避开下游故障实例（重试其他示例）。
重试的难点
- 需要保证服务是幂等的
- 重试风暴，重试沿着调用链路指数级上升。
- 超时设置。
重试策略
- 限制重试比例。只有成功请求次数占大部分的时候，少量失败的请求才有重试的必要，不然只会加剧错误的严重。
- 防止链路重试。理想情况下只有最后一层发生重试。
- 对于超时或者延时高的请求，重新向另一个下游实例发送相同的请求，等待先到达的响应。
