微服务过载保护原理与实战

[TOC]

连锁故障

在微服务中由于服务间相互依赖很容易出现连锁故障，连锁故障可能是由于整个服务链路中的某一个服务出现故障，进而导致系统的其他部分也出现故障。例如某个服务的某个实例由于过载出现故障，导致其他实例负载升高，从而导致这些实例像多米诺骨牌一样一个个全部出现故障，这种连锁故障就是所谓的雪崩现象。

比如，服务A依赖服务C，服务C依赖服务D，服务D依赖服务E，当服务E过载会导致响应时间变慢甚至服务不可用，这个时候调用方D会出现大量超时连接资源被大量占用得不到释放，进而资源被耗尽导致服务D也过载，从而导致服务C过载以及整个系统雪崩。

阅读全文»

通过MapReduce降低服务响应时间

[TOC]

在微服务中开发中，api网关扮演对外提供restful api的角色，而api的数据往往会依赖其他服务，复杂的api更是会依赖多个甚至数十个服务。虽然单个被依赖服务的耗时一般都比较低，但如果多个服务串行依赖的话那么整个api的耗时将会大大增加。

那么通过什么手段来优化呢？我们首先想到的是通过并发来的方式来处理依赖，这样就能降低整个依赖的耗时，Go基础库中为我们提供了 WaitGroup 工具用来进行并发控制，但实际业务场景中多个依赖如果有一个出错我们期望能立即返回而不是等所有依赖都执行完再返回结果，而且WaitGroup中对变量的赋值往往需要加锁，每个依赖函数都需要添加Add和Done对于新手来说比较容易出错

基于以上的背景，go-zero框架中为我们提供了并发处理工具MapReduce，该工具开箱即用，不需要做什么初始化，我们通过下图看下使用MapReduce和没使用的耗时对比:

阅读全文»

你还在手撕微服务？快试试 go-zero 的微服务自动生成

[TOC]

0. 为什么说做好微服务很难？

要想做好微服务，我们需要理解和掌握的知识点非常多，从几个维度上来说：

• 基本功能层面

• 1. 并发控制&限流，避免服务被突发流量击垮
  2. 服务注册与服务发现，确保能够动态侦测增减的节点
  3. 负载均衡，需要根据节点承受能力分发流量
  4. 超时控制，避免对已超时请求做无用功
  5. 熔断设计，快速失败，保障故障节点的恢复能力

• 高阶功能层面

• 1. 请求认证，确保每个用户只能访问自己的数据
  2. 链路追踪，用于理解整个系统和快速定位特定请求的问题
  3. 日志，用于数据收集和问题定位
  4. 可观测性，没有度量就没有优化

阅读全文»

一文读懂云原生 go-zero 微服务框架

[TOC]

0. go-zero介绍

从今年8月7日github开源以来，已经获得了4200+ star的 go-zero 是一个集成了各种工程实践的web和rpc框架。通过弹性设计保障了大并发服务端的稳定性，经受了充分的实战检验。

go-zero包含极简的API定义和生成工具goctl，可以根据定义的api文件一键生成Go, iOS, Android, Kotlin, Dart, TypeScript, JavaScript代码，并可直接运行。

使用go-zero的好处：

• 轻松获得支撑千万日活服务的稳定性
• 内建级联超时控制、限流、自适应熔断、自适应降载等微服务治理能力，无需配置和额外代码
• 微服务治理中间件可无缝集成到其它现有框架使用
• 极简的API描述，一键生成各端代码
• 自动校验客户端请求参数合法性
• 大量微服务治理和并发工具包

阅读全文»

[TOC]

权限系统设计

理论

理论知识可以参考《操作系统-精髓与设计原理》 第15章的访问控制策略一节。

演绎

1.1 RBAC0模型

RBAC0模型如下:

这是权限最基础也是最核心的模型,它包括用户/角色/权限,其中用户和角色是多对多的关系,角色和权限也是多对多的关系。

这里的权限其实是指在资源上能做什么操作。

阅读全文»

[TOC]

面向对象编程设计原则有个总结，叫SOLID原则。
再具体下去就是具体的设计模式了。

oop设计原则SOLID详解

S=single Responsibility Principle 单一职责原则

动机

在这里，责任被认为是改变的一个原因。这个原则表明，如果我们有两个原因要修改一个类，我们必须将功能分为两个类。每个类将只处理一个责任，如果将来我们需要做一个更改，我们将在相应的类中处理。 当我们需要在具有更多职责的类中进行更改时，更改可能会影响与类的其他职责相关的其他功能。

单一职责原则是一个简单和直观的原则，但在实践中有时很难正确运用。

阅读全文»