社交产品后端架构设计 (3)

二级缓存(代码级缓存):这是一个实体数据的本地存储,用于提高应用程序的性能。它有助于通过减少昂贵的数据库调用以提高性能,保持实体数据的本地化。EhCache是一个很受欢迎的选择。

客户端缓存:这实际上是设备或浏览器缓存。所有静态项目都应该尽可能地缓存。如果API响应HTTP缓存头已经被合理设置,很多相关资源的内容都会被缓存。我们应确保其如预期的那样工作。除此之外,我们应该尽可能缓存其他内容,可以使用设备自己的内存,或使用SQLite。所有昂贵的对象都应该缓存。例如NSDateFormatter和NSCalendar,初始化缓慢,应该尽可能多的重用。iOS Lot可以调整和应用,但是在这里,它是超出我们的研究范围。

数据压缩

考虑到我们的用户主要是要处理大量的图像和视频,需要下载大量的数据,所以优化下载大小是非常重要的。它将节省用户的数据量,提高应用程序的性能体验。

其他要考虑的方面,如我们的网络,我们的用户主要是在非LTE网络,使用2.5G或3G,需要考虑带宽,并且连接通常是不可靠的,数据使用成本高。在这种情况下,智能压缩是一个关键的需求。

但是实际上图像压缩和视频压缩并不是想象中那么直接简单,往往需要进行深入的分析。我们所处理的图像和视频,可以无损和有损,这取决于用户的设备质量。所以我建议使用多个压缩技术来处理这种情况。在这种情况下,我们可以尝试帧内压缩和帧间压缩技术。

但总的来说我们可以采用zpaq和fp8来应对所有压缩需求。我们也可以尝试非常适合我们业务场景的WebP。一般情况下,我们的API会使用gzip,我们API response总是经过gzip压缩过的。

数据转码

考虑到我们需要处理多个设备,多个操作系统和屏幕分辨率,我们的内容存储和处理时应与设备无关。但服务层应该基于用户的设备,理解并调整响应的内容。所以,图像和视频的转码是必不可少的。

我们的应用程序需要收集设备的配置,如内存、编码和屏幕分辨率,作为API的上下文。我们的API应该使用此上下文来修改/选择内容版本。基于我们接受到的设备上下文,我们可以预先准备好一些最频繁被请求的版本的内容。

我们可以使用FFMPEG转码,FFMPEG是最可靠和应用最广的转码框架。我们可以修改FFMPEG,使其满足我们的需求。转码是在数据输入端完成的。

传输协议

考虑到我们的网络场景(非LTE,不可靠的连接等),关键是要尽可能地节省资源,使通信尽可能地轻量。我建议我们所有的HTTP请求都使用okhttp客户端,okhttp使用SPDY协议,能够弹性处理连接失败,透明恢复。

我们所有的通讯需求,都应该切换到MQTT,这是一个轻量级的机器对机器的连接协议。

安全问题

保证我们应用程序的安全是非常重要的。我们整体架构都要有安全上的考虑。我在这里只谈架构为满足安全要求做出的改变,我们不谈实施过程的改变。

这里是一些必须添加到架构里的:

1. 我们所有的用户数据必须加密。MongoDB和Neo4j已经支持存储加密。在这基础上,我们可以决定加密哪些用户关键信息。所有与数据库相关的传输调用必须启用加密。

2. 安全套接字层:所有代理服务器的访问都应该使用SSLed。代理服务器可以充当SSL终止点。

3. 我们所有的API端点应该运行在非默认端口,并且必须实现OAuth。

4. 所有的DB读取都应该通过Rest endpoints。

5. 有关密码的配置必须特殊处理。密码必须hashed,文件应该被限制只能在应用启动时读取。这允许我们通过文件系统权限来控制应用程序身份实例。只有应用程序用户可以读,但不能写,其他用户不可以读取。所有类似的配置都要用keydb打包并需要密码。

组件

以下是我们架构用到的组件:

1. 负载均衡器:这层是用来转发所有对代理服务器的请求,基于定制的策略。这一层也将有助于我们通过基于容量重定向的方式来保障可用性。

2. 代理服务器:所有即将到来的调用都必须以这里为入口。这也是我们SSL的终止点。它缓存所有基于策略定义的HTTP请求。FE层:该层运行一个node服务器。

3. 数据输入引擎:这个组件涉及所有内容的输入,它做了一系列的工作:非规范化模型,转码,缓存等。将来如果可以的话,所有内容的处理,都可以在这里完成。

4. Rest服务:这层负责与所有DB交互,并返回数据。它的访问是受OAuth保护的。这可以用Tomcat容器以及edge缓存来实现。

5. 事件处理:这层处理所有的事件,主要负责分发的功能。它读取ActiveMQ并使用通知引擎生成通知。

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/zzszfj.html