系统设计

如何把握复杂系统

• https://medium.com/@cwodtke/five-models-for-making-sense-of-complex-systems-134be897b6b3
• https://yq.aliyun.com/articles/72212 把握复杂系统的五种常用模型。无论是写程序还是架构，都有一定的较为成熟的模型遵守，不然你的系统或者程序就会乱七八糟。

• 常见问题或系统

• 如何设计一个秒杀系统？

• 如何监控集群上每台机器的日志？

• 在线集群中，某台机器的CPU使用率非常高，如何找出原因？ (属于Debug问题)

• 如何设计一个用户在线购物的功能，设计对应的数据库表？

• 如何设计一个大文件的下载功能？

• 如何设计搜索自动补全和提示功能？

• P2P: BitTorrent的设计与实现？

P2P： BitTorrent的设计与实现

• http://web.cs.ucla.edu/classes/cs217/05BitTorrent.pdf

如何设计一个搜索自动补全和提示功能？

• http://www.geeksforgeeks.org/ternary-search-tree/
• http://futurice.com/blog/data-structures-for-fast-autocomplete
• https://www.cs.upc.edu/~ps/downloads/tst/tst.html
• https://shreyaschand.com/blog/2013/01/03/google-autocomplete-api/
• https://www.theatlantic.com/technology/archive/2013/08/how-googles-autocomplete-was-created-invented-born/278991/
• 常见的搜索引擎已经自带这样的功能：ElasticSearch.

如何设计一个秒杀系统？

短时间内的高并发请求。

案例

58同城 (5颗星资料)： http://www.infoq.com/cn/articles/flash-deal-architecture-optimization

• 题目: 秒杀业务架构优化之路

• 从浏览器或者App就开始限流

• 写操作，使用请求队列

• 产能有限，所谓秒杀，东西会相对较少，所以对应数据库的数据量，相对较少，每次只需要将差不多量的请求透到数据库层即可。

微信红包(5颗星资料): http://www.infoq.com/cn/articles/2017hongbao-weixin

• 题目: 百亿级微信红包的高并发资金交易系统设计方案

• 和下面的链家的案例，有类似的解决方案

• 使用了memcached。如果整个服务是在一个JVM里，可以用个Semaphore就可以解决问题。但是，如果拒绝服务，用户拆红包的时候，会显示什么错误？会影响用户体验吗？

1号店的抽奖系统(四颗星资料): http://www.infoq.com/cn/articles/practice-of-yhd-lottery-system-architecture

• 限流，风控

1号店的秒杀排队系统(三颗星资料): http://www.infoq.com/cn/articles/yhd-11-11-queuing-system-design

• 设计的基本理念
• 所谓深入理解业务，才能设计出合适的架构；和写算法一样，只有透彻地理解题目，才能写出最合适的算法。就算是EMC的中端存储系统也是有业务的。
• 削峰，将高峰均摊，以将请求量限制在系统的能力范围之内。

链家的抢红包系统(二颗星资料)：http://www.infoq.com/cn/articles/how-to-design-a-small-and-beautiful-spike-system

• 负载均衡

• 降级

• wrk压测

如何监控集群上的日志

核心就是互联网后台中，如何处理大集群，大数据，实时化的这种场景。无非是数据如何更有效地及时地收集、分析和展示出来。

业界也有都现成方案，需要自己学习一下，或者找大牛指引一下方向，有大牛指引提高更快。

• https://www.elastic.co/webinars/introduction-elk-stack
• http://blog.cloudera.com/blog/2015/02/how-to-do-real-time-log-analytics-with-apache-kafka-cloudera-search-and-hue/
• http://www.cnblogs.com/smartloli/p/4581501.html
• http://www.infoq.com/cn/articles/kafka-analysis-part-1.

常常思考系统设计

• 亚马逊的S3挂了 背后的原因是什么？系统设计如何避免？
• Unity的FileSystem挂了？想办法了解背后原因？FS系统本身是不是就比Block难做？还是Cellera产品的历史原因？还是人员变动的问题？公司策略问题？
• Baidu搜索也挂了？是什么原因？
• 12306被骂？你根据这个业务场景设计出你的解决方案吗？
• 秒杀系统？又是如何设计的？
• 开源软件的系统设计，开源软件是为了解决系统中的什么问题？

目标系统的基本要求

• 支持每秒多少次读
• 支持每秒多少次写

系统一些类别

• 实时系统: Uber, 饿了吗
• 电商系统：京东，咸鱼
• 交互型系统： 游戏
• 即时通信系统：微信
• 交易系统：支付宝, 各证券公司的系统, paypal.
• 视频类系统：爱奇艺，直播，短视频, YouTube，喜马拉雅（音频）
• 社交系统：Facebook, 豆瓣，贴吧
• 票务系统：大麦网，格瓦拉，12306
• 点评资讯类系统：大众点评，汽车之家
• 旅游酒店类系统： 携程，去哪儿.
• 知识经验分享类系统： 知乎，百度知道
• O2O类系统：途虎养车, 家政类

研究过的知名公司的业务系统

• Uber(实时):

  • http://highscalability.com/blog/2015/9/14/how-uber-scales-their-real-time-market-platform.html http://www.infoq.com/cn/articles/how-buer-expand-their-real-time-market-platform
  • 系统面临的挑战：实时匹配动态的供应与动态的需求 (matching a dynamic demand with a dynamic supply in realtime)
  • 驱动整个系统的是：那些使用手机的乘客和司机。乘客通过手机发出需求，司机通过手机寻找乘客。所以，后端的核心工作就是与这些手机中端通过Internet做交互
  • 核心功能是只能匹配乘客和司机，乘客更快到家，司机接更多的单。所以，涉及到实时路径规划， 历史信息的计算等等。
  • 行程结束后，可以以异步的方式（消息队列），完成支付，邮件通知，评价等操作。
  • 一个特点是可以按照城市分区。这样才能提高实时性。一般而言，都是城市内。也可以把多个小城市合成一个区。
  • 判断距离远近，可以用现有算法，Google S2 Lib, GeoHash, R Tree. （http://www.jianshu.com/p/3dbaf73a09af, https://hellosmallworld123.wordpress.com/2015/10/02/优步系统设计/）
  • 如判断距离的这种基础设施，是某几家大公司要解决的问题，所谓分工协作，但你要知道有这么个东西，如何使用。
  • 有用户查询，就一定会有索引，汽车地理位置索引，需求地理位置索引。索引如何做？Goolge S2, GeoHash, R tree去做。
  • 基本问题要搞清楚，是道路的距离，而不是直线距离，所以还需要，道路系统已计算道路距离。
  • 主要挑战： 不断移动的汽车，会引起大量的写操作；乘客的客户端的查询（读）也要实时地反映附近车辆的移动状态。因为是实时系统，所以无论是读，还是写，都要求快。还好能通多以城市为例读的分区，降低这个挑战的难度。
  • 读写情况的基本判断：读远多于写的，因为每个打开的手机客户端都在读，但并不是每个打开的客户端都在写。
  • 可扩展性：必须是可扩展的，公司的目标，就是希望更多的用户增加。用户增加后，不需要修改系统，只通过增加计算或者存储资源，就可以抗得住.
  • 一个有意思的结论： 使用一个64位数，地球上的每一平方厘米都可以被表示
  • 实时系统的一个主要特点，所有环节能快则快："ringpop是构建在Uber自己的RPC机制，称为TChannel。特别是在Node和Python中，很多现有的RPC机制工作得并不是很好。想要获取Redis级别的性能.TChannel已经比HTTP快20倍。Uber正在摆脱HTTP和Json业务。TChannel上的所有技术正往Thrift上迁移。"
  • 必须要遵守的设计原则：高可用（不然，不想社交网路，用户很容易可以换成别的打车软件），一切可重试（出错，就重试，设计成幂等可能是最简单的方法，不然，可能更复杂），Make everything killable. （杀死任何进程，不会出现大问题，如何做到？）
  • 问题：在扇出系统中，很小的错误都有一个非常大的影响。一个系统的扇出越高，出现高时延请求的机会就越大。
  • 新概念： 系统的扇出？ 搜索下面的章节。Uber: 在扇出系统中，很小的错误都有一个非常大的影响。一个系统的扇出越高，出现高时延请求的机会就越大。扇出代表依赖的模块多或者调用的服务多，所以延时高的风险大。
  • 问题：Why use Node.js?

• Splunk(数据中心）:

• StackOverflow（问答）:

• Instagram(照片）:

  • http://highscalability.com/blog/2011/12/6/instagram-architecture-14-million-users-terabytes-of-photos.html

• Wechat（即时通信）:

• JD(电商）:

• YouTube(视频):

• 12306(票务):

• 饿了吗(外卖):
• 点评（推荐）：
• 携程(旅游酒店):
• 七牛（CDN):
• 支付宝（交易):
• Paypal:
• Netflix:

研究过的开源系统或产品

• ZeroMQ. 需要从系统设计角度去总结
• 各种NoSQL的设计
• 各种MessgeQueue的设计

系统设计的相关设计能力或技术

• 数据库的表设计
• 面向对象的类设计
• UML图: 序列图, 类图, 流程图, 架构图.

系统设计相关的书籍

• Design Data-Intensive Application (未读，新书2017)
• 大型网站技术架构 (读:1)

软件系统中的扇入与扇出：

在软件设计中，扇入和扇出的概念是指应用程序模块之间的层次调用情况。按照结构化设计方法，一个应用程序是由多个功能相对独立的模块所组成。

• 扇入：是指直接调用该模块的上级模块的个数。扇入大表示模块的复用程度高。
• 扇出：是指该模块直接调用的下级模块的个数。扇出大表示模块的复杂度高，需要控制和协调过多的下级模块；但扇出过小（例如总是1）也不好。扇出过大一般是因为缺乏中间层次，应该适当增加中间层次的模块。扇出太小时可以把下级模块进一步分解成若干个子功能模块，或者合并到它的上级模块中去。

设计良好的软件结构，通常顶层扇出比较大，中间扇出小，底层模块则有大扇入。