caching - 面试分配 - 设计像S3

有几个反馈领域可能会有所帮助：

1。与S3的API比较

S3 API目前是RESTful API（它曾用于支持SOAP），它代表每个文件＆＃39; （实际上是一个由密钥索引的数据块）作为HTTP资源，其中密钥是资源URI中的路径。您的API更多是RPC，因为每个HTTP资源都代表要执行的操作，而blob的关键是参数之一。

这是好事还是坏事取决于你想要实现的目标以及你想采用的建筑风格（虽然我是REST的粉丝，但这并不意味着你拥有然而，由于你被要求设计一个像S3这样的系统，你的答案可以从一个明确的论据中获益，因为你选择不像S3那样使用REST。

架构图往往是非常高的水平 - 这是合适的 - 但有时候有一种趋势是只在框之间划线而不清楚这些线的含义。这是否意味着托管这些软件组件的基础架构之间存在网络连接？这是否意味着这些组件之间存在信息或数据流？

当您在图表中绘制一条线条，其中有多个框在线上连接在一起时，其含义是框之间存在某种关系。当您添加箭头时，更进一步暗示该关系遵循箭头的方向。但是关于这种关系是什么，或者为什么方向性很重要，这一点并不明确。

可以从图中推断出Memcache群集和文件存储群集都在向Metrics / SLA门户发送数据，但他们不会相互发送数据。或者说ELB没有连接到微服务。显然情况并非如此。

一般建筑类型
- 逻辑架构 - 更倾向于关注职能责任领域之间的信息流动
- 物理架构 - 往往更关注可部署的组件，例如服务器，VM，容器，但我也在这里对可安装的软件包进行分组，因为正在运行的可执行进程可以托管多个元素。逻辑架构
特定类型的架构
- 网络架构 - 专注于机器和设备之间的网络连接 - 可能会引用VLAN，IP范围，交换机，路由器等。
- 软件架构 - 专注于软件程序设计的内部结构 - 可以讨论类，模块，软件包等。

您的图表包括负载均衡器（更多物理）以及每个微服务（可以是物理或逻辑或软件）的单独框，其中每个微服务负责不同类型的操作。目前尚不清楚每个微服务是否拥有自己的负载均衡器，或者负载均衡器是否是可以将路径映射到不同前端的第7层均衡器。

虽然体系结构通常关注系统的内部结构，但考虑系统上下文也很重要 - 即系统需要与之交互的系统外部的重要元素是什么？例如什么是预期的客户端及其连接方法？

虽然上述反馈主要集中在沟通方式，但更多的是实际设计。

COTS产品 - 您是否谈到了替代品以及为什么选择了您选择的产品？或者它只是你认识的唯一一个。意识到选择和为特定目的选择适当选项的能力是有价值的。
缓存 - 你在文件存储前面进行缓存，但微服务（边缘缓存或前端反向代理）前面没有任何内容 - 假设微服务正在为进程添加一些值，缓存它们的结果也可能是有用
数据的冗余和持久性 - 当您谈到故障转移的弹性时，数据存储的数据冗余和持久性是这样的关键要求，并且明确提及如何实现这些将是有用的。请注意，这与服务的可用性略有不同。
性能 - 您谈到引入缓存层以提高性能，但不能确定实际性能要求 - 每秒存储或检索的100个对象，1000或数百万？您需要知道要知道要构建的内容
Global Access - S3是一个多区域/多数据中心解决方案 - 您的架构不会引用多数据中心的任何方面，例如存储对象和元数据的复制
安全性 - 您参考了AAA附近的要求，但您提出的解决方案并未定义哪个组件负责安全性，以及请求被验证，接受或拒绝的请求路径中的哪个层或哪个点

为了避免这种批评被认为过于消极，值得一提的是，您的方法中有很多需要 - 您对可能的要求的评估是彻底的，并且很高兴看到包含安全性以及运营监控和预先考虑过。

然而，回顾这一点，我想知道它实际上是什么样的工作 - 它看起来更像是云架构师角色的应用程序，而不是软件架构师角色，我期待它请参阅有关包，模块，程序集，库和软件组件的更多讨论。

尽管如此，它还值得考虑 - 如果面试官在面试中问这个问题，他们会寻找什么？没有人希望你在15分钟内提出一个架构，可以做亚马逊工程师和建筑师团队多年来建立和完善的建议！他们正在寻求思想和表达的清晰度，审查的彻底性，明确假设的逻辑结论，以及行业标准和实践的知识和意识。

希望这对你的工作有所帮助，祝你好运！