这是我参与「第五届青训营 」伴学笔记创作活动的第 7 天
微服务架构介绍
**为啥系统架构需要演进？
- 互联网的爆炸性发展
- 硬件设施的快速发展
- 需求复杂性的多样化
- 开发人员的急剧增加
- 计算机理论及技术的发展
系统架构演变历史
单体架构
all in process
优势：
1，性能最高
2，冗余小
劣势：
1，debug困难，字节有上万研发，试想全部开发成一个程序，debug会是什么体验？
2，模块间相互影响，非核心功能可能导致程序崩溃。
3，单个仓库的模块分工，依赖管理，开发流程，几乎无法分工（Google除外）
垂直应用架构
按照业务线垂直划分。
优势：
1，业务独立开发维护
劣势：
1，不同业务存在冗余，无法复用。
2，每个业务还是单体。
分布式架构
抽出业务无关的公共模块
优势：
1，业务无关的独立服务
劣势：
1，服务模块bug可导致全站瘫痪。
2，调用关系复杂。
3，不同服务冗余。
SOA架构
面向服务
优势：
1，服务注册
劣势：
1，整个系统设计上依然是中心化的。
2，需要从上到下去设计划分。
3，重构困难。
微服务架构
彻底的服务化
优势：
1，高效的开发效率
2，业务独立设计
3，自下而上，可控的故障
劣势：
1，治理，运维难度急剧增加。
2，观测挑战。
3，安全等问题。
4，分布式系统本身的复杂性。
微服务架构概览
微服务架构核心要素
服务治理
- 服务注册
- 服务发现
- 负载均衡
- 扩缩容
- 流量治理
- 稳定性治理
可观测性
- 日志采集
- 日志分析
- 监控打点
- 监控大盘
- 异常报警
- 链路追踪
安全
- 身份验证
- 认证授权
- 访问令牌
- 审计
- 传输加密
- 黑产攻击
微服务架构原理及特征
基本概念
- 服务(service)：一组具有相同逻辑的运行实体。
- 实例(instance)：一个服务中，每个运行实体即为一个实例。
实例和进程的关系：
实例和进程之间没有必然的对应关系，一个实例可以对应一个或者多个进程（反之不常见）
常见的实例承载形式：
进程、VM、k8s pod...
- 集群（cluster）：通常指服务内部的逻辑划分，包含多个实例。
- 有状态/无状态服务：服务的实例是否存储了可持久化的数据（例如磁盘文件）
- 服务间通信：对于单体服务，不同模块间通信只是简单的函数调用；对于微服务，服务间通信意味着网络传输。
