微服务架构
- 为什么系统架构需要演进？ 1. 互联网的爆炸性发展 2. 硬件设施的快速发展 3. 需求复杂性的多样化 4. 开发人员的急剧增加 5. 计算机理论及技术的发展
- 系统架构的演变历史 1. 单体架构->垂直应用架构->分布式架构->SOA架构->微服务架构->...... (1) 单体架构 ① 把所有逻辑放在一个进程里，将所有功能打包在一个程序里面 ② 优势：性能最高、冗余小 ③ 劣势：Debug困难、模块相互影响、模块风、开发流程 (2) 垂直应用架构 ① 按照业务线垂直划分 ② 优势：业务独立开发维护 ③ 劣势：不同业务存在冗余、每个业务还是单体 (3) 分布式架构 ① 抽出业务无关的公共模块 ② 优势：业务无关的独立服务，可以实现公共逻辑的复用 ③ 劣势：服务模块bug可导致全站瘫痪、调用关系复杂、不同服务冗余 (4) SOA架构 ① 面向服务，业务与服务的关系划分更清晰 ② 优势：服务注册 ③ 劣势：整个系统设计是中心化的、需要从上至下设计、重构困难 (5) 微服务架构 ① 彻底的服务化，从下而上的业务独立设计 ② 优势：开发效率高、业务独立设计、自下而上、故障隔离 ③ 劣势：治理、运维难度、观测挑战、安全性挑战、分布式系统 2. 微服务架构概览 (1) 核心组件：用户服务... (2) 网关：处理外界流量 (3) 服务配置和治理 (4) 链路追踪和监控：分布式系统 (5) 核心要素 ① 服务治理：服务注册、服务发现、负载均衡、扩缩容、流量治理、稳定性治理...... ② 可观测性：日志采集、日志分析、监控打点、监控大盘、异常报警、链路追踪...... ③ 安全：身份验证、认证授权、访问令牌、审计、传输加密、黑产攻击......
- 微服务架构原理及特征
- 概念 1. 服务：一组具有相同逻辑的运行实体。 2. 实例：一个服务中，每个运行实体即为一个实例。 3. 实例与进程的关系：实例与进程之艰难没有必要对应关系，可以一个实例对应一个或多个进程（反之不常见）。 4. 集群：服务内的逻辑划分，包含多个实例。 5. 常见的实例承载形式：进程、VM、k8s pod...... 6. 有状态/无状态服务：服务的实力是否存储了可持久化的数据（例如磁盘文件）。 7. 用微服务的视角分析HDFS：NameNode和DataNode为两个服务，单实例服务。
- 服务间通信：对于单体服务，不同模块通信只是简单的函数调用。对于微服务，服务间通信意味着网络传输。 l 在代码层面，如何指定调用一个目标服务的地址（ip:port）？ Ø 方法：hardcode 服务A调用服务B client:=grpc.NewClient(“10.23.45.67:8080”)这种方式的问题在于：一般不会指定一个固定的ip地址，因为一个服务中存在多个实例，每个实例的ip地址不同，固定的地址只能调用服务中的一个实例；服务的地址是动态的，如果指定域名，使用DNS会出现以下问题：本地DNS存在缓存，导致延时；负载均衡问题，大概率会返回第一个ip；不支持服务实例的探活检查；域名无法配置端口 Ø 解决思路：类似DNS的逻辑，新增一个统一的服务注册中心，用于存储服务名到服务实例的映射。 既然不能硬性指定ip的话，那么增加一个服务注册中心（哈希表或Map）,在serverb中注册ip和端口这样解决了DNS无法配置端口的问题，服务A的代码首先去调用服务中心拿到服务B实时的地址，使用random进行调用。
- 服务实例上线及下线过程 当服务B的第三个实例要下线时，直接下线会导致流量失败，在下线前到服务注册中心删掉第三个，那么服务A就不会调用到第三个实例，此时服务B剩余两个实例，需要添加一个实例缓解压力，在添加之前先在服务B中启动新的实例并进行健康检查，通过之后，再把新实例注册到服务注册中心当中。
- 流量特征 1. 统一网关入口。 2. 内网通信多数采用RPC。 3. 网状调用链路。 流量分两种：http和RPC，进入内部后http会转换为RPC Offline Training Job：除了可以正常接受用户请求之外，还可以有线下机器学习训练，这个训练需要走内部流程。
