这是一个校园二手交易平台的项目，具备和“咸鱼”类似的功能。它以以DevOps+持续交付+微服务+容器的云原生思想为核心，利用Jenkins+Docker持续集成，具备推荐系统（Spark+Redis+Kafka+MongoDB+Neo4j)，链路追踪系统（阿里巴巴TracingAnalysis），监控系统（百度移动统计），搜索引擎（Elasticsearch集群），后台管理系统（vue+springboot+mybatis+nginx)、图像检索（百度图像检索）等核心功能。集成了手机号码一键登录、商品品牌预测、商品类目识别、文本审核、手机短信等第三方服务。
姓名：甄美 年龄：21 身份：本科生
描述：该学生貌美如花，喜欢购物，常在闲鱼购买二手物品，但被骗过一次后，认为陌生人交易不靠谱。
1.1 场景一（购买二手iPad：一键登陆和模糊搜索）：
小美听说CUG贰货对卖家身份进行了实名认证，并且都是地大在校师生，能够进行面对面交易，这次她不用担心被骗了。
她打开软件后，提示她手机号码一键登陆，或者选择QQ、微信进行第三方登陆，很是方便，瞬间就对软件的好感有所提升。进到主页后，她通过搜索栏搜索“平板”，相关平板的商品信息很快就出现，没有明显的延迟或卡顿发生，她觉得这个平台确实是个靠谱的平台。
1.2场景二（购买二手iPad：优先级排序）**
小美想找一个评价好的卖家，并且商品价格实惠。正好她发现该该页面支持优先级排序，于是她把评价优先设置为了最高优先级，把价格设置为了次优先级。点击确定后，当前页面按照排序的优先级重新显示商品列表，小美倍感满意。
1.3场景三（购买二手iPad：商品信息和“砍一刀”）**
小美选择了第一个商品点击进入查看详情，看到卖家的文字描述和商品图片后，觉得这就是自己想要的宝贝。但是觉得2800的价格略微偏高，在往下继续翻阅时，她果真看到了好几位同学通过“砍一刀”功能开出了自己的理想价格。于是她也点击了砍一刀，并且将自己的理想价格设置为了2500。
1.4 场景四（购买二手iPad：联系卖家）
小美砍价完之后，点击了第二个卖家，但是该卖家的商品图片只拍摄了iPad背面。她想看看完整的商品情况，于是点击了联系卖家，向卖家表达自己想让卖家拍个视频看看的请求，并附带一个可爱的表情。商家看到消息后，向小美拍摄了一段完整的视频，发送给了小美。并且卖家表示，自己马上要毕业了，如果她真心想要，2000出了。小美心动了。
1.5 场景五（购买二手iPad：交易）
于是小美和商家约定在未来城图书馆门口面对面交易。交易完成之后，小美对本次交易感到满意，于是给卖家五星好评和一段文字评价，因此该卖家的在系统中的推荐指数上升了。同时推荐系统记录了本次交易，在小美下次打开app时会优先向她推荐iPad等电子产品相关的设备。
姓名：麦佳 年龄：23 身份：本科生
描述：爱好购入各种物品，用了没多久之后又不想要了，因此经常在二手平台出售各种物品。
2.1 场景一（出售AirPods：评估价格）
小麦想看一下贰货平台上有没有其他卖家出售AirPods，并参考其他卖家的价格确定自己的售价。他使用贰货app的以图搜图功能，拍照识别他手中的AirPods，很快系统就为他展示了所有出售AirPods及其它各种品牌的耳机商品。他通过比较其他卖家的产品成色，确定了自己的AirPods价格。
2.2 场景二（出售AirPods：发布商品）
小麦不假思索的就点击了底部导航栏中间的“+”号按钮，因为他潜意识里认为这里就是发布商品的地方。点击后果然进入了商品发布页面，很符合小麦的心理预期。系统要求小麦选择商品种类，并写了一段商品描述。随后小麦发现可以上传几张照片，以增加售出概率，于是他选择了拍了两张AirPods的照片上传。最终小麦设置了商品价格为800元，并发布商品。
2.3 场景三（出售AirPods：砍价通知）
小麦发布产品后便忙别的去了。到了第二天，他的手机消息栏收到了几条买家的砍价和“我想要”消息通知，他打开app后发现有三位买家分别砍价720、180、680元，一位直接选择了“我想要”，即认可小麦开出的800元。于是小麦选择主动与开价800元的买家进一步沟通。
2.4 场景四（出售AirPods：骚扰屏蔽）
在小麦与理想买家沟通时，开价180的买家发送了大量消息，称他是学生，要求便宜卖给他。小麦实在不想卖给这家伙，谁不是学生啊。小麦选择了屏蔽该同学，于是系统将该同学列入小麦的黑名单，该同学从此无法查看小麦的任何商品信息，也不能给小麦发消息了。
2.5 场景五（出售AirPods：反向评价）
小麦和出价800的同学沟通好后，他们约定在2023年3月6日中午10点在未来城图书馆门口进行见面交易。于是买家提交了订单，并选择了交易日期和时间。小麦收到了订单后，确定了订单信息，同意了买家的下单请求，订单信息在系统形成。同时该AirPods在平台显示为已出售状态，其他买家再无法购买。到了交易日期，小麦提前15分钟到达了图书馆门口，一直等到了10点30，迟迟不见买家的人。于是小麦愤怒之下，申请取消订单，系统判定交易已超时，同意了小麦的请求，并要求小麦对该买家进行评价。小麦对他评价不讲信用，于是系统扣除了该买家一定对信用分，并将小麦对商品恢复了正常出售状态。
姓名：安欣 年龄：28 身份：博士生
描述：安欣是贰货平台的管理员，因为专心科研，头发都白了，他做事总能让人安心。
3.1 场景一（后台管理：事件提醒）
该系统比较智能，很多问题自动监测，不需要管理员每天查看，当出现问题的时候，系统会自动通知管理员。2023年3月6日中午11点，安欣的手机里收到了一封系统的短信，短信告诉他有一个系统事件需要他处理。安欣看到短信后，立刻打开了电脑，登陆进入了管理系统，发现是一名买家发起的申诉。该申诉描述道“我与一个叫麦佳的卖家约定好今天中午10点在图书馆门口进行交易，但是我提前15分钟到了等他，一直等到了10:30，还是没见到他人。期间我给他发了很多消息，他一条都没有回复。最后他还反咬一口，取消了订单，并评价说我不守信用，导致我的信用分被扣了。希望平台能给出一个公正的处理结果，以下是我当时与他的消息截图”。
3.2 场景二（后台管理：记录查询）
安欣看到这样的描述之后很是愤怒，怎么能有这么不要脸的人？但是他内心的责任意识不允许他感情用事，他立马查询了系统里该买家和麦佳的消息记录，发现确实是麦佳在约定时间内杳无音讯，并且反咬一口。
3.3 场景三（后台管理：处理申诉）
为了给这位委屈的买家找回公道，安欣通过管理系统恢复了这位买家的信用分，并且双倍扣除了麦佳的信用分。同时为了让麦佳服气，管理员通过系统消息向麦佳发送处理声明，如有异议可提起上诉，进一步协调。但系统对麦佳的投诉会进行记录，如果被管理员核实了三次以上的违规行为，平台将永久封禁麦佳的账号。并且封号的相关条款在用户一键登陆的页面就会要求用户勾选认可，因此该处罚完全是合规合理的，一切责任均在麦佳。
3.4 场景四（后台管理：广播通知）
为了警示平台其他卖家，安欣通过后台管理系统向全平台广播，呼吁有关方不要搬起石头砸自己的脚，否者扣分、封号，平台说到做到。在安欣发布广播后，平台所有用户都会在消息模块收到系统管理员的消息。
3.5 场景五（后台管理：封号处理）
该事情发生几天后，麦佳虽然知道自己恶人先告状，但是心理难免不爽，主要是因为信用分减少了之后，系统对他的商品推荐度也下降了，买家也不愿意买信用分低的商家的东西。于是麦佳想通过平台发泄一下自己的情绪，他企图通过发布商品的模块漫骂管理员和举报他的买家。但是系统在他的文字里识别到了低俗文字信息，拦截了他的发布，记录了他骂人的证据，并对他进行警告。于是麦佳依旧不依不饶，他企图在其他卖家的商品评论区骂人，再一次被系统拦截并警告。这下麦佳彻底愤怒了，他心生一计，往平台里上传涉恐、色情类图片，然后反手举报该平台，让平台被封禁。可是当他正准备上传一张衣不蔽体的图片时，被系统再次识别到并拦截。这时系统忍无可忍，将麦佳的账号永久封禁，并产生系统消息。当安欣下次登陆时，如果发现是系统误判，则可以恢复麦佳的账号。
姓名：韫维 年龄23 身份： 研究生
描述：小维擅长分析数据，并提出改进方案
4.1 场景一（系统运维：crash分析）
小维日常查看系统运维控制台，发现有一个页面最近频繁抛出异常，这些异常数据都被监控系统捕获并可视化呈现在小维面前。小维根据数据看板发现，最近的新增用户不少，于是猜测这些异常可能是由新用户引发的。因此小维依次查看异常日志的机型、系统信息，发现了这些出错的机型都有一个共同特点：都是安卓9的操作系统。
4.2 场景二（系统运维：热更新）
小维发现问题后，向开发者团队反馈了问题，了解到确实是app的SDK不支持安卓9及以下的版本，这都是19年以前的老机型了。但是为了不损失用户，开发者团队选择在app中加入安卓9的SDK。好在该系统支持热更新，在用户无感知的情况下完成了更新。
4.3 场景三（系统运维：流量分析与负载均衡）
几天后，小维发现系统最近的数据访问层服务器带宽经常占满，因为最近新增的用户实在太多了。于是再次联系开发者团队，反馈问题。幸亏开发者团队早有预料，早在系统开发阶段就集成了nginx和数据库同步组件。因此他们只需要再购买一台服务器，将部分数据流量转移到新服务器上，同时数据同步组件会在夜深人静时完成两台数据库的同步工作，以保证数据的最终一致性。
4.4 场景四（系统运维：用户画像）
经过一段时间时间的运营，小维发现了使用本系统的还是女性偏多，并且发现绝大多数用户喜欢刷推荐的商品列表页面，因为他们在这个页面的停留时间最长。
4.5 场景五（系统运维：广告投放）
小维发现商机来了，于是联系了广告投放商，邀请投放商来投送美妆、服饰类广告。因此推荐的商品列表界面，会在不影响用户体验的情况下，插播一些广告内容。
姓名：艾岛乱 年龄：26 身份：小黑客
描述：学了点网安技术，但是找不到工作，成天在家游手好闲，喜欢对别人的软件搞破坏。
5.1 场景一（搞破坏：SQL注入）
艾岛乱听说某国字号开头的大学生开发了一款校园二手交易平台，于是想来显摆一下自己的数据。首先他就拿出了他的拿手活：SQL注入，但没想到开发团队使用了MyBatis，而底层通过prepareStatement预编译实现类对当前传入的SQL进行了预编译，这样就可以防止SQL注入了。
5.2 场景二（搞破坏：自动化脚本）
艾岛乱一计不成，又施一计。他想到了通过自动化脚本在平台不断的发布空商品，让其他商品被淹没。于是他立刻就开始写自动化脚本，没想到刚打开想通过手机虚拟机启动app就被系统识别到是虚拟环境，直接被系统自己强制关闭了。
5.2 场景三（搞破坏：自动化脚本图像识别版）
这点困难可难不倒艾岛乱，于是他又使用了基于识别的自动化工具AirTest。该工具通过计算机视觉识别对应的按钮，并模拟人的点击行为，达到自动化运行的目的。然而刚发布第二个商品，就被系统提示不能发布同样的商品多次。于是他进一步修改脚本，使每次发布的内容随机生成乱码，可当他发布个时，就被系统限制了发布。因为卖家每日最多发布三个商品。同时在这一天里，他的恶意发布可能会被其他用户通过平台提供的举报功能举报，管理员有足够的时间删除他的发布，并封禁其账号。
5.3 场景四（搞破坏：抓包）
用尽了浑身解数的艾岛乱，决定使出绝招：抓包。他启动抓包工具，试图抓到客户端发往服务器的包。算他厉害，他成功的抓到了一堆包，因为这确实无法避免。然而令他头痛的是，这些包里的内容全部被加密过了，他什么信息都获取不到。
5.3 场景五（搞破坏：D）
最终艾岛乱气急败坏，决定使用DDOS攻击，但由于该平台需要通过手机号码一键登陆，也拦截了模拟器，他又弄不到那么多手机。因此只能通过自动化脚本不断的刷新app，企图让app在不断的数据加载中出现卡死崩溃。但是好在开发者团队设置了缓存机制，已经被加载过的数据会在本地建立缓存，并不会重复向服务器发起请求。几个小时后，看着发烫的手机，和毫发无伤的app，他意识到了大事不妙。于是使用了流量监控软件监控上行下行流量，发现微乎其微。意识到问题的他，又写了一段程序用于删除该app的本地缓存。正当他偷着高兴时，他的访问突然被中断，无法连接到服务器。这下他彻底是服了，心中对开发者团队充满了敬佩。其实这是由于开发者团队使用了阿里云（广告位招租）服务器，自带DDOS预防机制。
客户端：https://github.com/Zhumeng420/CugErHuo
推荐系统：https://github.com/cugzjr/recommend
推荐系统数据访问层：https://github.com/cugzjr/myrecommend
服务端：https://github.com/slhcodes/EHMall
后台管理系统前端：https://github.com/cugzjr/FrontErhuo
后台管理系统后端：https://github.com/cugzjr/BackSystem
手机号码一键登录：号码认证服务 (aliyun.com)
动画库：LottieFiles: Download Free lightweight animations for website & apps.
Okhttp：网络请求框架，用于发起对外部接口的请求。
RxGalleryFinal：图片选择库，用于图片或视频的拍照、裁剪和压缩等。
Spark：分布式计算框架，用于推荐系统中数据的实时处理与计算。
Kafka：分布式消息队列，用于推荐系统中实时计算流量削峰。
MongoDB：文档型数据库，用于存储实时和离线的推荐结果。
ElasticSearch：分布式搜索引擎，用于用户和商品信息的模糊检索。
Docker：应用容器引擎，用于持续集成中软件环境的快速部署与发布。
Jenkins：持续集成工具，用于持续集成中项目编译打包并推送到部署环境。
Neo4j: 高性能的 NoSQL 图数据库，用于存储用户-商品关系等复杂数据。
Log4j：日志记录库，用于记录用户在使用过程中的评分数据。
MySQL：关系型数据库，用于存储用户、商品、交易等信息。
Redis: 基于内存的键值对存储数据库，用于缓存用户头像、商品图片等信息。
Minio：分布式的对象存储系统，用于存储系统中的图片资源。
Nginx：高性能代理服务器，用于反向代理部署后台管理系统和用作虚拟子网网关。
SpringBoot: Spring应用开发的框架，用于搭建后台管理系统的后端。
Vue: 渐进式的 JavaScript 框架，用于搭建后台管理系统的前端。
Canal：数据同步组件，用户Mysql数据库直接的主从同步。
朱萌（[email protected])：主要负责软件架构设计、技术选型、软件过程与项目管理
施立豪([email protected])：主要负责服务端及客户端核心业务的开发，如缓存、对象存储、VPC
朱佳睿([email protected])：主要负责推荐系统的算法设计与开发
唐小莉([email protected])：主要负责客户端即时通信模块及UI的开发、后台管理系统的前端+后端的开发
李柏睿([email protected])：主要负责客户端UI的开发、后台管理系统的前端+后端的开发