[System Design] High Level Workflow

it2023-02-09  45

System Design整个的High Level流程以及需要掌握的知识

4S Analysis

1. Scenario 场景

需要设计哪些功能,有哪些用例,有多大的访问量等。

2. Service 服务

将整个系统拆分成多个小系统,各司其职。

3. Storage 存储

数据应该如何存储和访问。

4. Scale 升级

遇到瓶颈如何升级,未来可能遇到的问题和解决方案。

Scenario

列出所有需要设计的功能选出核心功能,因为时间太多不可能实现所有功能,优先实现核心功能讨论并发用户/请求的数量 DAU和QPS,假设峰值是average的2-3倍 讨论、计算Read QPS 和 Write QPS QPS = 100 : 自己的笔记本就行 QPS = 1k: 一台服务器 QPS = 1m: 1000台服务器的集群 • 一台 Web Server 约承受量是 1k 的 QPS (考虑到逻辑处理时间以及数据库查询的瓶颈) • 一台 SQL Database 约承受量是 1k 的 QPS(如果 JOIN 和 INDEX query比较多的话,这个值会更小) • 一台 NoSQL Database (Cassandra) 约承受量是 10k 的 QPS • 一台 NoSQL Database (Memcached) 约承受量是 1M 的 QPS

Service

重新过一遍需求,为不同的需求创建不同的Services

合并相同的Service

Service之间怎么交流

常用的Restful API、 RPC (亚马逊里面所有组用的Coral)、UDP (没有handshake区别于TCP)、Socket、Long PollingGraphQL 现在亚麻内部也是大量使用的,不同于RestfulMessage Queue, Amazon基本上用AWS SNS+SQL一起Kafka (Scala为数不多拿的出手的代表之作, 可怜的Scala)

API GateWay 和 Load Balancer的区别要清楚,以及怎么运用到System Design中。

Nginx 可以做API GateWay 也可以做Load Balancer,不要把两者混为一谈。亚马逊里面通常使用AWS的API GateWay 来做API GateWay 或者像我们组老旧的使用内部的OPF。

AWS 的SWF (Simple Work Flow) 也是很常用的在系统架构中。内部组更多的使用的是Herd Workflow。但是这个系统设计一般提不到,比较low level

套路说法,为什么要拆分成一个个service? 分成更多layer更多的services可以更好的独立地scale和configure它们。 并且,尊从single responsibility principle 可以让small team 专注于它们自己的功能,来提高生产力,让它们各自发展的更快。

Storage

细化数据库表

SQL Database

主要是要掌握越来越主流热门的PostgreSQL, 其他的数据库太多用烂了。P和其他数据库很多细节还是有一点不一样, 比如returning来实现last insert id,比如Sequence来自增。不过其他SQL也有序列表来实现自增。AWS里面:RDS, Redshift

NoSQL Database

了解掌握 AWS DynamoDB (典型NoSQL), Google BigTable (NoSQL,加了个时间戳, 相关知识点有Skip List), Microsoft Cosmos (Not only SQL)

Left-Prefix Index Rule 索引注意点,系统设计应该用不到

File System

了解掌握 GFS 和 HDFS, 主要是后者,因为开源

数据存储一定要提Back up 和Replica

怎么用master slave实现Replica? 整理了另外一篇博客。

Table Sharding

Vertical Sharding & Horizontal ShardingConsistency Hash Algorithm 一定要掌握的怎么均匀的分布数据又让系统知道该去哪个地方请求又能方便后面继续scale up

Cache

什么都能用来做Cache,不管是文件,数据库等。一般用的比较多的是Redis,自带分布式锁。以及Memory Cache: LRU和LFU

CDN 其实也是一种缓存, push/pull

Scale

通过前面3个步骤,我们得到了一个可行的方案 work solution,但不是Perfect Solution. 我们需要考虑一些比较Edge Case的情况,比如流量暴增,服务器挂了等。或者某些具体的use case我们可以怎么区别的处理。 Single Point Failure

Horizontal scaling

Load balancers can also help with horizontal scaling

Vertical Scaling

Scaling up a single server on more expensive hardware, called Vertical Scaling.

最新回复(0)