微服务笔记

为什么微服务

单体架构  web架构 巨石应用，开发前阶段容易测试部署开发
随着业务发展，体量变大，业务之间依赖程度变大 代码量变大 影响到开发的进度和质量 风险的保障
开发效率部署效率降低

扩容单体架构 

对资源的浪费太大 收益太低，对应用的扩展整个系统的认知复杂度变大

 

微服务

      化繁为简，将应用拆分为小的应用独立开发环境 独立部署 独立上线 独立扩缩容
一个服务专注一个业务，代码量少易于测试 维护，易于迭代优化。
复杂度高 ，不同的微服务可以通过rpc 消息队列来进行通讯，可以使用不同的语言数据库实现当前的微服务

测试难度增大 一个服务依赖多个微服务 微服务的升级可能会牵一发动全身

API GetAway+BFF?在当前层进行身份认证与授权

去中心化： 技术方向 数据访问Open

依赖基础设施自动化 搭建微服务部署于测试 gitlab gitlab hooks k8s

微服务api兼容性 接口契约

微服务划分

通过业务职能或DDD进行业务划分

公司内部不同部门提供职能。

通过领域驱动DDD理念进行拆分

CQRS

命令端提供CRUD请求提供触发事件

查询端口？

微服务通信

微服务通信rpc，rpc实现方式有http方式 grpc 有基于TCP的rpc框架

Grpc

 1，支持各种多种语言序列号支持protobuff json

 2,   基于文件的服务通过proto3 生成不同的语言protobuffer接口文件由于swaggerui 文档与代码不同步

 3，主动健康检查，服务不稳定临时从负载中一处，待恢复后重新加入请求

服务发现

1，客户端发现

2，服务端发现

 

 

微服务粗粒度进程间的通信，需要处理更多的通信带来的问题

隔离

轻重隔离 服务隔离？？？？ 

 

物理隔离 进程隔离 集群隔离

 

超时控制 ：组件快速失效 返回504，服务端shutdown正在处理的请求防止资源浪费，

进程内超时控制，通过context控制上下文超时时间达到进程内控制超时

 

过载保护 限流

令牌桶：

　　　　令牌桶的算法，桶的容量固定 按照固定速率往桶里添加请求，可以动态的根据桶中的令牌数量峰值速率调整恢复。

漏桶：   类似于令牌桶，固定桶的流量限制流出速率 不限制流入速率

两种桶的算法太过被动 没有一个自适应的限流效果 阈值太难设定

过载保护机制自适应限流保护

降级

 

重试

负载均衡

目标使请求均匀的分发在每个load节点上 均衡的流量分发

可靠的识别异常节点

JSQ 负载均衡算法 不是全局最优只是局部最优

P2C 节点打分使得请求均匀的分发