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

Day13——微服务框架

01.微服务架构介绍

系统架构演变历史

单体架构：

优势:

1.性能最高

2.冗余小 劣势:

1.debug困难

2.模块相互影响，会导致连锁反应

3.模块分工、开发流程

垂直应用架构

按照业务线垂直划分 优势: 1.业务独立开发维护

劣势: 1.不同业务存在冗余

2.每个业务还是单体

分布式架构

抽出业务无关的公共模块 优势: 1.业务无关的独立服务 劣势: 1.服务模块bug可导致全站瘫痪

2.调用关系复杂

3.不同服务冗余

SOA架构

面向服务 优势︰ 1.服务注册 劣势： 1.整个系统设计是中心化的

2.需要从上至下设计

3.重构困难

微服务架构

彻底的服务化 优势: 1开发效率

2.业务独立设计

3.自下而上

4.故障隔离，拆分粒度细 劣势: 1.治理、运维难度

2.观测挑战

3.安全性

4.分布式系统

微服务架构概览

微服务架构核心要素

1.服务治理 服务注册

服务发现

负载均衡

扩缩容

流量治理

稳定性治理

2.可观测性 日志采集

日志分析

监控打点

监控大盘

异常报警

链路追踪

3.安全 身份验证

认证授权

访问令牌

审计

传输加密

黑产攻击

02.微服务原理及特征

基本概念

服务

一组具有相同逻辑的运行实体。

实例

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

实例与进程的关系 实例与进程之间没有必然对应关系，可以一个实例可以对应一个或多个进程(反之不常见)。

集群

通常指服务内部的逻辑划分，包含多个实例

常见的实例承载形式

进程、VM、kBs pod 。。。。

有状态/无状态服务

服务的实例是否存储了可持久化的数据(例如磁盘文件)。

服务间通信

服务间必须是可以通信的。每个实例在不同的机器，要通信

对于单体服务,不同模块通信只是简单的函数调用。对于微服务，服务间通信意味着网络传输。

服务注册与发现

在代码层面，如何指定调用一个目标服务的地址(ip:port)?

比如A服务要调用B服务，B服务的地址怎么调用

这样写，有问题，因为首先代码里地址不好写死

另外，如果写死，就只会有一个B服务实例

那如果使用DNS，用域名，把B服务的几个端口注册上去

问题所在：本地 DNS存在缓存，导致延时负载均衡问题（会经常选第一个ip）。 不支持服务实例的探活检查（域名不存在也能配置上去，这样访问时会出错）。域名无法配置端口。

解决思路:新增一个统一的服务注册中心用于存储服务名到服务实例的映射。

可以将注册中心看成hash看成map

服务实例上线及下线过程

想要下线有问题的B的第三个实例，可以先在注册中心删掉第三个实例，缓存一会后，第三个实例会消失

上线一个实例，先把一个新实例加好，进行进网检查测试其功能，再把他注册到注册中心，上线完成

流量特征

统一网关入口

内网通信多数采用RPC

网状调用链路

外网通常HTTP，HTTP采用文本协议，运行效率较低