职业体检系统 系统框架设计_解决系统设计问题的有效框架

职业体检系统 系统框架设计

In my experience as either a software developer or a mentor for software developers, the buzz word “system design” has been popped up quite frequently. Actually, no matter for real-life software development or software engineering interviews, “system design” is right in the center of the stage. I fully understand the frustrations with the so-called “system design” problems, and I have to be frank that I struggled with them, in either real-life scenarios or interviews, for quite some time in the past. All of these experiences, some rewarding, some humbling, lead me to a journey seeking for a good framework to approach system design challenges in a systematic fashion. Here are some of my thoughts.

以我作为软件开发人员或软件开发人员的指导者的经验，流行语“系统设计”已经经常出现。 实际上，无论是针对现实生活中的软件开发还是软件工程访谈，“系统设计”都是舞台的中心。 我完全理解所谓的“系统设计”问题所带来的挫折感，并且坦率地说，我在过去的相当长的一段时间里，无论是在现实生活中还是在采访中，都在与他们共同奋斗。 所有这些经历，既有收获，也有谦逊，使我进入了一个寻找一个好的框架，以系统的方式应对系统设计挑战的旅程。 这是我的一些想法。

大图景 (The Big Picture)

To start with, let’s talk about some general ideas about designing software systems. Specifically, I noticed three basic things make design-related topics very different from other technical topics.

首先，让我们讨论一些有关设计软件系统的一般想法。 具体来说，我注意到三个基本要素使与设计相关的主题与其他技术主题大不相同。

1. There may be no ultimately perfect design, but multiple sufficiently good solutions. Different engineers may have completely different perspectives, and we need to embrace this diversity. As Shakespeare once said, there are a thousand Hamlets in a thousand people’s eyes.

   最终可能没有完美的设计，但是有多个足够好的解决方案。 不同的工程师可能有完全不同的观点，我们需要拥抱这种多样性。 正如莎士比亚曾经说过的那样， 在一千个人眼中有一千个哈姆雷特 。

2. How you reach the conclusion is far more important than the conclusion itself. While we understand the fact that actions and deliverable results are crucial, the questions raised, the inspirations, and the brainstorms during the discussion further improves the outcome of the design.
   得出结论的方式比结论本身重要得多。 尽管我们理解行动和可交付成果至关重要的事实，但在讨论过程中提出的问题，灵感和头脑风暴进一步改善了设计的结果。
3. Rome wasn’t built in a day. Gathering and understanding all the information for the discussion may require years of experience, so it’s not quite practical to build your design skills just with your adrenaline.
   罗马不是一天建成的。 收集和理解讨论所需的所有信息可能需要多年的经验，因此仅凭肾上腺素来建立设计技能是不切实际的。

Under these observations, there are two types of real challenges when pursuing a design. The first type is on knowing too few of the field knowledge: in order to deliver good design, one has to have a good understanding of multiple perspectives of computer science, especially computer systems. The second type of challenge is on knowing too much: sometimes we know too much and we realized there are too many problems to solve but we don’t know where to start with. We may randomly pick one way to start but easily got distracted. Then, hours of discussions later (or half an hour later, in an interview) we just realized we’ve got distracted and forgot something crucial.

根据这些观察，进行设计时存在两种实际挑战。 第一类是对现场知识了解的太少 ：为了交付良好的设计，必须对计算机科学尤其是计算机系统的多种观点有很好的理解。 第二种挑战是了解太多 ：有时我们了解太多，我们意识到有太多问题需要解决，但我们不知道从哪里开始。 我们可能会随机选择一种开始的方式，但很容易分心。 然后，经过数小时的讨论(或半小时后的采访)，我们才意识到自己已经分心了，忘记了一些关键的内容。

Our model addresses the second type of challenge mentioned above. For the first type of challenge, I recommend starting to build your Rome gradually, so get a great system design reading list and start reading today.

我们的模型解决了上述第二种挑战。 对于第一种挑战，我建议开始逐步构建您的罗马，因此，请获取出色的系统设计阅读清单并立即开始阅读。

接近良好设计的模型 (The Model to Approach a Good Design)

So here comes the fun part. Even though system design problems pose significant challenges to our software development process, both in a real working environment and in interviews, I do notice there are general rules. After summarizing these rules, here is a model I use to approach a great design.

因此，这是有趣的部分。 即使系统设计问题在我们的软件开发过程中构成了巨大的挑战，无论是在实际的工作环境中还是在访谈中，我都注意到其中存在一些通用规则。 总结了这些规则之后，这是我用来进行出色设计的模型。

Specifically, we can approach a good design by considering the Use cases, the Requirements, the Commitment plans, and the System itself. To make it easy to remember, I simply call it “the URCS model”, dedicated to my Ph.D. program at the Computer Science Department, University of Rochester.

具体来说，我们可以通过考虑用例，需求，承诺计划和系统本身来进行良好的设计。 为了易于记忆，我仅将其称为“ URCS模型”，专用于我的博士学位。 罗切斯特大学计算机科学系的程序。

用例 (Use cases)

Understanding the use cases helps us to properly understand how the system works for our users, and how can we leverage some facts to optimize the system according to use cases. In this step, we convert a vague business requirement into a concrete computer software problem. We can start by asking ourselves:

了解用例有助于我们正确地了解系统如何为用户服务，以及如何利用一些事实根据用例优化系统。 在这一步中，我们将模糊的业务需求转换为具体的计算机软件问题。 我们可以从问自己开始：

a. Who are the users of our system?

一个。 谁是我们系统的用户？

b. What is the end to end workflow for each type of user?

b。 每种类型的用户的端到端工作流程是什么？

c. Are there any specific usage patterns? For example, how many readers/writers/admin will be using the system? Who’s frequent? Who’s infrequent?

C。 有没有特定的使用模式？ 例如，将使用多少个读者/作家/管理员？ 谁经常去？ 谁不常见？

After we have a good understanding of the use case side, we transferred our problem completely into a technical world. We can then move forward on the technical side.

在对用例方面有了很好的了解之后，我们将问题完全转移到了技术领域。 然后，我们可以在技术方面前进。

要求 (Requirements)

There are multiple perspectives we need to consider to solidly define our system. This is one of the main parts to approach a good design since we really need to know what we are doing afterward. We can start checking by asking us questions from different perspectives.

我们需要考虑多种角度来牢固地定义我们的系统。 这是进行良好设计的主要部分之一，因为我们确实需要知道以后的工作。 我们可以通过从不同角度向我们提问来开始检查。

a. System Scale

一个。 系统规模

i.User: How many users? How many active users? Qps? How good is the quality of the requests?

i.User：多少个用户？ 有多少活跃用户？ Qps？ 请求的质量如何？

ii. Data: How much data are we generating and storing when the system is running?

ii。 数据：系统运行时，我们会生成和存储多少数据？

b. Latency requirements

b。 延迟要求

i. Shall we deliver an online system or an offline system? What is the expected latency of the system? Micro/Nanoseconds? Milliseconds? Minutes? Hours? Days?

一世。 我们应该提供在线系统还是离线系统？ 系统的预期延迟是多少？ 微秒/纳秒？ 毫秒？ 分钟？ 小时？ 天？

ii. Based on the latency requirement, for disk IOs, are we limited by seeks or throughput? What about network IOs?

ii。 根据延迟要求，对于磁盘IO，我们是否受搜索或吞吐量限制？ 那网络IO呢？

iii. Shall we optimize for average numbers, or 80 percentile, or 99 percentile?

iii。 我们应该优化平均值还是80％或99％？

c. Bandwidth consumptions

C。 带宽消耗

i. Based on the data we will process (covered in item a, ii), will the disk IO or network become the bottleneck?

一世。 根据我们将处理的数据(包含在项目a，ii中)，磁盘IO或网络是否会成为瓶颈？

d. Semantics

d。 语义学

i. Fault tolerance of the system: what if one component goes wrong? What is in-memory? What will we lose?

一世。 系统的容错能力：如果一个组件出现故障怎么办？ 什么是内存中？ 我们将失去什么？

ii. Do we need high availability? If so, decide the HA strategy for each component

ii。 我们需要高可用性吗？ 如果是这样，请确定每个组件的高可用性策略

iii. Do we maintain strong consistency? If so, how do we guarantee this even with network partitions?

iii。 我们保持很强的一致性吗？ 如果是这样，即使有网络分区，我们如何保证呢？

iv. Notice the limitation of the CAP theorem.

iv。 注意CAP定理的局限性。

e. Other potential limitations/upper bounds

e。 其他潜在限制/上限

i. System: the number of nodes? the number of active connections? the number of total network connections (capped by the number of ports, fixed number)?

一世。 系统：节点数？ 活动连接数？ 网络连接总数(由端口数，固定数限制)？

ii. User: upper limit capped by the total population. Can we further cap this? For example, cap by organization sizes, or by their geolocation.

ii。 用户：上限为总人口上限。 我们可以进一步限制吗？ 例如，按组织规模或地理位置限制。

iii. Other requirements: Privacy? Security? Politeness/interference when running the system?

iii。 其他要求：隐私？ 安全？ 运行系统时的礼貌/干扰？

承诺计划 (Commitment plan)

We then need to be sure about how can we get to the designed features. Ideally, all requirements would be satisfied with one batch. However, in the real world, we always need to adjust our plans and expectations due to time and budget limits. Therefore, before we get down to the actual system, we need to think about, from a pure engineering perspective, the steps to get our goal.

然后，我们需要确定如何获得所设计的功能。 理想情况下，一批可以满足所有要求。 但是，在现实世界中，由于时间和预算的限制，我们总是需要调整计划和期望。 因此，在进入实际系统之前，我们需要从纯粹的工程角度考虑实现目标的步骤。

a. What’s our overall strategy? Do we need a quick or sustainable solution? How about our cost limitations?

一个。 我们的总体策略是什么？ 我们需要快速或可持续的解决方案吗？ 我们的成本限制如何？

b. Define the basic feature set for our MVP.

b。 为我们的MVP定义基本功能集。

c. Define our development plan in phases. Initially, we may focus on phase I, but we definitely need to keep future phases in mind.

C。 分阶段定义我们的发展计划。 最初，我们可能专注于第一阶段，但我们绝对需要牢记未来的阶段。

d. Consider our development velocity and risk management strategy. How fast can we reach our goal? When shall we check the progress? And, how to manage the risk if something went wrong during the development process? Is there a Plan B?

d。 考虑我们的发展速度和风险管理策略。 我们能多快达到目标？ 我们什么时候检查进度？ 而且，如果在开发过程中出现问题，如何管理风险？ 有计划B吗？

系统总览 (System overview)

We start with interfaces, define their semantics, define the type of the interfaces: Are they APIs or CLIs, or UI? If APIs, what kind of API shall we proceed with? For example, are they RPCs, or REST? And why?

我们从接口开始，定义它们的语义，定义接口的类型：它们是API还是CLI或UI？ 如果是API，我们应该使用哪种API？ 例如，它们是RPC还是REST？ 又为什么呢

We can then start our design, split up components, and do the drawings. One quick comment here is that our initial design should be the one that satisfies our requirements. I do not recommend a “land and then expand” strategy to gradually discover new bottlenecks that should be covered in our initial requirements. Past engineering and interview experiences taught me hard lessons on that.

然后，我们可以开始设计，拆分组件并进行工程图。 这里的一个简短评论是，我们的初始设计应该是能够满足我们要求的设计。 我不建议采用“先扩张然后再扩张”的策略来逐渐发现我们的初始需求中应涵盖的新瓶颈。 过去的工程和面试经验教会了我一些艰巨的经验。

Once you reached this step, congratulations, you’re on your way to good design!

祝贺您，完成此步骤后，您就可以迈向出色的设计！

最后的想法 (Final Thoughts)

Thank you very much for keep reading until this line. If you felt this is helpful, just don’t forget to add a clap! (This is the first time I use Medium and hopefully this is how things work.) I understand some readers may feel disappointed that this is not THE magical article that suddenly makes you understand all the concepts we mentioned above. However, I hope it serves as a good framework, and starting point, to help you glide through your next design.

非常感谢您继续阅读直到这一行。 如果您觉得这很有用，那就别忘了加掌声！ (这是我第一次使用Medium，希望这是工作方式。)我了解一些读者可能对这不是神奇的文章突然让您理解我们上面提到的所有概念感到失望。 但是，我希望它可以作为一个良好的框架和起点，帮助您顺利进行下一个设计。

All of the contents come from my past experience, so some of them may be wrong (or may even be ridiculous). If you have any comments, critiques, suggestions, or find any mistakes, please do not hesitate to comment inline or send a response. I’m more than happy to connect and discuss.

所有内容均来自我过去的经验，因此其中一些内容可能是错误的(甚至可能是荒谬的)。 如果您有任何意见，评论，建议或发现任何错误，请随时在网上进行评论或发送回复。 我非常乐意联系和讨论。

免责声明 (Disclaimers)

• The model discussed in this post is not intended to be the ultimate solution to system design discussions. It solely serves as an outline, or a starting point, to systematically initiate all related design discussions.

  本文中讨论的模型并非旨在成为系统设计讨论的最终解决方案 。 它仅作为概述或起点 ，以系统地启动所有相关的设计讨论。

• The points in this article only reflect my own view. This article has absolutely NO relationship with any of my previous or future employers. Here let’s limit our discussion to the pure technology side.
  本文中的观点仅反映了我自己的观点。 本文与我以前或将来的任何雇主绝对没有关系。 在这里，让我们将讨论限制在纯技术方面。
• I reserve the right to add new disclaimers.
  我保留添加新免责声明的权利。

翻译自: https://medium.com/swlh/an-efficient-framework-to-approach-system-design-problems-cf058f614a84

职业体检系统 系统框架设计