Random walk to my blog

微软的FMA（Failure Mode Analysis）设计方案, 将自动化的故障治理分为：

• Detection: 故障探测，从直接指标上发现是否有某种类型的故障
• Recovery: 故障恢复, 自动治理的过程,用于几时止损
• Diagnostics: 故障定位, 一般由扔接入，排查故障根因，从本质上解决问题

微服务架构，每个服务功能内聚，独立开发部署和运维，服务间通过接口通信，相比单体架构，开发，部署，扩展，迭代处理更加简单灵活。
但是，随着为服务的增多，服务间的依赖关系更加复杂。这是如果单个服务发生故障，有可能导致故障沿着调用链路，扩散至多个上游服务，进而导致多个业务链路故障。
故障的发生难以避免，但故障的级联可以避免。微服务之间适当做解耦，可以规避级联故障的发生。

RocketMQ介绍

什么是Kafka

消息系统

Kafka和传统的消息系统都具备系统解耦，冗余存储，流量削峰，缓冲，异步通信，可恢复行等功能。此外，Kafka还具备消息顺序型保障和回溯消费的功能。

Kafka适合大数据，日志处理等高吞吐的离线业务。

存储系统

Kafka把消息持久化到磁盘以及多副本机制，有效地降低了数据丢失的风险。

分布式系统(Distributed systems), 通常有多份数据，并且需要保持数据间的同步。然而，我们不能依赖处理节点可靠地工作，网络延迟很容易导致不一致。

微服务架构中，有一些常用的模式用于服务之间的通信/协调。本文介绍几种常用的模式：Database per service,Event Sourcing(事件溯源),CQRS(Command-Query Responsibility Segregation, 命令和查询责任分离模式), SAGA 。

Event Sourcing是原子性地更新数据库，然后发布对应更新操作的事件。CQRS(Command-Query Responsibility Segregation)通常与Event Sourcing一起使用，SAGA用于解决跨服务的分布式事务。

BFF(Backend For Frontend)层基本上是一个编排器层(orchestrator layer)，也称为前端的后端。当编排器层包括聚合、计算、某些数据的组合时，它就不仅仅是一个简单的 API 网关。由于大多数公司出于一些原因（可扩展性、开发成本、可维护性等）而转向微服务架构。因此，考虑到每个客户端都有不同的规范和不同的数据要求，每个微服务都很难为其每个客户端提供准确的 API。

SQL查询执行

SQL查询的执行可以分为三部分：逻辑计划（Logical Planning），物理计划（Physical Planning）和执行（Execution）。

前情回顾

在checker v1的文章中，讲到了:

• 原生的参数校验方法冗长
• 使用tag的校验方法可读性差，容易出错，性能不高（需要使用反射读取每一个字段的标签，解析标签内容，生成校验逻辑），与结构体强耦合
• checker的校验方法清晰简洁，与结构体解耦。

Golang使用Gin框架的开发中，服务器在绑定HTTP请求的参数后，需要对参数进行校验：