微服务架构介绍
1.1系统架构演变历史
为什么系统架构需要演进？
- 互联网的爆炸性发展
- 硬件设施的快速发展
- 需求复杂性的多样化
- 开发人员的急剧增加
- 计算机理论及技术的发展
总的来说，即旧的系统架构无法满足新的系统需要
单体架构-->垂直应用架构-->分布式架构-->SOA架构-->微服务架构
单体架构：
all in one process
优点：性能最高、冗余小
缺点：debug困难、模块相互影响、模块分工及开发流程复杂
垂直应用架构
按照业务线垂直划分
优点：业务独立开发维护
缺点：不同业务间存在冗余、每个业务还是单体
分布式架构
抽出业务无关的公共模块
优点：业务无关的独立服务
缺点：单个服务模块bug可导致全站瘫痪、调用关系复杂、不同服务间存在冗余
SOA架构
面向服务
优点：服务注册功能
缺点：整个系统设计是中心化的、需要从上至下设计、重构困难
微服务架构
彻底的服务化
优点：开发效率、业务独立设计、自下而上、故障隔离
缺点：治理运维难度、观测挑战、安全性、分布式系统
1.2微服务架构概览
1.3微服务架构核心要素
服务治理: 服务注册、服务发现、负载均衡、扩缩容、流量治理、稳定性治理等
可观测性： 日志采集、日志分析、监控打点、监控大盘、异常报警、链路追踪等
安全： 身份验证、认证授权、访问令牌、审计、传输加密、黑产攻击等
微服务架构原理及特征
2.1基本概念
服务(service): 一组具有相同逻辑（运行同一段代码）的运行实体（即实例）
实例（instance）： 一个服务中，每个运行实体即为一个实例
实例与进程的关系： 实例与进程之间没有必然对应关系，一个实例可以对应一个或多个进程（反之不常见）
集群（cluster）： 通常指服务内部的逻辑划分，包含多个实例
常见的实例承载形式： 进程、VM、k8s pod 等
有状态/无状态服务： 服务的数据是否存储了可持久化的数据（例如磁盘文件）
服务间通信： 对于单体服务，不同模块通信只是简单的函数调用，对于微服务，服务间通信意味着网络传输
2.2服务注册及发现
问题： 在代码层面，如何指定调用一个目标服务的地址（ip：port）？
解决思路： 新增一个统一的服务注册中心，用于存储服务名到服务实例的映射
服务实例上线、下线过程：
下线：
上线：
2.3流量特征
- 统一网关入口
- 内网通信多数采用RPC
- 网状调用链路
核心服务治理功能
3.1服务发布
服务发布（deployment） ，即让一个服务升级运行新的代码的过程
服务发布的难点： 服务不可用、服务抖动、服务回滚
蓝绿部署： 简单、稳定，但需要两倍资源
灰度发布（金丝雀发布）： 节省资源，但是需要精细化流量控制，回滚复杂
3.2流量治理
在微服务架构下，我们可以基于地区、集群、实例、请求等维度，对端到端流量的路由路径
3.3负载均衡
负载均衡（Load Balance）负责分配请求在每个下游实例上的分布
3.4稳定性治理
线上服务总会出问题的，这与程序的正确性无关。 因为还有许多客观因素存在 ：
- 网络攻击
- 流量突增
- 机房断电
- 光线被挖
- 机器故障
- 网络故障
- 机房空调故障
- ......
微服务架构中典型的稳定性治理功能：
- 限流
- 熔断
- 过载保护
- 降级
