服务开发往年题汇总

简答题

2024年

简述RESTful服务开发设计的基本步骤

• 资源分析与设计
• 客户端表述的设计
• 服务端表述的设计
• 暴露资源可执行接口
• 多种资源整合到一起
• 规划服务交互的响应

资源、资源的表述、资源表述状态转移的关系

• 资源：任何寄宿于Web可供操作的“事物”均可视为资源，就其本质而言，任何足够重要并被引用的事物都可以是资源。
• 资源的表述：资源可以具有多种表现形式，这种资源的呈现形式，称作资源的表述
• 资源表述状态转移：REST从资源的角度来观察整个网络，分布在各处的资源由URI确定，而客户端的应用通过HTTP操作来获取资源的表征。REST视角下，互联网就是一个巨大的状态机；REST风格的应用则是从一个状态迁移到下一个状态的状态转移过程

常见HTTP中幂等的操作

• DELETE：执行两次DELETE请求并不比只执行一次造成更多的影响。
• PUT：如果你发送10次同样的PUT请求，请求的结果和你只发1次请求的结果是一样的
• GET：只读操作，请求多少次都不修改服务器资源
• HEAD：与GET类似，但只返回头部

说出至少三个SOA的协议

• 简单对象访问协议（SOAP）
  • 提供了一个标准的封装结构，用来在各种不同的互联网协议（如SMTP、HTTP和FTP）上传输XML文档。通过使用这样的标准消息格式，异构的中间件系统可以实现互操作
• Web服务描述语言（WSDL）
  • 描述了接口，即Web服务支持的一系列标准格式的操作。它标准化了操作的输入和输出参数的表示以及服务的协议绑定，消息在线传输的方式。使用WSDL，不同的客户端可以自动理解如何与Web服务交互
• 通用描述、发现和集成
  • 提供了一种通过搜索名称、标识符、类别或Web服务实现的规范来广告和发现Web服务的全局注册表
• REST

服务怎样实现前后端分离(忘了具体咋说的了)

• 需求分析和架构设计
• API设计
• 开发实施
• 联调与测试
• 部署与运维

为什么要遵循OpenAPI规范

• 定义了一个标准的、语言无关的RESTful API 接口规范
• 正确定义规范文档后，开发者就可以使用最少的实现逻辑来理解远程服务并与之交互
• 此外，借助于文档生成工具，可以使用OpenAPI规范来生成API 文档，代码生成工具可以生成各种编程语言下的服务端和客户端代码，测试代码和其他用例

简述服务在软件互操作中的作用

• 标准化接口：提供统一的API规范，定义数据交换格式（JSON、XML等），建立通信协议标准（HTTP、gRPC等）
• 解耦系统依赖，降低系统间的耦合度
• 支持跨平台
• 增强安全性与可控性
• 实现动态组合与能力复用

无状态性解释

• 所谓“无状态性”，就是对于分布式的应用任意给定的两个服务请求不依赖彼此，处理一次请求所需的全部信息，要么都包含在这个请求里，要么可以从外部获取到（如数据库），服务端本身不存储任何信息。

2023年

面向服务的三种角色和三种操作

• 服务提供者：提供服务实现的一方，即创建、部署并发布服务的一方。
• 服务请求者：需要使用服务的一方，即调用服务来完成特定任务的一方。
• 服务注册中心：一个可选的中间角色，用于服务的发布与发现。
• 发布：服务提供者将服务的描述信息（如 WSDL）发布到服务注册中心，使服务可以被外界发现。
• 发现：服务请求者通过服务注册中心查找符合其需求的服务。
• 绑定：服务请求者根据服务描述信息（如 WSDL），与具体的服务提供者建立连接，并调用其提供的服务操作。

服务在软件互操作的作用

• 标准化接口：提供统一的API规范，定义数据交换格式（JSON、XML等），建立通信协议标准（HTTP、gRPC等）
• 解耦系统依赖，降低系统间的耦合度
• 支持跨平台
• 增强安全性与可控性
• 实现动态组合与能力复用

ROA与RPC的区别

• 面向对象程序的标准设计方法是把系统分解为一个个功能部件——即其中的名词(nouns)。
  • 一个对象(object)是(is)某个事物（如“读者”、“栏目”、“报道”、“评论”等）。
  • 每个名词都有自己的类和自己的方法（用以与其他名词交互）
• 与此形成对比的是，RPC式架构的设计方法是把系统分解为一个个动作，即其中的动词(verbs)。
  • 一个过程(procedure)做(does)某些操作（比如“订阅”、“阅读”、“作评论”等），在面向RPC的分析中，它会被视为将被客户端调用的动作(action)

OpenAPI作用

• 定义了一个标准的、语言无关的RESTful API 接口规范
• 正确定义规范文档后，开发者就可以使用最少的实现逻辑来理解远程服务并与之交互
• 此外，借助于文档生成工具，可以使用OpenAPI规范来生成API 文档，代码生成工具可以生成各种编程语言下的服务端和客户端代码，测试代码和其他用例

HTTP幂等性操作

• DELETE：执行两次DELETE请求并不比只执行一次造成更多的影响。
• PUT：如果你发送10次同样的PUT请求，请求的结果和你只发1次请求的结果是一样的
• GET：只读操作，请求多少次都不修改服务器资源
• HEAD：与GET类似，但只返回头部

Restful服务开发步骤

• 资源分析与设计
• 客户端表述的设计
• 服务端表述的设计
• 暴露资源可执行接口
• 多种资源整合到一起
• 规划服务交互的响应

SOA协议(至少三种)

• 简单对象访问协议（SOAP）
  • 提供了一个标准的封装结构，用来在各种不同的互联网协议（如SMTP、HTTP和FTP）上传输XML文档。通过使用这样的标准消息格式，异构的中间件系统可以实现互操作
• Web服务描述语言（WSDL）
  • 描述了接口，即Web服务支持的一系列标准格式的操作。它标准化了操作的输入和输出参数的表示以及服务的协议绑定，消息在线传输的方式。使用WSDL，不同的客户端可以自动理解如何与Web服务交互
• 通用描述、发现和集成
  • 提供了一种通过搜索名称、标识符、类别或Web服务实现的规范来广告和发现Web服务的全局注册表
• REST

微服务架构的特点(至少两种)

• 服务组件化
• 按业务组织团队
• 做产品的态度
• 轻量化通信机制
• 去中心化治理
• 去中心化管理数据
• 基础设施自动化
• 容错设计
• 演进式设计

2022年

ROA和RPC的区别

• 面向对象程序的标准设计方法是把系统分解为一个个功能部件——即其中的名词(nouns)。
  • 一个对象(object)是(is)某个事物（如“读者”、“栏目”、“报道”、“评论”等）。
  • 每个名词都有自己的类和自己的方法（用以与其他名词交互）
• 与此形成对比的是，RPC式架构的设计方法是把系统分解为一个个动作，即其中的动词(verbs)。
  • 一个过程(procedure)做(does)某些操作（比如“订阅”、“阅读”、“作评论”等），在面向RPC的分析中，它会被视为将被客户端调用的动作(action)

资源、资源的表述、资源表述状态转移的关系

• 资源：任何寄宿于Web可供操作的“事物”均可视为资源，就其本质而言，任何足够重要并被引用的事物都可以是资源。
• 资源的表述：资源可以具有多种表现形式，这种资源的呈现形式，称作资源的表述
• 资源表述状态转移：REST从资源的角度来观察整个网络，分布在各处的资源由URI确定，而客户端的应用通过HTTP操作来获取资源的表征。REST视角下，互联网就是一个巨大的状态机；REST风格的应用则是从一个状态迁移到下一个状态的状态转移过程

HTTP中HEAD的作用

• 轻量级的GET，但只返回头部信息
• 轻量级检查 - 获取元数据而不传输完整内容
• 缓存优化 - 验证缓存有效性
• 性能提升 - 减少不必要的数据传输
• 资源探测 - 检查资源存在性和属性
• 带宽节省 - 特别适用于移动端和慢速网络环境

常见HTTP中安全的操作

• GET、HEAD、OPTIONS
• 这些方法只用来获取信息，不会在服务器上产生副作用

服务开发设计的基本步骤

• 资源分析与设计
• 客户端表述的设计
• 服务端表述的设计
• 暴露资源可执行接口
• 多种资源整合到一起
• 规划服务交互的响应

如何开发前后端分离项目

• 需求分析和架构设计
• API设计
• 开发实施
• 联调与测试
• 部署与运维

OpenAPI有何作用

• 定义了一个标准的、语言无关的RESTful API 接口规范
• 正确定义规范文档后，开发者就可以使用最少的实现逻辑来理解远程服务并与之交互
• 此外，借助于文档生成工具，可以使用OpenAPI规范来生成API 文档，代码生成工具可以生成各种编程语言下的服务端和客户端代码，测试代码和其他用例

微服务设计中的微服务有何特点(至少2个)

• 服务组件化
• 按业务组织团队
• 做产品的态度
• 轻量化通信机制
• 去中心化治理
• 去中心化管理数据
• 基础设施自动化
• 容错设计
• 演进式设计

问答题

在618期间，你的网站可能需要承受十倍的访问量，你作为网站的设计者，你应该怎样设计相关资源，并给出体现的Restful服务设计思想

设计

• 负载均衡：使用负载均衡器（如Nginx、HAProxy）分发请求
• 微服务架构，按业务功能拆分服务
• 通过缓存提升可伸缩性，可以使用一个逆向代理（reverse proxy）来缓存并提供那些频繁访问的资源表述。在架构里增设了Web缓存（逆向代理），再加上有缓存元数据，客户端获取资源时就不会给服务器增添很大负担了
• 弹性扩展：使用云服务（如AWS、Azure或阿里云）提供的自动扩展功能，根据流量动态增加或减少服务器实例。

体现思想

• 资源的抽象与统一：通过URL路径清晰地表示资源，避免混乱。
• 无状态性：保证服务端的扩展性和容错能力，适应高并发场景。
• 可扩展性：通过分布式架构和弹性扩展，满足高流量需求。
• 性能优化：通过缓存、限流等手段，提升服务响应速度。

咖啡厅案例的启示和思想

通过缓存提升可伸缩性

• 作为经营者，其实很不喜欢业务波动，不希望给服务增添负担、或者徒然增加业务流量。
• 为防止服务因过载而崩溃，可以使用一个逆向代理（reverse proxy）来缓存并提供那些频繁访问的资源表述
• 在架构里增设了Web缓存（逆向代理），再加上有缓存元数据，客户端获取资源时就不会给服务器增添很大负担了

无状态性

• 所谓有状态指的是要求在多个异步操作的序列间维持事务资源的一定状态，但这就阻碍了消息的自由传递，因为消息只能向特定服务器传递，系统无法横向扩展，这也就等于损害了可伸缩性
  

异常处理

• 重试
• 补偿：补偿是回退所有已完成的操作，让系统回到一致的状态。例如：退款/重新发货

善用状态码

如何保证安全性

• 对客户端做身份认证和身份鉴权
• 对敏感的数据做加密，并且防止篡改
  • 常见做法：部署SSL(Secure Sockets Layer 安全套接层)基础设施（即HTTPS），敏感数据的传输全部基于SSL；或者仅对部分敏感数据加密，并加入某种随机数作为加密盐，以防数据被篡改
• 身份认证之后的访问控制
  • 主要是由应用来控制。通常应该实现某种基于角色+用户组的授权机制，即基于角色的访问控制（Role-Based Access Control，RBAC）

RESTful服务适用于哪些场景

Web应用后端

• RESTful服务非常适合为Web应用提供后端支持，允许前端通过HTTP请求与后端交互。
• 例子：电商网站的API
  • GET /products：获取商品列表。
  • POST /orders：创建订单。
  • GET /users/{id}：获取用户信息。

物联网（IoT）设备

• IoT设备可以通过RESTful服务与云端通信，上传数据或接收指令。

微服务架构

• 在微服务架构中，服务之间可以通过RESTful API进行通信，保持服务的独立性和解耦。

数据共享与开放平台

• RESTful服务适合用于开放数据平台，供用户或开发者访问共享数据。

设计

• 有一个查询天气的服务。可以查询某地当天的天气情况，包括温度、风速等，也可以查看未来7天一周的天气，用户可以收藏常用的城市，可以在天气情况下进行评论

• （1）要设计什么资源（5分）

• （2）有哪些操作（10分）

（1）要设计的资源

1. 城市：表示用户查询的城市信息，包括城市名称、国家等。
2. 天气：表示某城市的天气信息，包括当天的天气和未来7天的天气预报。
3. 用户：表示使用服务的用户信息，包括用户名、收藏的城市等。
4. 收藏：表示用户收藏的城市列表。
5. 评论：表示用户对某城市天气情况的评论。

（2）有哪些操作

1. 城市资源操作：

   • 查询城市列表：获取支持查询的城市。
   • 查询城市详情：获取某城市的详细信息。

2. 天气资源操作：

   • 查询当天天气：获取某城市当天的天气情况（温度、风速等）。
   • 查询未来7天天气：获取某城市未来7天的天气预报。

3. 用户资源操作：

   • 注册用户：创建新用户。
   • 登录用户：验证用户身份。

4. 收藏资源操作：

   • 添加收藏：将某城市添加到用户的收藏列表。
   • 删除收藏：从用户的收藏列表中移除某城市。
   • 查询收藏：获取用户收藏的城市列表。

5. 评论资源操作：

   • 添加评论：用户对某城市的天气情况进行评论。
   • 删除评论：删除用户的评论。
   • 查询评论：获取某城市的所有评论。