System Design

系统设计，从业务需求开始设计，业务分析，，可行性分析，整体技术架构设计（如何做负载均衡，要不要消息系统，要不要用缓存，用什么存储系统, CAP对业务来说，哪两个更重要，具体有什么方式实现其中的目标），组件设计，服务划分设计，数据分区设计，更细的是，编程级别的设计模式，数据库表的设计。

有个博客说，此类面试is all about communication.

定义问题的Scope 和目标，系统的目标，阐述你的设计逻辑，发散思维，听清楚问题，持续沟通。巧妇难为无米之炊，你还要了解现有的开源产品，设计经验和模式。我的特色？量化式的设计。粗略计算系统特性的能力，PoC的能力，可能属于系统可行性分析。

  • 系统目标，需求分析，用户量有多少，识别出基本的应该用类型，不同的应用类型适用的架构不一样，这个地方自己还不懂。

譬如，监控类应用，搜索应用，电商网站，论坛，社交类应用，产品展示，中介平台类软件。不同的应用类新要求的系统特性不一样，架构也就不一样，架构取舍不一样。还不懂他们具体是什么样的架构区别？

https://www.ibm.com/developerworks/community/blogs/3302cc3b-074e-44da-90b1-5055f1dc0d9c/entry/%E8%A7%A3%E6%9E%90%E5%BE%AE%E6%9C%8D%E5%8A%A1%E6%9E%B6%E6%9E%84_%E4%B8%80_%E4%BB%80%E4%B9%88%E6%98%AF%E5%BE%AE%E6%9C%8D%E5%8A%A1?lang=en 

哪些应用会从微服务收益 ？
记录型系统(System of Record)将从微服务方法中获益最多。例如可将大型应用按相对独立的业务功能分解成若干个微服务实现。
交互型系统(System of Engagement)也将受益于微服务方法，例如渠道应用可以应用“后端服务前端”的模式实现。
分析型系统(System of Insight)则可能对微服务受益不多。其他架构模式如管道及过滤模式可能更适用于分析型系统。
  • 系统限制，系统约束，对一致性的要求是什么程度（最终一致性可否接受），高可用，Partition toleranc?，成本要求。
  • 系统设计：设计逻辑，借鉴类似项目，取舍
  • 系统可行性分析，计算，POC。估算： 速度(CPU, 主存访问速度，网络访问速度）， 字节大小的换算。

划重点：

  • Remember, we’re not looking for mastery of all these topics. We’re looking for familiarity.

  • In other words, the systems design interview is all about communication.

  • 下面也说了如何锻炼这种能力。其中，一个就是看看开源系统OS, Database的设计理念和权衡，为做出这个系统，作者是如何取舍的。Memcached我认为也是一个很好的例子，可以深入挖掘。

五星资料

  • https://github.com/checkcheckzz/system-design-interview

  • 开篇点题：即使你在是著名公司工作过几年的工程师，你的系统设计能力也不见得能非常好，系统设计能力需要阅读大量的书籍和资料，还要有实际项目经验。我要加一条：扎实的计算机理论基础和编程能力。

  • 基本概念和入门

  • 大型互联网公司的技术博客

  • 具体的产品和系统

  • 常见系统设计问题（如设计缓存，设计爬虫，设计搜索，设计图片分享，设计多人在线游戏，。。。）

  • 一些技术书籍

  • WE’RE MEASURING THREE THINGS

Nominally, this interview appears to require knowledge ofsystemsand a knack fordesign—and it does. What makes it interesting, though, and sets it apart from a coding or an algorithms interview, is that whatever solution you come up with during the interview is just a side effect. What we actually care about is the process.

In other words, the systems design interview is all about communication.

This reflects what actually working at Palantir is like. As engineers we have a tremendous amount of freedom. We aren’t asked to implement fully-specced features. Instead we take ownership ofopen-ended problems, and it’s our job to come up with the best solution to each. We need people we can trust to do the right thing without a lot of supervision—people who can own large projects and take them consistently in the right direction. Invariably, this means being able to communicate effectively with the people around you. Working on problems with huge scope isn’t something you can do in a vacuum.

IT’S AN OPEN-ENDED CONVERSATION

Usually we’ll start by asking you to design a system that performs a given task. The prompt will be simple, but don’t be fooled—these problems are wide and bottomless, and the point of the interview is to see how much volume you can cover in 45 minutes.

For the most part, you’ll be steering the conversation. It’s up to you to understand the problem. That might mean asking questions, sketching diagrams on the board, and bouncing ideas off your interviewer. Do you know the constraints? What kind of inputs does your system need to handle? You have to get a sense for the scope of the problem before you start exploring the space of possible solutions. And remember, there is no single right answer to a real-world problem. Everything is a tradeoff.

TOPICS

Systems are complex, and when you’re designing a system you’re grappling with its full complexity. Given this, there are many topics you should be familiar with, such as:

  • Concurrency . Do you understand threads, deadlock, and starvation? Do you know how to parallelize algorithms? Do you understand consistency and coherence?
  • Networking . Do you roughly understand IPC and TCP/IP ? Do you know the difference between throughput and latency, and when each is the relevant factor?
  • Abstraction . You should understand the systems you’re building upon. Do you know roughly how an OS, file system, and database work? Do you know about the various levels of caching in a modern OS?
  • Real-World Performance . You should be familiar with the speed of everything your computer can do, including the relative performance of RAM, disk, SSD and your network.
  • Estimation . Estimation, especially in the form of a back-of-the-envelope calculation, is important because it helps you narrow down the list of possible solutions to only the ones that are feasible. Then you have only a few prototypes or micro-benchmarks to write.
  • Availability and Reliability . Are you thinking about how things can fail, especially in a distributed environment ? Do know how to design a system to cope with network failures? Do you understand durability?

Remember, we’re not looking for mastery of all these topics. We’re looking for familiarity. We just want to make sure you have a good lay of the land, so you know which questions to ask and when to consult an expert.

HOW TO PREPARE

How do you get better at something? If your answer isn’t along the lines of “practice” or “hard work,” then I have a bridge to sell you. Just like you have to write a lot of code to get better at coding and do a lot of drills to get really good at basketball, you’ll need practice to get better at design. Here are some activities that can help:

  • Do mock design sessions . Grab an empty room and a fellow engineer, and ask her to give you a design problem, preferably related to something she’s worked on. Don’t think of it as an interview—just try to come up with the best solution you can. Design interviews are similar to actual design sessions, so getting better at one will make you better at the other.
  • Work on an actual system . Contribute to OSS or build something with a friend. Treat your class projects as more than just academic exercises—actually focus on the architecture and the tradeoffs behind each decision. As with most things, the best way to learn is by doing.
  • Do back-of-the-envelope calculations for something you’re building and then write micro-benchmarks to verify them . If your micro-benchmarks don’t match your back-of-the-envelope numbers, some part of your mental model will have to give, and you’ll learn something in the process.
  • Dig into the performance characteristics of an open source system . For example, take a look at LevelDB . It’s new and clean and small and well-documented. Read about the implementation to understand how it stores its data on disk and how it compacts the data into levels. Ask yourself questions about tradeoffs: which kinds of data and sizes are optimal, and which degrade read/write performance? (Hint: think about random vs. sequential writes.)
  • Learn how databases and operating systems work under the hood. These technologies are not only tools in your belt, but also a great source of design inspiration. If you can think like a DB or an OS and understand how each solves the problems it was designed to solve, you’ll be able to apply that mindset to other systems.

FINAL THOUGHT: RELAX AND BE CREATIVE

The systems design interview can be difficult, but it’s also a place to be creative and to take joy in the imagining of systems unbuilt. If you listen carefully, make sure you fully understand the problem, and then take a clear, straightforward approach to communicating your ideas, you should do fine.

Good luck!

results matching ""

    No results matching ""