架构实战：图片库平台-CSDN博客

本文链接：https://blog.csdn.net/flyTie/article/details/150993703

架构是指系统架构，广义上包含业务架构、运维架构、组织架构等所有系统构建场景。本文主要聚焦开发人员最关注的开发架构。

关于架构的理论众说纷纭，每个人都有不同的理解。在实际应用中，开发者往往会遇到各种问题和困惑。本文摒弃理论教条，通过一个实际项目的演进过程，来探讨架构的本质。

项目背景

让我们先了解一下项目背景。这个项目最初是为一家国外公司开发的图片库平台，主要提供图片授权服务，属于正规商业项目。然而当地市场环境复杂，各种不正当竞争手段频出——多个同类项目接连遭遇DDOS攻击、流量劫持或被恶意植入违规内容，导致该公司损失惨重。最终他们决定高薪聘请专业团队来解决问题。作为专业团队一员的你可能会觉得项目规模不大，但除了核心业务功能外，服务器架构和数据安全防护同样需要重点规划。

基础版

显然，用户浏览网站需要一个site，如果采用前后端分离还得有api-server。

为了防止恶意用户上传违规内容，所有图片都由管理员上传至图床比如AWS-S3（公共读私有写模式）。

S3 同步版

基础版虽然在业务端保证了数据安全，但由于两处服务器（S3、site/api，即红色节点）直接对外暴露，黑客能轻而易举地实现定位进而展开攻击。S3 是可靠的云服务，倒也不用太担心，然而惊弓之鸟的甲方要求管理员不能直接访问 S3，防止黑客嗅探到管理端。

于是，在管理端和 S3 中间新加一个中转节点minio，图片先上传到 minio，再同步给 S3，如此，管理端暴露的风险大大降低。

注意此时还没有解决 site/api 暴露的问题，后面会讲。

会员版

马上新的需求出来了，甲方要求加入收费会员模式，但是不能出现任何关于公司的账户信息（看来甲方真的是怕了，要彻底地隐藏自己）。

要有会员体系，得先有账号模块，为防止恶意注册，加上邮箱验证即可。

收费不能体现公司账号比较麻烦，常规走银行流水肯定不行，第三方甚至套壳支付总是会被追踪到，剩下的选择只有加密货币了，所幸加密货币在当地是被广泛使用的。

加密货币交易一般都是异步的，所以要设计一个定时器，定时从链上获取最新的交易记录，同步给账号中心处理。

图中虚线表示连接的是内部服务。

CMS 版

管理员除管理图片外，还需对网站本身进行管理，比如广告投放、布局调整、会员策略等。于是新增了CMS-Service。

当然以后还会需要其它非 CMS 的站点管理功能比如会员管理、系统监控等，统一以admin-site对管理端提供服务。

CQRS 版

现在，把图片管理一同并入站点管理，并对各服务应用CQRS模式，为以后做读写策略/集群/分布式打下良好基础。

注意，其中 admin-site 兼具 site-command、album-command 职责。

IM 版

为了提升服务质量，甲方老板要求加上在线客服，客户诉求第一时间反馈，同时其它一些消息（比如客户下单、图片合约到期等），管理员也能第一时间收到。

这就不单单是一个即时聊天系统了，还得有消息推送的功能。

再考虑到当地朝九晚五懒散的工作状态，想要管理员一直呆在电脑前也不现实，那么客户消息和系统消息就容易错过。

还好，这里有一个人人都离不开的聊天 App ——Telegram，这玩意儿类似国内的微信，但是开放了很多接口和协议，使第三方系统能方便地接入它。比如我们可以使用它的Telegram-Bot，当客户发送消息时，IM 服务除向管理端实时推送外，还会推送给 Telegram-Bot，Telegram-Bot 再将消息推至 Telegram，如此，沉浸在美女频道的管理员就能及时知道有待反馈消息了。