这是我参与「第五届青训营 」伴学笔记创作活动的第11天
1.微服务架构
1.1系统架构演变历史
- 单体架构
All in one process（所有的模块在一个进程中），它的优势是性能最高冗余小，劣势是debug困难、模块相互影响
- 垂直应用架构
按照业务线垂直划分，它的优势是业务独立开发维护，劣势是不同业务之间存在冗余、每个业务还是单体（因为每个业务依然是单体架构，所以它依然存在单体架构的缺陷）
- 分布式架构
抽出与业务无关的公共模块，它的优势是业务无关的独立服务，劣势是服务模块bug就会导致全站瘫痪、调用关系复杂、不同服务冗余
- SOA（面向服务架构）
它的优势是多了一个服务注册中心（可以实现服务注册与发现），劣势是整个系统设计是中心化的、需要从上至下设计、重构困难
- 微服务架构
它的核心在于彻底的服务化，优势是开发效率高、业务独立设计、自下而上、故障隔离，劣势是治理、运维难、观测挑战、安全问题、分布式系统问题（服务拆分的很细，面临分布式系统的问题）
2.微服务架构原理与特性
2.1基本概念了解
- 服务(service)是一组具有相同逻辑的运行实体
- 实例(instance)是一个服务中，每个运行实体即为一个实例。
- 实例与进程的关系：实例与进程之间没有必然对应关系，一个实例可以对应一个或多个进程(反之不常见)
- 集群(cluster)通常指服务内部的逻辑划分，包含多个实例。（服务包括集群，集群包括实例）
- 常见的实例承载形式：进程、VM、k8s pod...
- 有状态/无状态服务：服务的实例是否存储了可持久化的数据(例如磁盘文件)
- 服务间进行通信：对于单体服务，不同模块通信只是简单的函数调用，对于微服务，服务间通信需要网络传输（通信协议有HTTP，RPC等）。
2.2服务注册与发现
2.2.1引出问题
在代码层面，如何指定调用一个目标服务的地址（ip：port）
- 直接指定
// Service A wants to call service B.
client := grpc.NewClient(“192.168.1.78:8080”)
问题：指定固定ip，不具有动态能力
- DNS指定
// Service A wants to call service B.
net.Dial(“b.server.cn:8080”)
- 使用域名进行调用，一个域名可对应多个ip
- 新的问题：本地DNS存在缓存，导致延时、负载均衡问题、不支持服务实例的探活检查、域名无法配置端口
- 解决思路
新增一个统一的服务注册中心，用于存储服务名到服务实例的映射
