这是我参与「第五届青训营」伴学笔记创作活动的第 10 天

微服务架构特征

微服务架构是当前大多数互联网公司的事实架构标准。

微服务架构介绍

系统架构的演进历史

单体架构
- 所有的逻辑在同一个进程/项目里，性能高，冗余小
- debug困难，模块耦合严重，开发困难
垂直应用架构
- 按照业务进行垂直划分，每个业务都回到了单体架构
- 不同业务间存在冗余
分布式架构
- 将业务无关的部分抽离成公共模块
- 服务模块的bug会导致整站瘫痪，调用关系复杂，不同服务间有冗余
SOA架构
- 面向服务，使用服务注册中心进行服务注册
- 整个系统是中心化的（注册中心），自上而下进行设计，重构困难
微服务架构
- 彻底的服务化、将业务以微服务的形式独立进行设计，自下而上搭建。可以实现故障隔离
- 微服务治理，运维困难，难以观测，安全性问题、分布式系统
Service Mesh...

微服务架构的概览

中心还是服务相关的组件，除了核心服务之外，外部入口是网关，另外还有两个重要组成部分：

服务配置和治理
链路追踪和监控

微服务架构的核心要素有哪些？

服务治理
- 服务注册、服务发现
- 负载均衡
- 扩缩容
- 流量治理、稳定性治理
可观测性
- 日志采集、日志分析
- 监控
- 异常报警
- 链路追踪：在传统程序里可以打印出调用栈，但是微服务架构中变成了链式调用、需要提供跨机器的链路追踪来帮助排查问题。
安全：服务之间的互相调用必须要有授权认证的过程，否则会造成不安全
- 身份验证
- 认证授权
- 访问令牌
- 审计
- 传输加密
- 防黑产

微服务架构原理及特征

基本概念

什么是服务？

一组具有相同逻辑的运行实体。（即每个实体运行相同的代码）
什么是实例？

一个服务中的每个运行实体即为一个示例。

实例与进程之间有何关系？

没有必然关系
什么是集群？

通常是服务内部的逻辑划分
常见的实例承载方式有哪些？

进程、虚拟机、k8s容器
有状态服务与无状态服务有什么区别？

区别在于是否存储了持久化的数据，例如磁盘文件等。

服务注册与发现

问题的引出：在代码层面如何确定一个目标服务的地址？

client := grpc.NewClient("ip:port")

在微服务架构中，一个服务存在多个实例，因此不可能在代码层面hardcode一个固定的地址。

如果采用域名和DNS来指定一个服务呢？

存在的问题：DNS存在缓存，有延时、无法控制负载均衡、不支持服务实例的探活检查，端口无法动态配置。

解决思路：引入服务注册与服务发现

在存在服务注册与发现的情况下，可以动态地上线和下线实例而不影响服务的整体运行：先删除服务注册记录再下线&先上线测试再注册到注册中心。

微服务架构的流量特征

使用统一的网关入口
内网通信一般采用RPC
调用链路呈网状

核心服务治理功能

服务发布

服务发布：简单来说是让一个服务升级运行新的代码的过程

服务发布的难点有哪些？

服务不可用：不能让所有的服务停止
服务抖动：服务发布过程中，部分不可用
服务回滚：假设新发布的服务存在bug，需要回滚保证服务正常运行，避免服务整体不可用

服务发布的实践方案：

蓝绿部署

将整个服务分为蓝绿两个集群，分别升级。简单，稳定但需要两倍的资源（在流量低谷进行升级）。
灰度发布（金丝雀发布）

先更新服务的一个实例，如果运行正常再逐步替换。也称为滚动发布。

它的问题是需要很精细的流量控制，另外如果出现问题回滚困难

流量治理

在微服务架构下，可以基于地区、集群、实例、请求等维度，对端对端的流量路由路径进行控制。

可以根据维度对流量进行非常精细化的控制。

服务均衡

负载均衡负责分配请求在每个下游实例上的分布。

负载均衡策略：

Round Robin
Random
Ring Hash（一致性哈希）
Least Request
...

稳定性治理

线上服务总是会出问题的，即便程序是正确的。

出现故障的原因可能是网络攻击、流量突增、机房断电、光纤被挖断等等无法人为控制的外部因素。

微服务中用于稳定性治理的一些功能包括：

限流：在流量过大的时候、通过限流组件拒绝一部分服务
熔断：例如服务A调用服务B时，发现无法正常调用，正常来说会进行重试。熔断则是服务A中的熔断器主动停止重试，等待冷却。
过载保护：还是以A调用B的例子，如果B发现自身CPU使用率达到99%，则主动拒绝一部分流量实现过载保护。
服务降级：只保证重要的服务正常工作，不重要的请求接拒绝掉。

[ 微服务 | 青训营笔记]