自营商城架构杂谈

minororange 的个人博客 / 7 / 19 / 创建于 4年前 / 更新于 4年前

前言#

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

技术栈架构图#

架构图

详细说明#

后台#

自营商城最开始开发一般都是小团队进行开发，后台不会有前端工程师的参与，我个人非常推荐使用 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 修复，一切都只能自己来，耗时又费力还不一定搞的好。