社区App技术架构
Last updated
Last updated
社区App考虑使用的是典型的前后端分离架构，并且实际上这类社区App已经有了充足的开源项目可供参考。此处描述其大致的技术架构以便后续的开发和实现。比较值得考量的是，由于此刻我们没有过多部署运维的经验，我们所有组件准备全部托管给云，并且极力地降低成本，像是引入云函数替代云服务器，挂载CFS替代文件系统等，这样子可以极力地减少对扩缩容、负载均衡的考量，在低流量的情况下按资源收费可能是个比云服务器+自己使用容器化技术部署组件更可靠的解决方案。同时的，在技术力不足的情况下，这样的设计可能更能保证程序的鲁棒性，毕竟云厂商能够一定程度上保障容灾和多活能力。同时，即使这个架构导致成本增加/难以实现等问题，我们也可以快速采用比较典型的云服务器部署的策略。
当然，我们的首要目标是快速实现图像保护和处理技术并且能在有效性验证后快速开放接口提供服务。图像处理部分理想的情况下是其能够快速且有效地使用我们期望的扰动性对抗、噪声注入和电子水印等方法处理图像并返回结果。这个场景下云函数可能确实是个非常好的选择。
我本人对前端开发并不充分了解，但是在前端应用的选择上，经过调研选择了uni-app作为开发框架，按理说其能够编译到iOS、Android、Web以及各种小程序等多个平台，可以节约Native化的成本。同时也有充足的社区、插件支持。当然此处可能存在多种比如平台兼容性等等的问题，可能需要前辈们提醒和指正。这里的选择不必太过拘泥，如果有合适的开源项目以开源项目技术栈为准。但无论用何种技术栈，前端交互的大致功能预览和逻辑如下:
后端服务使用Flask框架，它的轻量级和易扩展性使得我们能够快速迭代开发，同时也便于我们将服务部署在Serverless Cloud Function上，额外的也是考量到Python的图像处理库比较完备。在云函数的架构下，可以通过类似于云流水线、函数组合等的方式完成业务后端和图像处理模块间的微服务拆分，图像处理资源需求和耗时较大的情况下也可以通过消息队列将其作为一个异步任务。日志等系统可以存储于挂载CFS。业务后端与DB、对象存储、Elasticsearch交互完成图片发布，搜索等功能的闭环。如下为后端业务树：
数据存储策略包括两部分，一部分是存储用户信息的MySQL数据库，一部分是存储用户图片的对象存储服务。通常的，DB用于保存用户信息，对象存储则用于保存用户发布的图片等。同时标签、存储路径等应当同步至ES以提供搜索服务。
图像反AI模块通过对图像加入数字水印、对抗性扰动、注入噪声等方式，保护图像版权，并防止AI进行无授权学习。这个模块应该被设计为一个独立的微服务模块，并且前期能够尽快独立地提供服务。参考云函数部署的模式。当然，对于该方面技术，仍然需要优先进行调研、有效性测试后进行。
考虑到当前需求为低成本，使用场景为低并发。决定为项目设计基于SCF（Serverless Cloud Function，云函数）挂载CFS（Cloud File Storage）的基础部署方式以减少性能浪费。同时当前的SCF技术兼顾了低成本，并发控制，平滑扩缩容以及和数据库、对象存储交互的能力，理应能满足服务的基础运行。后期如果有必要可以上K8S等。
