这是我参与「第五届青训营 」笔记创作活动的第7天
Day7：微服务架构
微服务架构是当前大多数互联网公司的标准架构
微服务架构介绍
为什么系统架构需要演进？
- 互联网爆炸性发展
- 硬件设施快速发展
- 需求复杂性多样化
- 开发人员急剧增加
- 计算机理论及技术发展
单体架构
all in one process
优势：
- 性能最高
- 冗余小
劣势：
- debug困难
- 模块相互影响
- 模块分工、开发流程
垂直应用架构
按照业务线垂直划分
优势：
- 业务独立开发维护
劣势：
- 不同业务存在荣誉
- 每个业务还是单体
分布式架构
抽出与业务无关的公共模块
优势：
- 业务无关的独立服务
劣势：
- 服务模块bug可导致全站瘫痪
- 调用关系复杂
- 不同服务冗余
SOA架构
面向服务
优势：
- 服务注册
劣势：
- 整个系统设计是中心化的
- 需要从上至下设计
- 重构困难
微服务架构
彻底的服务化
优势:
- 开发效率
- 业务独立设计
- 自下而上
- 故障隔离
劣势：
- 治理、运维苦难
- 观测挑战
- 安全性
- 分布式系统
微服务架构原理及特征
服务：一组具有相同逻辑的运行实体
实例：一个服务中，每个运行实体即为一个实例
实例进程关系：一个实例通常包含一个或多个进程，一个进程通常不包含多个实例
常见的实例承载形式：进程、VM、K8s pod
HDFS：NameNode应该看作一组微服务，DataNode看作一组微服务
服务间通信
对于单体服务，不同模块通信只是简单的函数调用。
对于微服务，服务间通信意味着网络传输：HTTP，gRPC，Thrift等。。。
服务注册与发现
在代码层面，如何指定调用一个目标服务的地址？
hardcode：
- 微服务环境中ip地址会动态变化
- 一个微服务中有多个实例，指定一个实例肯定不行
DNS：
- 本地DNS存在缓存，导致延时
- 负载均衡问题（域名很多情况选第一个，不是随机选）
- 不支持服务实例的探活检查
- 域名无法配置端口
解决思路：新增一个统一的服务注册中心，用于存储服务名到服务实例的映射
上线：先创建实例后注册
下线：先注销后下线实例
流量特征
- 统一网关入口
- 内网通信多数采用RPC
- 网状调用链路
