grpc服务调用资料.md

Service 中 rpc 服务

在grpc-go中，当客户端调用ChatService的Chat1或Chat2服务时，以下是连接建立的过程：

1. 客户端初始化：客户端创建一个gRPC连接到服务器。这通常是在客户端应用的启动阶段完成的，例如通过grpc.Dial。

2. 服务调用时机：客户端在需要时调用Chat1或Chat2服务。这是根据客户端应用的业务逻辑决定的，可能是用户发起的动作或其他触发条件。

3. 建立连接：在客户端首次调用Chat1或Chat2时，gRPC框架通过之前建立的连接与服务器进行通信。若连接已存在，gRPC会重用该连接。

4. 流式通信：一旦调用开始，客户端和服务器之间就建立了流式通信，可以互发消息。

在这个过程中，Chat1和Chat2服务共享同一个gRPC连接，这是由gRPC的HTTP/2基础设施自动处理的。

1. 定义多个操作的单个RPC服务：
   • 优点：简化服务发现和管理；更少的网络开销；方便版本控制和API管理。
   • 劣势：服务可能变得臃肿，难以维护；服务间耦合度高。
   • 使用场景：功能相关性较高，且数量不多的操作。
2. 定义多个RPC服务：
   • 优点：服务清晰、职责单一；降低耦合，易于维护和扩展。
   • 劣势：增加了服务发现和网络交互的复杂性。
   • 使用场景：功能模块之间区分明显，服务需要独立扩展和部署。

结论

不要使用多个 rpc 服务封装前面的 sc -> webserver 业务

标准

• 代码行数：服务代码量巨大，难以管理和理解。
• 复杂性：服务包含多个不相关的功能，导致逻辑复杂。
• 维护困难：频繁的变更导致维护成本高。
• 部署和扩展问题：服务部署和扩展变得笨重和缓慢。
• 性能瓶颈：单一服务成为整个系统的性能瓶颈。
• 团队协作障碍：服务过大导致团队协作困难。

量级

• 代码行数：上万行代码时可能需要考虑拆分。
• 复杂性：如果功能模块之间的耦合导致理解和修改一个功能需要深入其他多个功能，可能需要拆分。
• 维护：频繁的变更导致回归测试和部署风险增加。
• 部署和扩展：服务启动时间过长或单个服务的资源需求影响到整体系统性能。
• 性能：单个服务成为性能瓶颈，影响用户体验。
• 团队协作：多个团队在同一服务上工作导致协调困难。