Go进阶训练营第五期笔记

1.1 微服务概览

化繁为简，分而治之

SOA 【service-oriented Architecture】（面向服务的架构），而微服务就是SOA的最佳实践

• 小即是美：小的服务代码量少，bug少，易测试，易维护
• 单一职责：一个服务也只需要做好一件事情
• 尽可能早的创建原型：尽可能早的提供服务的API，建立服务契约，达成服务间沟通的一致约定
• 可移植性比效率更加重要：服务间的轻量级交互协议在效率和可移植性上，首先要考虑兼容性和可移植性

微服务的定义：

​ 围绕业务功能构建的，服务关注单一的业务，服务间采用轻量级的通信机制，可以完全独立部署，可以使用不同的编程语言和数据存储技术。微服务架构通过业务拆分实现服务组件化，通过组件快速开发系统，其中业务单一的服务组件可以独立部署，使得整个系统变得清晰灵活。

• 原子服务
• 独立部署和交互
• 隔离部署
• 去中心化服务治理

缺点：

• 运维困难
• 测试困难
• 微服务架构是分布式系统，由此会带来固有的复杂性。开发者不得不使用RPC或者是消息传递来实现进程间的通信；此外，必须写代码来处理消息传递中速度过慢或者是消息不可达等局部失效的问题。
• 分区的数据库架构，同时更新多个业务的主体的事务很普遍。
• 服务模块间的依赖，应用升级可能会波及多个服务模块的修改

可用性 & 兼容性

Design for failure 思想

• 隔离
• 负载均衡
• 负载保护
• 超时控制
• 限流
• 重试
• 降级

1.2 微服务设计

认证 授权

API gateway

BFF

1.3 gRPC & 服务发现

gRPC 是什么

high performance，open-source universal RPC frameWork

gRPC 是一个高性能、开源、通用的远程过程调用（RPC）框架，由Google开发并开源。它基于HTTP/2协议，使用Protocol Buffers（protobuf）作为接口描述语言。gRPC支持多种编程语言，包括C++, Java, Python, Go, Ruby等。

gRPC的特点

1. 多语言：语言中立，支持多种语言
2. 轻量级、高性能：序列化支持PB（protocol buffer）和json
3. 可插拔
4. IDL（接口描述语言）：基于文件定义服务，通过proto3工具生成指定语言的数据结构、服务端接口以及客户端Stub
5. 支持移动端：基于HTTP/2 的设计，支持双向流、消息头压缩、单TCP的多路复用、服务端推送等特性。

CAP 模型是分布式系统中常用的一种理论模型，用于描述一个分布式系统在面临网络分区的情况下可能面临的一致性、可用性和分区容错性之间的权衡关系。CAP 模型由三个概念组成：

1. 一致性（Consistency）： 所有节点在同一时间具有相同的数据视图。换句话说，当一个节点更新了数据后，所有其他节点应该能够立即看到这个更新。
2. 可用性（Availability）： 系统保证每个请求都能够得到响应，无论请求成功还是失败。可用性意味着系统在任何时刻都能够对外提供服务。
3. 分区容错性（Partition Tolerance）： 系统在遇到网络分区的情况下仍然能够继续运行。分区容错性意味着即使系统中的节点之间发生了通信故障，系统仍然能够正常运作。

CAP 模型指出，一个分布式系统在面对网络分区时，很难同时满足一致性、可用性和分区容错性这三个要求，只能在它们之间进行权衡。根据 CAP 模型，一个分布式系统最多只能同时满足其中的两个要求。

以下是 CAP 模型的一些可能组合：

1. CA： 强一致性和可用性，不支持分区容错。当发生网络分区时，系统可能会停止对外提供服务，以确保数据的一致性。
2. CP： 强一致性和分区容错性，不保证可用性。在发生网络分区时，系统可能选择牺牲可用性以确保数据的一致性。
3. AP： 可用性和分区容错性，不保证强一致性。在发生网络分区时，系统会继续对外提供服务，但可能会出现不同节点之间数据的一致性问题。

3.3 sync package

使用 -race 来检测 race condition

i++ 的方式并非原子操作

• copy the value of context to BX
• increment the value of bx
• move the new value to counter

context

cancel