在多服务调用中，选择HTTP方式还是RPC方式取决于多种因素。以下是一些考虑：
-
传输协议：
- HTTP：基于TCP/IP协议，属于应用层协议。HTTP是一种无状态、面向请求/响应的协议，通常使用文本格式（如JSON、XML）进行数据传输。
- RPC：RPC可以基于不同的传输协议，比如gRPC就基于HTTP/2。相比传统的HTTP，HTTP/2提供了多路复用、头部压缩等特性，提高了传输效率。
-
数据格式：
- HTTP：通常采用JSON或XML等人类可读的文本格式。这些格式通用性强，但可能会导致较大的网络负载。
- RPC：通常采用二进制格式，比如gRPC使用Protocol Buffers。这种格式更紧凑，解析速度更快，但不易于人类读写。
-
连接管理：
- HTTP：每个请求/响应通常是独立的，HTTP/1.1开始支持持久连接，但缺乏内建的流控能力。
- RPC：像gRPC依赖于HTTP/2，这允许单个TCP连接中进行多路复用，使得多个请求可以并发进行，减少了延迟。
-
调用方式：
- HTTP：通常基于REST架构风格，使用标准的HTTP动词（GET、POST、PUT、DELETE）来表示操作。
- RPC：直接通过方法调用的方式进行通信，使其更像本地调用。接口定义通常通过IDL（接口描述语言）。
-
状态管理：
- HTTP：本质上是无状态的，每个请求独立处理。需要额外的机制（如Cookies、Session）来管理状态。
- RPC：可以设计成支持状态的服务，但具体实现依赖于应用逻辑。
-
安全性：
- HTTP：有成熟的TLS和认证机制，如OAuth，用于保护传输的数据。
- RPC：同样可以使用TLS保护传输过程，但由于使用二进制格式，需要确保数据的完整性和安全性。
总的来说，HTTP适合于一般Web服务开发，具有良好的互操作性和简单性。而RPC则更加高效，适合对性能要求高的内部服务调用。选择哪个技术栈要根据具体的应用场景和需求来决定。
http 1.0和2.0对比
HTTP 1.0和HTTP 2.0在底层实现上有许多显著的区别，主要体现在以下几个方面：
1. 连接管理
-
HTTP 1.0：
- 每个请求/响应需要一个单独的TCP连接。完成后立即关闭。
- 导致高延迟和资源浪费，因为每次请求都需重新建立连接。
-
HTTP 2.0：
- 基于持久连接，一个TCP连接可以处理多个并发的请求/响应对。
- 使用多路复用，可以在同一连接中同时发送和接收多个消息，从而减少了延迟。
2. 数据传输
-
HTTP 1.0：
- 数据以明文的形式（通常是纯文本）传输。
- 无内置压缩机制，头部信息冗长。
-
HTTP 2.0：
- 引入二进制分帧层，将HTTP消息（头部和数据）分解为更小的帧，通过流ID区分不同的数据流。
- 支持头部压缩（HPACK算法），减少开销。
3. 性能优化
-
HTTP 1.0：
- 缺乏原生的性能优化特性。
- 请求排队等待，容易导致"队头阻塞"。
-
HTTP 2.0：
- 多路复用消除了"队头阻塞"，提升了网络资源利用率。
- 允许服务器推送数据到客户端缓存（Server Push），减少延迟。
4. 状态管理
-
HTTP 1.0：
- 基于无状态协议，每次请求独立。
- 需要使用外部机制（如Cookies）来维持会话状态。
-
HTTP 2.0：
- 同样是无状态，但其流式通信模型更适合实时应用。
5. 扩展性和兼容性
-
HTTP 1.0：
- 扩展性有限，缺乏现代Web开发所需的一些功能。
- 大多数功能通过后续的HTTP版本或其它协议扩展支持。
-
HTTP 2.0：
- 向后兼容HTTP 1.x，保持相同的语义。
- 提供了更好的扩展性和灵活性。
总结
HTTP 2.0在性能、效率和现代应用需求的支持上较HTTP 1.0有显著提升，尤其是在减低延迟和提高带宽利用率方面。它通过引入多路复用、头部压缩等技术，使得Web内容加载速度更快，用户体验更好。
protocol buffer是如何体现更紧凑、解析更快
Protocol Buffers（简称Protobuf）是Google开发的一种高效的序列化格式，它通过以下几个方面实现了数据表示更紧凑、解析更快：
1. 二进制格式
- 紧凑性：Protobuf使用二进制格式进行编码，比JSON或XML等文本格式占用更少的空间。因为二进制格式可以直接使用数值而不是字符表示数据，从而减少了存储和传输的数据量。
- 解析速度：二进制格式使得Protobuf在解析时能够直接操作字节数据，而不需要像JSON那样进行字符串解析，这显著提高了解析速度。
2. 字段标识符
- Protobuf使用字段编号而非名称来标识数据字段。这意味着存储时只需保存数字标识符，而不是完整的字段名称，进一步减少了数据大小。
3. 可选字段与默认值
- 在Protobuf中，只需对有值的字段进行编码，不需要发送具有默认值的字段。因此，只包含必要数据的消息会更加小巧。
4. 高效的数据编码
- Protobuf采用了一些高效的编码机制，如变长整数编码（varint），这种编码方式对于小整数特别高效，能有效减少所占用的字节数。
5. 预定义结构
- 编译生成代码：Protobuf通过
.proto文件定义结构，然后生成强类型的代码，这使得数据的序列化和反序列化过程更加优化和快速，因为生成的代码是专门为特定数据结构设计的。
如何设计一个有状态的服务
我们可以构建一个假想场景：在线购物平台中的购物车服务。这个服务需要维护用户的购物车状态，以确保在不同会话中能够持续跟踪用户的购物行为。
案例背景
场景描述
- 用户通过不同设备（如手机、平板、电脑）访问在线购物平台。
- 每个用户有一个购物车，用于存储他们在浏览期间选择的商品。
- 用户可能会在登录后添加商品到购物车，并期望即使在不同设备或网络环境下，也能看到相同的购物车内容。
- 购物车数据需要在服务器端持久化和实时更新，以便在断线重连或系统错误时不丢失数据。
状态管理策略
-
用户会话管理
- Session ID分配：每次用户登录或使用购物车功能时，分配一个唯一的Session ID。
- 身份验证：通过用户ID或OAuth等方式进行身份验证，每个请求都包含Session ID以便进行状态跟踪。
-
持久化存储
- 数据库设计：使用关系型数据库（如MySQL）或NoSQL数据库（如MongoDB）来存储用户购物车的数据，包括用户ID、商品ID、数量、时间戳等信息。
- 数据同步：在用户操作购物车时（如添加、删除商品），立即更新数据库，以保持数据的一致性和持久性。
-
缓存技术
- Redis缓存：利用Redis等内存数据库来缓存活跃用户的购物车数据，提高读写速度。
- 过期策略：设置合理的缓存过期时间，以平衡性能与数据新鲜度。
-
负载均衡与粘性会话
- 使用负载均衡器将请求分发至多个应用服务器，同时启用粘性会话保证用户请求落在同一服务器上，使得临时状态可以在服务器内存中短暂保存。
-
事务管理
- 在涉及库存检查、价格确认等关键操作时，利用数据库事务来确保操作的原子性和一致性。
-
数据同步与消息队列
- 如果购物车服务是微服务架构的一部分，可以使用消息队列（如RabbitMQ或Kafka）在相关服务之间同步购物车状态变化。
-
断线重连与恢复机制
- 实现断线重连功能，允许用户在网络波动后继续其购物流程。
- 提供自动恢复机制，在检测到服务器故障时，将用户会话转移到其他健康服务器实例并恢复状态。
实现细节
- API设计：设计RESTful API或gRPC接口，提供添加、删除商品、查看购物车等功能。
- 安全性：通过HTTPS加密和Token认证确保数据传输的安全性，并防止未经授权的访问。
- 日志与监控：实现详细的日志记录和实时监控，以便快速发现和解决问题。
TLS是如何保证http和rpc传输安全性
它通过以下方式提供安全性：
1. 加密
- 对称加密：TLS使用对称加密来保障数据的机密性。在客户端和服务器之间建立连接后，双方使用协商好的对称密钥进行数据加密。这确保了传输中的数据即使被截获，也无法轻易解读。
2. 身份验证
- 证书与公钥加密：TLS使用数字证书保证服务器的身份真实性。服务器通过一个受信任的CA（证书颁发机构）签名的证书向客户端证明其身份。同时，客户端可以选择要求服务器提供客户端证书以验证客户端身份。
3. 完整性
- 消息认证码（MAC） ：TLS在数据传输中使用MAC来确保数据的完整性。MAC可以检测到任何在传输中对数据的篡改。
4. 握手协议
-
TLS使用握手协议在建立连接时协商加密算法和密钥。这个过程包括：
- 客户端和服务器交换支持的加密算法列表，并协商使用哪种算法。
- 客户端生成一个随机数，并使用服务器的公钥加密该随机数，然后发送给服务器。服务器使用自己的私钥解密该随机数，进而双方根据此随机数生成会话密钥用于对称加密。
5. 前向保密
- 前向保密（Forward Secrecy） ：即便长时间后的密钥泄露，历史通信内容仍然无法被解密。TLS结合临时密钥（如DHE或ECDHE）实现这一特性，使每次会话都有独立的会话密钥。
总结
- HTTPS：通过TLS为HTTP提供安全传输通道，实现HTTP over TLS，即HTTPS。这确保了网页浏览时的安全性。
- 安全的RPC调用：在基于TLS的RPC框架中（如gRPC），TLS确保了远程过程调用的数据安全，防止未经授权的访问或数据泄露。
