UberEats 高级设计
UberEats High Level Design
我正在为 SDE 3-4 的高级设计面试练习。
我为 UberEats 做了这个设计，我有一些问题。
功能需求为：
- 获取附近餐馆列表
- 从餐厅获取菜肴
- 根据用户位置我们有
计算附近的餐厅
- 获取订单并处理给餐厅
- 可以通过第三方支付
- 餐厅的位置和营业时间
- 跟踪订单状态/通知用户
- 推荐系统
- 与餐厅 OMS 集成
- 送货
- 用户对餐厅的反馈
非功能性是：
- 低延迟
- 高可用性
- 高一致性
- 每天 100 万个订单
- 50 万日活用户
下面放一张我的设计图。
我的问题是：
我必须指定微服务之间的通信类型？
这是一个很好的细节水平，还是我必须更深入？
通知服务部分，我不知道它是否正确我在考虑一个 messageQueue 和 OMS（订单管理系统）将负责将订单更新放入消息队列。
我做了一些研究，但我对这种类型的设计很迷茫，所以欢迎大家提供帮助。
UberEats High Level Design
- 我不熟悉亚马逊的方法以及他们对您需要提供的内容可能有的具体期望。但我可以更笼统地谈谈 HLD 和你的两个具体问题。
对您的图表与 HLD 的一般评论
- 我喜欢您采用的“页面架构”方法，因为您将大量相关信息一起传达 - 而不是将读者淹没在 1,000 页的文档中。
- 您可以改进的一件事是 presentation/layout，以便将信息适当地划分。这将使它更容易消化。粗体标题、分隔线或封闭框/阴影背景面板等
永远为观众着想——他们需要知道什么？还有你的信息——你想传达什么。考虑这一点将帮助您调整包含的信息以及呈现信息的方式。
HLD 是否展示了所问问题的答案？
- 例如：non-functionals：查看您的 HLD，您如何知道它将“高度可用”并且每天有 100 万个订单 - 您知道平均每小时、每分钟有多少吗？并且选择的 components/technology 可以处理这个设计？
HLD 的数据模式看起来不错，但添加关系（连接线）可能会有用。如果它变得太复杂（连接太多），将它与其他所有内容包含在同一页面上可能不可行。
您 可能 的一个差距是 (API)“[资源][2]”（[更多信息请点击此处][1 ]). API 尤其是 REST-based API 应该处理资源。您已经调用了数据模式（数据的存储方式）。资源模型不需要很复杂。
- 但正如我所说，您可能不需要拥有一个。如果我正在做一个包含 API 的 HLD，我可能会做一个，特别是如果 API 将被外部第 3 方使用。
（是否）我必须指定微服务之间的通信类型？
参考我上面的#2。就整个 HLD 而言，简短的回答可能是“是”，但不一定是在一张图表的上下文中。
如果你有很多微服务，尤其是如果它们之间的关系是 non-trivial，那么你可能有两个图表：一个显示所有微服务以及它们之间的关系，一个第二个显示不同的通信类型。
通常微服务之间的通信应该是相对一致的 - 因此您应该能够通过处理微服务类型之间的通信以及任何特殊情况（如果存在）来做到这一点。
第二个“图表”也可以是 table/matrix，其中列出了微服务及其关键信息，例如：external-facing y/n，类型（服务, orchestration 等），它位于哪个业务域等
这是一个很好的细节水平还是我必须更深入？
我无法表达亚马逊的期望，但总的来说，细节水平很好——你可能不想更深入。
您的主图做两件事 - 一些元素用功能描述（例如“Rider App”），一些纯技术（例如“Messaging queue”），大多数用两个都。我更喜欢后者，尽量保持一致。
- 如果我这样做，我可能会有一个功能表示和一个单独的技术表示，因为超过一定程度的复杂性，处理起来可能太多了。
- 看看能不能把图表画得更优雅；这听起来可能很有趣，但是一个优雅且看起来不错的图表可能更容易理解 - 只要您将美学放在远远高于意义的意义之上。
- 这里的一个简单的事情是尝试定位元素，使它们的布局有意义（例如按层或层级）- 这样你就有更少的连接器交叉......当很多连接器 cross-over 看起来很乱时人们通常会翻译 messy = complex。
- 如果有助于清晰，请不要害怕使用一点颜色。
更多详情
[1]: https://www.thoughtworks.com/insights/blog/rest-api-design-resource-modeling
[2]: https://cloud.google.com/apis/design/resources
我正在为 SDE 3-4 的高级设计面试练习。
我为 UberEats 做了这个设计，我有一些问题。
功能需求为：
- 获取附近餐馆列表
- 从餐厅获取菜肴
- 根据用户位置我们有 计算附近的餐厅
- 获取订单并处理给餐厅
- 可以通过第三方支付
- 餐厅的位置和营业时间
- 跟踪订单状态/通知用户
- 推荐系统
- 与餐厅 OMS 集成
- 送货
- 用户对餐厅的反馈
非功能性是：
- 低延迟
- 高可用性
- 高一致性
- 每天 100 万个订单
- 50 万日活用户
下面放一张我的设计图。
我的问题是：
我必须指定微服务之间的通信类型？
这是一个很好的细节水平，还是我必须更深入？
通知服务部分，我不知道它是否正确我在考虑一个 messageQueue 和 OMS（订单管理系统）将负责将订单更新放入消息队列。
我做了一些研究，但我对这种类型的设计很迷茫，所以欢迎大家提供帮助。
UberEats High Level Design
- 我不熟悉亚马逊的方法以及他们对您需要提供的内容可能有的具体期望。但我可以更笼统地谈谈 HLD 和你的两个具体问题。
对您的图表与 HLD 的一般评论
- 我喜欢您采用的“页面架构”方法，因为您将大量相关信息一起传达 - 而不是将读者淹没在 1,000 页的文档中。
- 您可以改进的一件事是 presentation/layout，以便将信息适当地划分。这将使它更容易消化。粗体标题、分隔线或封闭框/阴影背景面板等
永远为观众着想——他们需要知道什么？还有你的信息——你想传达什么。考虑这一点将帮助您调整包含的信息以及呈现信息的方式。
HLD 是否展示了所问问题的答案？
- 例如：non-functionals：查看您的 HLD，您如何知道它将“高度可用”并且每天有 100 万个订单 - 您知道平均每小时、每分钟有多少吗？并且选择的 components/technology 可以处理这个设计？
HLD 的数据模式看起来不错，但添加关系（连接线）可能会有用。如果它变得太复杂（连接太多），将它与其他所有内容包含在同一页面上可能不可行。
您 可能 的一个差距是 (API)“[资源][2]”（[更多信息请点击此处][1 ]). API 尤其是 REST-based API 应该处理资源。您已经调用了数据模式（数据的存储方式）。资源模型不需要很复杂。
- 但正如我所说，您可能不需要拥有一个。如果我正在做一个包含 API 的 HLD，我可能会做一个，特别是如果 API 将被外部第 3 方使用。
（是否）我必须指定微服务之间的通信类型？
参考我上面的#2。就整个 HLD 而言，简短的回答可能是“是”，但不一定是在一张图表的上下文中。
如果你有很多微服务，尤其是如果它们之间的关系是 non-trivial，那么你可能有两个图表：一个显示所有微服务以及它们之间的关系，一个第二个显示不同的通信类型。
通常微服务之间的通信应该是相对一致的 - 因此您应该能够通过处理微服务类型之间的通信以及任何特殊情况（如果存在）来做到这一点。
第二个“图表”也可以是 table/matrix，其中列出了微服务及其关键信息，例如：external-facing y/n，类型（服务, orchestration 等），它位于哪个业务域等
这是一个很好的细节水平还是我必须更深入？
我无法表达亚马逊的期望，但总的来说，细节水平很好——你可能不想更深入。
您的主图做两件事 - 一些元素用功能描述（例如“Rider App”），一些纯技术（例如“Messaging queue”），大多数用两个都。我更喜欢后者，尽量保持一致。
- 如果我这样做，我可能会有一个功能表示和一个单独的技术表示，因为超过一定程度的复杂性，处理起来可能太多了。
- 看看能不能把图表画得更优雅；这听起来可能很有趣，但是一个优雅且看起来不错的图表可能更容易理解 - 只要您将美学放在远远高于意义的意义之上。
- 这里的一个简单的事情是尝试定位元素，使它们的布局有意义（例如按层或层级）- 这样你就有更少的连接器交叉......当很多连接器 cross-over 看起来很乱时人们通常会翻译 messy = complex。
- 如果有助于清晰，请不要害怕使用一点颜色。
更多详情 [1]: https://www.thoughtworks.com/insights/blog/rest-api-design-resource-modeling [2]: https://cloud.google.com/apis/design/resources