后面我们会根据具体的互联网业务来了解互联网的工作内容和使用的技术栈，主要讲今日头条。 建议您先体验“今日头条”APP及今日头条后台。 今日头条是作者用来发表文章的账号，类似于微信公众号的后台。 如果你加入了今日头条，你就必须经常使用“今日头条”并安装测试版，即使你不喜欢它。 领导往往闲着没事就刷刷刷刷。 他们上班的时候就刷头条、刷抖音，还挺过瘾的。 刷的时候也很容易发现bug。

为了简单起见，仅选择关键功能和流程进行介绍。 今日头条的模式在很多地方都可以找到，CSDN也基本一致。 CSDN作者在后台发布文章，发布后进行审核。 审核结束后，一些好的文章会被推荐到首页，也可以花钱购买推荐。 当然，大多数CSDN文章仍然被搜索引擎收录。 被收录后，大家搜索关键词的时候就有机会看到。 因为CSDN的用户远比今日头条少，而且更专业，人们不会用CSDN来消磨时间，所以推荐并不是那么重要。

文章阅读与写作的实现

点击今日头条发文章功能，随便输入一些内容。 推荐使用火狐浏览器。 写完内容后，首先按F12打开浏览器的开发者工具进行互联网开发。 浏览器的开发者工具功能非常常用，前端和后端都使用。 后端主要看选项，看看发起了哪些HTTP请求，请求的数据和返回的数据。 然后点击发布文章。 这时可以找到发布文章的界面，如下图：

这个接口是由后端开发工程师开发的，因此后端开发人员也被嘲笑为api工程师。 该接口功能较多，业务逻辑也比较复杂。 例如，检查标题是否足够长，文章中是否有错别字。 这些都是业界提到的业务逻辑，也是大家一直吐槽的。 例如，标题长度的最小和最大范围一开始可能是5-10，但后来有人反馈太短了，就改为5-20。 这种业务逻辑的变化对于技术人员的成长是不利的。 有技术追求的人不能一直只做这种小需求。

你可以想象一下，根据API请求数据，后台会进行哪些数据处理，或者如果要求你这样做，你会如何实现？

这个接口本来就是用框架写的，当然今日头条还是封装的。 使用它的主要原因是开发效率高。 早期，今日头条的大部分服务都是开发的，包括一些PHP。 近年来，情况发生了转变。 新开发的服务被使用，旧的服务被慢慢重构。 入门是慢了一点，但是一旦熟练了，你的开发效率确实会是一样的。 对于今日头条这样大的东西，更换可以节省大量的服务器资源，并且性能更好。

文章发布后后端服务器到底做了什么？ 你可以先自己想一想，就像面试官让你设计面试时你会做什么？ 不用担心做得是否完美，只要把你能想到的要点都写下来，形成一个计划文件即可。 它会是什么样子？

也就是说，假设项目从0开始，老板的需求只有一句话：做一个类似于微信公众号的平台，可以发布文章。 这就是目标，那么下一步就是团队围绕这个目标努力。 为了实现这样的功能，产品经理需要对需求进行细化。 产品经理认为的需求不一定是正确的。 需求也需要讨论，哪些是必须做的，哪些是不能做的，哪些是先做的，哪些是后做的。 讨论之后，建筑师必须进行建筑设计。 如果功能很简单，当然不需要设计，直接写代码。 但看看今日头条的复杂性。 您认为没有技术负责人可以做什么？ 有了方案之后，是不是要开始分工，让低级战士一次一个API去实现呢？

话不多说，回到发帖界面。 普通图文文章的本质就是一些字符串。 文章的章节和字体通过特殊字符来区分，称为富文本。 文章数据传输到后端时是否需要存储？ 应该如何保存？ 磁盘、文件或其他存储？

这就涉及到技术选型。 至于如何选择，则要看功能和性能。

（1）文章可以反复修改，是否需要版本管理？ 更改完成后，不会立即发布。 还有审阅步骤，也可以保存草稿。

(2)一篇文章的访问量可能非常大。 一篇热门文章阅读量十万+、百万+是很常见的事情。 怎么支持这么大的并发呢？

（3）接口是否只支持发布图片和文字？ 是否需要支持视频、音频、图片类型？

（4）除了文章内容之外，文章属性还有很多，比如是否参加过创作者活动、是否有广告等。 如何储存这些？

(5) 还有什么方法可以区分一篇文章？ 用身份证吗？ 文章数量可能是几百、几百亿。 如此大量的文章如何设计ID？ 如何防止不同作者同时发表不同ID的文章？

如果这么细化的话，要做的工作就很多了。 所以，写API是最后一件事，也是最体力的工作。 写之前想清楚，弄清楚需求是什么，有哪些例外，性能要求是什么。 写代码之前想清楚。

今日头条的实现是存储文章属性。 恩，那就对了。 所有文章都存储了，所以初学者会问存储这么多数据性能能跟得上吗？ 这已经用到极致了。 首先，它不是一台机器。 分为数据库和表，读写分离。 其次，表格也很重要。 数据类型和索引都设计得很好。 增删改查不允许交叉。 该表也是一个连接。 文章属性存储，但是文本内容使用kv存储，视频内容使用对象存储。 否则，几十、几百MB的视频仍然是浪费空间。

一些其他属性被保存。 点击作品管理，可以按照分类查看作者的作品。

我可以直接查看这里的文章列表吗？ 如果数据量小的话，肯定是可以的。 如果量很大，那么直接查询压力太大，会导致查询时间较长，而且查询SQL会有点复杂，不适合直接查询。 所以我这里就加一层缓存，在今日头条很少用到。 表中的所有字段数据都不会存储在里面，只会存储ID和这些关键数据，其他读取数据会从其他地方取出。

存储作为非常重要的基础设施，各大厂商都投入了大量的研发。 基本上都是自主开发或者基于开源修改的。 KV存储（key-）是一个大类，属于其中之一，但是太贵了。 是的，因为纯内存，内存比磁盘贵很多。 话又说回来，今日头条是自主研发的，在今日头条的技术公众号上也有介绍。

解决了存储的问题之后，我们再来看看数据是如何流动的。 是直接通过接口写的吗？ 不，小公司没有那么重视。 HTTP接口的功能基本上都是在HTTP服务中完成的，并且也会直接操作HTTP服务。 但在今日头条，却做了区分。 读写数据库等服务不应该在HTTP服务中完成。 而是在中间添加一层RPC服务。 rpc是远程调用，不是HTTP协议。 今日头条使用的协议是开源的，你可以学习一下。

rpc是另一个知识点，除了谷歌的grpc和百度的brpc之外。 那么为什么我们需要在中间添加一层服务呢？ 为什么这个服务是RPC服务而不是HTTP服务？ 加一层服务的目的是安全和统一，因为存储文章的数据库不仅可以通过发文章的接口访问，还可以通过阅读文章的接口访问，头条app也会访问，所以阅读数据库通过专用服务层进行访问。 操作统一，避免重复开发，方便管理。 那么为什么这个中间层不使用HTTP服务呢？ 关于效率，HTTP协议是文本协议，数据没有被压缩，协议头中的一些内容是冗余的。 RPC专门用于公司内部的服务，可以提高效率。 grpc是基于.0实现的。

当然，当暴露大公司的HTTP服务时，必须连接负载均衡。 负载平衡是另一个大话题。 目前的情况简单理解就是文章阅读和写作都是独立的HTTP服务，评论也有独立的HTTP服务，其他业务也有HTTP服务。 为了承受大流量，单个 HTTP 服务将在多个 x86 服务器上运行此 HTTP 进程。 这么多进程必须均衡地向外界提供服务，避免某些进程总是闲着去做某些进程无法完成的事情。 那么就需要负载均衡开源，各大厂商也在基于它制作自己的LB（负载）组件。

上面提到，独立的文章阅读、写作和评论都是独立的HTTP服务。 那么你会好奇为什么不将它们放在一项服务中。 那么即使这两个服务可以放在一起，那么登录注册、交易、提现服务呢？ 全部放在一起会很混乱，上网也会很麻烦。 当注释掉的代码修改上线时，事务修改后没有经过测试的代码也可能会被带上来，并且都放在仓库中。 代码太乱了。 因此，微服务诞生了。 微服务按照各个业务和功能进行拆分，使得各个服务独立，对应的代码库一般也是独立的。 微服务是另一个大知识点。

那么文章读写界面经历的流程大致如下，从上到下看。

现在数据流转的流程已经比较清晰了。 写代码的本质就是处理数据，数据从哪里来，到哪里去，如何处理。 尤其是写API的人首先要了解数据流。 对于数据流，总体架构中有层次。

下一篇文章将介绍如何制作今日头条的统计数据。 。