需要设计哪些功能,有哪些用例,有多大的访问量等。
将整个系统拆分成多个小系统,各司其职。
数据应该如何存储和访问。
遇到瓶颈如何升级,未来可能遇到的问题和解决方案。
重新过一遍需求,为不同的需求创建不同的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 专注于它们自己的功能,来提高生产力,让它们各自发展的更快。
细化数据库表
SQL Database
主要是要掌握越来越主流热门的PostgreSQL, 其他的数据库太多用烂了。P和其他数据库很多细节还是有一点不一样, 比如returning来实现last insert id,比如Sequence来自增。不过其他SQL也有序列表来实现自增。AWS里面:RDS, RedshiftNoSQL 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 upCache
什么都能用来做Cache,不管是文件,数据库等。一般用的比较多的是Redis,自带分布式锁。以及Memory Cache: LRU和LFUCDN 其实也是一种缓存, push/pull
通过前面3个步骤,我们得到了一个可行的方案 work solution,但不是Perfect Solution. 我们需要考虑一些比较Edge Case的情况,比如流量暴增,服务器挂了等。或者某些具体的use case我们可以怎么区别的处理。 Single Point Failure
Load balancers can also help with horizontal scaling
Scaling up a single server on more expensive hardware, called Vertical Scaling.