1. 微服务架构介绍
1.1 系统架构演变历史
1.1.1 为什么系统架构需要演进
- 互联网的爆炸性发展
- 硬件设施的快速发展
- 需求复杂性的多样化
- 开发人员的急剧增加
- 计算机理论及技术的发展
1.1.2 系统架构的历史演变!
1.1.2.1 单体架构
优势:性能最高、冗余小
劣势:debug 困难、模块相互影响、模块分工、开发流程
1.1.2.2 垂直应用架构
优势:业务独立开发维护 劣势:不同业务存在冗余、每个业务还是单体
1.1.2.3 分布式架构
优势:业务无关的独立服务
劣势:服务模块bug可导致全站瘫痪、调用关系复杂、不同服务冗余
1.1.2.4 SOA架构
优势:服务注册 劣势:整个系统设计是中心化的、需要从上至下设计、重构困难
1.1.2.5 微服务架构
优势:开发效率、业务独立设计、自下而上、故障隔离
劣势:治理、运维难度大、观测挑战、安全性、分布式系统
1.2微服务架构概览
1.3微服务架构核心要素
服务治理
- 服务注册
- 服务发现
- 负载均衡
- 扩缩容
- 流量治理
- 稳定性治理
可观测性
- 日志采集
- 日志分析
- 监控打点
- 监控大盘
- 异常报警
- 链路追踪
安全
- 身份验证
- 认证授权
- 访问令牌
- 审计
- 传输加密
- 黑产攻击
2. 微服务架构原理及特征
2.1基本概念
服务 (service)：一组具有相同逻辑的运行实体
实例 (instance)：一个服务中，每个运行实体即为一个实例。
实例与进程的关系：实例与进程之间没有必然对应关系，可以一个实例可以对应一个或多个进程 (反之不常见)
集群 (cluster)：通常指服务内部的逻辑划分，包含多个实例。
常见的实例承载形式：进程、VM、k8s pod
有状态 / 无状态服务：服务的实例是否存储了可持久化的数据(例如磁盘文件)
2.2 服务间通信
对于单体服务，不同模块通信只是简单的函数调用。 对于微服务，服务间通信意味着网络传输。
3. 核心服务治理功能
3.1 服务发布
服务发布 (deployment)，即指让一个服务升级运行新的代码的过程。
3.1.1服务发布难点
- 服务不可用
- 服务抖动
- 服务回滚
3.1.2 蓝绿部署
简单、稳定但需两倍资源
3.1.3 灰度部署
灰度发布 (金丝雀发布)
金丝雀(canary) 对瓦斯及其敏感，17世纪时，英国旷工在下井前会先放入一只金丝雀，以确保矿共中没有瓦斯。
3.2 流量治理
在微服务架构下我们可以基于地区、集群、实例、请求等维度，对端到端流量的路由路径进行精确控制。
3.3 负载均衡
负载均衡 (Load Balance)负责分配请求在每个下游实例上的分布
常见的 LB 策略
- Round Robin
- Random
- Ring Hash
- Least Request
3.4 稳定性治理
线上服务总是会出问题的，这与程序的正确性无关。
- 网络攻击
- 流量突增
- 机房断电
- 光纤被挖
- 机器故障
- 网络故障
- 机房空调故障
微服务架构中典型的稳定性治理功能
- 限流
- 熔断
- 过载保护
- 服务降级
4. 总结
微服务的核心服务治理是指将应用程序拆分为独立的服务，每个服务都作为一个独立的单元进行开发和部署，以实现高内聚、低耦合的开发原则。在服务治理中，需要建立服务注册中心、服务消费者和服务提供者，并使用API网关进行统一的访问控制和路由。服务治理还需要考虑服务的版本控制、服务之间的调用关系、服务之间的通信协议、服务之间的依赖关系、服务的容错和恢复等问题。通过服务治理，可以实现服务的独立开发和部署，提高系统的可维护性和可扩展性，同时也可以降低系统的复杂性和维护成本。
