微服务架构介绍
微服务架构介绍
微服务作为近几年出现的词,一出现就受到了公司的一致好评。前几年找工作还没有微服务这个概念,现在找工作没有微服务可就很难了。那么接下来就来了解一下微服务架构是怎么样的。
1 微服务架构介绍
1.1 系统架构演变历史
首先我们先了解一下:为什么系统架构需要演进?
- 互联网的爆炸性发展
- 硬件设施的快速发展
- 硬件:包括 CPU、MEM、存储、网络
- 需求复杂性的多样化
- 文本、图片、音频、视频、VR
- 开发人员的急剧增加
- 早期的精英程序猿,如今的开发平台
- 计算机理论及技术的发展
- 算法(Paxos Raft)NoSQL大数据
下图就是系统架构的演变历史进程:
-
单体架构:
all in one process
优势:- 性能最高
- 冗余小
劣势
- debug 困难
- 模块相互影响
- 非核心功能导致程序崩溃
- 模块分工、开发流程
-
垂直应用架构
按照业务线垂直划分优势
- 业务独立开发维护
劣势
- 不同业务存在冗余
- 每个业务还是单体
不同业务线的模块存在冗余,无法复用
-
分布式架构
抽出业务无关的公共模块优势
- 业务无关的独立服务
劣势
- 服务模块 bug 可导致全站瘫痪
- 调用关系复杂
- 不同服务冗余
-
SOA架构(Service Orriented Architecture)
面向服务优势
- 服务注册
劣势
- 整个系统设计是中心化的
- 需要从上至下设计
- 重构困难
-
微服务架构
彻底的服务化优势
- 开发效率
- 业务独立设计
- 自下而上
- 故障隔离
劣势
- 治理、运维难度增加
- 观测挑战
- 安全性
- 分布式系统本身的复杂性
1.2 微服务架构概览
微服务架构大体全貌
1.3 微服务架构核心要素
- 服务治理
- 服务注册
- 服务发现
- 负载均衡
- 扩缩容
- 流量治理
- 稳定性治理
- …
- 可观测性
- 日志采集
- 日志分析
- 监控打点
- 监控大盘
- 异常报警
- 链路追踪
- …
- 安全
- 身份验证
- 认证授权
- 访问令牌
- 审计
- 传输加密
- 黑产攻击
- …
2.微服务架构原理及特征
2.1 基本概念
- 服务(service):一组具有相同逻辑的运行实体
- 实例(instance):一个服务中,每个运行实体即为一个实例。
- 实例与进程的关系
- 实例与进程之间没有必然对应关系,可以一个实例可以对应一个或多个进程(反之不常见)
- 集群(cluster):通常指服务内部的逻辑划分,包含多个实例。
- 常见的实例承载形式:进程、VM、K8s pod…
- 有状态/无状态服务:服务的实例是否存储了可持久化的数据(例如磁盘文件)。
例子:
如果把 HDFS 看作一组微服务
服务间通信:
- 对于单体服务,不同模块通信只是简单的函数调用。
- 对于微服务,服务间通信意味着网络传输。
2.2 服务注册与发现
问题:在代码层面,如何指定调用一个目标服务的地址(ip:port)?
对于网络通信功能(不管是 http 还是rpc),我们指导需要指定远程的 ip port。
既然服务之间存在通信关系,在实际代码层面,如何写通信地址。
-
如果是
hardcode
的方式指定下游实例地址有什么问题?
服务有多个实例,没法 hardcode (记住一个服务的所有实例都是运行同一份代码)
服务实例 ip port 本身是动态变化的。 -
DNS
- 本地 DNS 存在缓存,导致延时
- 负载均衡问题
- 不支持服务实例的探活检查
- 域名无法配置端口
DNS 的思想是:中间层
通过上述的问题我们知道:
解决思路
:新增一个统一的服务注册中心,用于存储服务名到服务实例的映射。
服务实例上线及下线过程
知道了服务发现的基本机制,接下来查看基于服务发现来实现平滑无损的服务实例上下线流程。因为我们不能直接下线,因为还有流量存在。
下面就是一个服务实例下线的过程
:首先会先从注册中心中去除,在服务B中去掉,之后流量没有后直接从服务B中就没有了。图示如下。
此时服务B只有两个实例,压力有点大,重新添加一个实例
上线一个服务和之前的类似:我们可以看下面的图解。
:首先会线到服务B,并进行 health check。之后上线到服务中心
ok之后将其注册到服务注册中心中
2.3 流量特征
从流量的视角看看微服务架构的全貌
- 统一网关入口
- 内网通信多数采用RPC
- 网状调用链路
弱化连接的概念,强调的是请求。
更多推荐
所有评论(0)