第四周作业一

一个典型的大型互联网应用系统使用了哪些技术方案和手段，主要解决什么问题？请列举描述。



案例：某视频网站的实时观看数或者某新闻网站的点赞数，关注数，如何设计？



1. 需求收集和简化架构

在一开始往往会给出一些很粗糙的需求，所以在给出解决方案之前需要前对需求进行澄清。



• 需求澄清：

• 场景用例：谁用这个系统（网上用户、内部运营团队、第三方广告商）、用户如何用这个系统（主要功能接口有哪些）

• 量级规模（读/写）：每秒查询请求、每个请求查询多少数据量、每秒处理多少个视频观看记录、流量模式是什么？是否有流量高峰？

• 性能：预期从写入到读取数据的延迟（点击观看之后 多久对观看数进行更新，这决定了系统是一个批处理系统还是实时或进实时系统）、预期P99读请求延迟多少（涉及到是不是需要引入缓存）、高可用性（一般都隐含）

• 成本：开发成本有限制、运维成本有限制、开发人员平均水平情况



• 明确API：

• 写入处理的API

• 读取查询的API



• 非功能性需求：高性能、高可用、可扩展，成本和可维护性。



2.存储设计

首先要回答一个存什么的问题？单个事件存储（每次查询要做聚合计算，查询比较慢，存储量也比较大）、聚合数据存储（查询快，存储少，问题是，只能按结果进行查询 ，需实时聚合运算，出错时无法修复），在实际情况中要根据场景需求进行综合判断，折中的办法是单个事件和聚合数据分别存储。



选合适的数据库产品，为什么？以需求，尤其是非功能需求作为数据库选型的依据。Sql，NoSql都可以满足需求。



• SQL方案：

• SQL数据库+客户端嵌入代理模式：数据分区（Sharding，reSharding比较麻烦;Replication复制技术）Mysql主从复制，一主一从，一主二双，数据库访问代理，以客户库形式嵌入到应用程序当中。



• SQL数据库+独立部署代理层：shardingsphere 也支持独立部署代理层模式，在Registry Center,对后台数据库的配置管理，相当于配置中心和服务发现的角色，sharding proxy本身需要高可用部署，所以前置一般需要引入 负载设备来支持。

• 

劣势：传统虽然可以满足需求，但是为了实现可扩展和高可用引入了很多复杂性比如，手工sharding、需要引入主从复制机制，还需要引入数据库访问代理和配置中心这些组件。另外对传统数据库sharding之后，后续要再扩展sharding的话需要手工导数据非常麻烦。为了解决传统数据库这些问题，推出相应的Nosql解决方案。



• NoSQL方案：



Cassandra，开源分布式NoSQL数据库，适合时间序列存储的场景。一致性hash，集群节点之间会定期进行数据交换，相应的协议称为gossip协议，支持最终一致性的数据库，仲裁读/仲裁写（以多数为准），可以了解一个Cassandra的官方文档。



优点：支持按序动态增加节点，可以线性扩展，无须人工干预，原生支持跨数据中心。

缺点：运维复杂性比较高。开发人员少



3.核心服务设计



• 写入服务设计：countingService,用户不能直接写入到消息队列，APIGateway，做路由转发到Countingservice,另外还可以做监控日志，限流容错这些功能



• 查询服务设计：假设视频的每分钟、每小时还有每月、每年的观看量已经通过流式计算或者是后台的批处理运算的方式已经聚合好，并且已经存储到DB中了，当用户查询某个视频观看量的时候，请求先到APIGateway,然后APIGateway将请求转发到QuseryService(查询服务)，查询服务直接查询数据库，并进行简单的聚合计算。计算出到最近一分钟的观看量，就可以将这个结果返回给到这个用户端，这个结果是准实时的，可以满足要求。

• 老数据归档问题（会影响DB性能）注意箭头方向

• 对近期频繁访问的数据要进行缓存操作，进而来提升近期查询的性能（三级缓存架构：分布式缓存、DB、对象存储）



4.技术路线选型：



5.更加有挑战性的问题



• 如何定位系统的性能瓶颈（性能和压力测试：定位程序性能、内存和多线程问题，对核心服务进行性能和压力测试，性能调优；为生产部署进行容量估算，通过测试获取基准数据，从而估算出应对生产环境需要多少的软硬件资源）

• 如何监控系统的健康状况（对系统进行细粒度的埋点和监控，对核心服务的调用量、调用延迟、错误数据进行监控，对硬件资源CPU、内存使用率也要监控起来，如果会用Java语言开发服务，对jvm的垃圾回收等活动也要监控起来，另外由于在系统中引入了很多消息队列，对这些也要监控起来，尤其是消息堆积要监控和告警，这是系统要扩容的一个重要信号，监控手段包括：日志监控、调用链监控、metrics监控，还有健康检查等）

• 如何确保线上系统运行结果正确（对系统进行全面的线下系统测试，但互联网流量变化无常，普通线下测试不能覆盖线上的真实流量，另外有些场景对数据的准确性要求非常高，所以不能有误差。主要做法，一种是开发一套线上模拟程序，定期模拟视频点击事件，写入到生产系统同时也查询生产系统，然后在后台对数据结果进行校验；另一个做法，在实时流计算的基础上，再引入一套线下的批处理系统（hadoop/mp)，两套系统同时做相同计算，然后后台有一套校验系统，对两个系统的结果进行校验，这种做法也要做lambda architecture）

• 如何解决热分区的问题（热点视频，进行系统处理，对视频ID key的部分增加时间截，这样可以把热点视频按时间分摊不同的分区里去）

• 如何监控慢消费者（如何解决慢消费者）



6.扩展设计思想的复用

• 监控系统（对微服务的调用量和错误数据进行计数）

• 欺诈监测系统（对用户近期使用情况计数）

• 限流系统（对IP和ID进行计数）

• 推荐系统（对用户购买和浏览的商品进行计数）

• 今日热点（对头条数据进行计数）