自营商城架构杂谈

minororange 的个人博客 / 1123 / 19 / 创建于 3年前 / 更新于 3年前

前言

自营商城在技术层面来说是比较简单的系统，难点一般都在业务逻辑，只要业务逻辑理通顺了，技术实现起来并不难。但是做一个可靠的系统还是需要一定的功夫打磨，毕竟再简单的系统如果没有一定的规划与架构，后续维护与扩展也是一个头疼的问题。以下是我从事商城开发一年多的个人经验，分享给大家一起探讨学习。

技术栈架构图

架构图

详细说明

后台

自营商城最开始开发一般都是小团队进行开发，后台不会有前端工程师的参与，我个人非常推荐使用 ElementUI 进行后台开发（原始引入的方式，非打包），后台程序员参考官方文档就能写出很好看的 UI，结合上 Vue 对于一些复杂的表单页面也会比 jQuery 好写很多。

前台

前台是商城的重要组成部分，一般会先由设计部出设计稿，评审通过后再交给前端进行开发。

商城是一个非常需要 SEO 的网站，所以在技术选型上优先考虑使用框架模板引擎作为基础，对于一些不需要 SEO 的页面（购物车，个人中心）可以使用 Vue 渲染。
对于静态资源的引入会涉及到 CDN 缓存的问题，所以使用 Webpack 对静态资源（css,js）进行打包，而后结合 Laravel mix 进行版本更迭。
axios 是替代原有 jQuery ajax 的，他拥有非常完善的请求机制，代码层面也更加语义化。
Promise：商城中会涉及到第三方平台数据上报，有时候部分业务逻辑在前台是异步的，这时候就需要用到 Promise。

服务器

软件

服务器基本架构还是 LNMP，但是对于完善的系统应该还需要一些工具的辅助。

Redis:作为缓存驱动、队列驱动、锁、Session驱动等
Supervisor: 守护队列进程
Shell：切割日志、服务器备份等
ElasticSearch：前台搜索引擎、日志收集等

代码

在传统的 MVC 上，多加一层 service ，用于放置业务逻辑，结合公司实际业务需求也可继续划分。

Middleware: 用于权限校验、日志采集等全局性的逻辑
Job: 不影响主流程的业务逻辑都应该使用队列，例如客户注册成功发送邮件，客户注册是主流程，只要客户注册数据写入数据库成功，就可以跟客户端返回成功，发邮件使用异步进行处理。这样既优化了业务流程，也优化了代码结构
Event: 事件是 Job 的升级版，业务初始逻辑可能是客户注册成功发送邮件，后面产品经理又加需求：客户注册成功要发优惠券，如果去注册逻辑那里再派发个优惠券任务是不是显得不够优雅（~~如果产品经理又双叒叕加逻辑，揍他~~），这时候就可以使用事件来代替了，只用在主流程结束后派发一个事件，然后再给事件定义监听者即可
Exception: 我很少在业务逻辑中看到有人写专门的异常类，但是我十分推荐大家使用异常，每个业务逻辑都应该有自己的异常类，一个方法只有异常跟正常，上层只用放心调用、处理异常就行，不需要关心方法的返回值（返回值必然是成功）

数据库管理

migration 是一个十分符合版本管理的工具，以前使用 SQL 文件进行数据库管理，往往会有数据库跟线上不一致的情况，而且执行起来也麻烦，自从用上了 migration ，一行命令轻松迁移（点一下用一年，超快迁移不要钱），结合上 seed，能够对数据库结构与初始数据进行一个很好的统一。

依赖管理

0202年了，还有人把 vendor 文件夹纳入版本管理（气冷抖）

之前接手一个项目， vendor 文件夹纳入了版本管理，并且更改了框架底层代码（之前程序员说没办法只能改底层，后续出了一堆莫名奇妙的 Bug），说多了都是泪。对于第三方依赖尽量不要去改底层，如果真的是有问题，可以单独拿出来（或者给作者提 issue），一旦更改了第三方依赖，等于说放弃了版本升级、官方 Bug 修复，一切都只能自己来，耗时又费力还不一定搞的好。