UberEats 高级设计 [关闭]

Question

我正在为 SDE 3-4 的高级设计面试练习。

我为 UberEats 做了这个设计，但我有一些问题。

功能要求是：

1. 获取附近餐厅列表
2. 从餐厅拿菜
3. 根据我们拥有的用户位置 计算附近的餐厅
4. 获取订单并将其处理到餐厅
5. 可以由第三方付款
6. 餐厅的位置和工作时间
7. 跟踪订单状态/通知用户
8. 推荐系统
9. 与餐厅 OMS 集成
10. 发货
11. 用户对餐厅的反馈

非功能性是：

1. 低延迟
2. 高可用性
3. 高一致性
4. 每天 100 万个订单
5. 50 万日活

我在下面放了一张我的设计图片。

我的问题是：

我必须指定微服务之间的通信类型？

这是一个很好的细节层次还是我必须更深入？

通知服务部分，我不知道是否正确我在考虑一个消息队列，OMS（订单管理系统）将负责将订单更新放入消息队列。

我做了一些研究，但我对这种类型的设计很迷茫，所以欢迎所有帮助。

UberEats High Level Design

Answer 1

• 我不熟悉 Amazon 方法以及他们可能对您需要提供什么的具体期望。但我可以更笼统地谈谈 HLD 和您的两个具体问题。

对图表与 HLD 的一般评论

1. 我喜欢您采用的“页面架构”方法，因为您可以一起传达大量相关信息，而不是让读者淹没在 1000 页的文档中。

• 您可以改进的一件事是显示/布局，以便适当地划分信息。它会更容易消化。粗体标题、分隔线或封闭框/阴影背景面板等。

1. 始终为观众着想——他们需要知道什么？还有你的信息——你想传达什么。考虑这一点将帮助您调整包含的信息以及呈现方式。

2. HLD 是否展示了所提问题的答案？

• 例如：非功能性：查看您的 HLD，您如何知道它将是“高度可用的”和每天 100 万个订单 - 您知道平均每小时、每分钟有多少订单吗？并且所选的组件/技术可以在此设计中处理吗？

1. 对于 HLD，数据架构看起来不错，但添加关系（连接线）可能有用。如果它变得太复杂（连接太多），将它与其他所有内容放在同一页面上可能不可行。

2. 您可能存在的一个差距是 (API)“[Resources][2]”（[在此处了解更多信息][1]）。 API 尤其是基于 REST 的 API 应该处理资源。您已经调用了数据模式（数据的存储方式）。资源模型不需要很复杂。

• 但正如我所说，您可能不需要拥有一个。如果我正在做一个包含 API 的 HLD，我可能会做一个，尤其是当 API 将被外部第三方使用时。

（是否）我必须指定微服务之间的通信类型？

1. 参考我上面的#2。就整个 HLD 而言，简短的回答可能是“是”，但不一定在一个图表的上下文中。

2. 如果您有很多微服务，特别是如果它们之间的关系很重要，那么您可能会有两张图：一张显示所有微服务及其相互关系，另一张显示不同的通信类型。

3. 通常，微服务之间的通信应该是相对一致的——因此您应该能够通过处理微服务类型之间的通信以及任何特殊情况（如果存在）来做到这一点。

4. 第二个“图表”也可以是一个表格/矩阵，列出了微服务及其关键信息，例如：面向外部的 y/n、类型（服务、编排等）、它所在的业务领域、等等

这是一个很好的细节层次还是我必须更深入？

1. 我无法满足亚马逊的期望，但总的来说，细节水平很好 - 你可能不想更深入。

2. 您的主图正在做两件事 - 一些元素用功能描述（例如“Rider App”），一些纯技术（例如“消息队列”），大多数都使用两者。我更喜欢后者，只要尽量保持一致即可。

• 如果我这样做，我可能会有一个功能表示和一个单独的技术表示，因为超过一定程度的复杂性可能会处理得太多。

1. 看看能不能让图表更优雅；这听起来可能很有趣，但一个优雅且看起来不错的图表可能更容易理解 - 只要您将美学置于意义之上，就会失去意义。

• 这里有一个简单的事情是尝试定位元素，以便它们的布局有意义（例如按层或层） - 这样你交叉的连接器就会减少......当很多连接器交叉看起来很乱并且人们经常会翻译混乱 = 复杂。

4. 如果有助于提高清晰度，请不要害怕使用少量颜色。

更多详情 [1]：https://www.thoughtworks.com/insights/blog/rest-api-design-resource-modeling [2]：https://cloud.google.com/apis/design/resources