面试分配 - 设计像S3这样的系统

Question

在我作为软件架构师的一家金融公司的电话采访中," 设计了像AWS S3这样的云存储系统".

以下是我的回答,请您帮助批评和评论以及我的方法.我想根据您的反馈进行改进.

,我列出了要求 - 对象上的CRUD微服务 - 用于提高性能的缓存层 - 在PaaS上部署 - 具有故障转移的弹性 - AAA支持(授权,审计,计费/计费) - 管理微服务(用户,项目,对象的生命周期,SLA仪表板) - 度量标准集合(Ops,Dev) - 管理UI的服务端点的安全性

我定义了基本的API.
https://api.service.com/services/get Arugments对象id,元数据返回二进制对象 https://api.service.com/services/upload参数对象返回对象id https://api.service.com/services/delete Arugments对象id返回成功/错误 http://api.service.com/service/update-meta Arugments对象id,元数据返回成功/错误

我用架构和我可以使用的一些COTS组件绘制了图片.下面是图片.

面试官没有问我很多问题,因此我有点担心如果我的进程正确.Pl提供您的反馈..

提前致谢..

Answer 1

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

的S3 API是RESTful API这些天(它用来支持SOAP)和它表示每个"文件"(真由密钥索引的数据的二进制大对象)作为HTTP资源,其中关键是在资源的URI的路径.您的API更多是RPC,因为每个HTTP资源代表要执行的操作,并且blob的键是参数之一.

这是好事还是坏事取决于你想要实现的目标以及你想采用的架构风格(虽然我是REST的粉丝,但这并不意味着你必须为所有应用程序采用它)但是,既然你被要求设计一个像S3这样的系统,那么你的答案就会受益于一个明确的论据,即为什么你选择不像S3那样使用REST.

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

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

可以从图中推断出Memcache Cluster和File Storage集群都在向Metrics/SLA门户发送数据,但他们没有向对方发送数据.或者说ELB没有连接到微服务.显然情况并非如此.

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

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

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

虽然上述反馈集中在沟通您的方法上,但这更多是关于实际设计.

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

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

然而,回顾一下,我想知道它实际上是什么样的工作 - 它看起来更像是云架构师角色的应用程序,而不是软件架构师角色,我期望看到更多关于包,模块的讨论,程序集,库和软件组件.

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

希望这对你来说很有帮助,祝你好运!