架构实战

所谓架构，意即系统架构，广义上它涵盖业务架构、运维架构、组织架构等所有系统构建场景，本文特指一般开发人员主要关注的开发架构。

关于架构的理论有很多，每个人也都有各自的理解，笔者相信很多人在实际运用中也会遇到各种各样的问题和困惑，本文抛开教条，从一个实际项目的演化看何为架构。

项目背景

开始之前，先了解下项目背景。该项目原本是为某东南亚公司开发的图库，提供图片使用授权服务，正规项目。无奈当地营商环境鱼龙混杂，黑白手段层出不穷，有好几个其它项目要么被 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，如此，沉浸在美女频道的管理员就能及时知道有待反馈消息了。