UberEats 高级设计

如何解决UberEats 高级设计

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

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

功能要求是：

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

非功能性是：

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

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

我的问题是：

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

这是一个很好的细节水平，还是我必须更深入？

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

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

UberEats High Level Design

解决方法

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

对图表与 HLD 的一般评论

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

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

2. 总是为观众着想——他们需要知道什么？还有你的信息——你想传达什么。考虑这一点将有助于您调整包含的信息以及如何呈现这些信息。

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

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

3. 数据模式对于 HLD 来说看起来不错，但添加关系（连接线）可能很有用。如果它变得过于复杂（连接过多），则可能无法将其与其他所有内容放在同一页面上。

4. 您可能遇到的一个差距是 (API)“[Resources][2]”（[更多关于它们的信息][1]）。 API 的特别是基于 REST 的 API 应该处理资源。您已调出数据模式（数据的存储方式）。资源模型不必很复杂。

• 但正如我所说，您可能不需要拥有一个。如果我正在做一个包含 API 的 HLD，我可能会做一个，特别是如果 API 将被外部 3rd 方使用。

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

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

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

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

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

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

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

2. 你的主图做了两件事——一些元素用功能描述（例如“Rider App”），一些纯技术性的（例如“消息队列”），大多数都有。我更喜欢后者，尽量保持一致。

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

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

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

4. 不要害怕使用一点颜色，如果它有助于提高清晰度。

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