一次电商系统搭建过程的分享

最近亲身参与了一次电商系统的架设过程，将整个项目过程整理分享在这里，希望可以帮助到有需要的人。

背景介绍

先介绍一下我们公司：新奥集团，也许有的朋友听过，主要是做能源的，大家见到比较多的是新奥加气站，其实还有太阳能、房产、酒店、旅游业务、家政业务，尤其在廊坊本地是首屈一指的企业，在本地有很多资源。

这个项目的背景是：集团的战略调整，要将上述这些资源进行整合，上线一套电子商务系统，但集团内部其实没有一个专门的电商部门或子公司，于是从各个子公司抽调人手，临时组成的一个团队，不到十个人，高层拍板一个月必须上线😂，咱也不知道领导咋想的，咱也不敢问， 但感觉这是一个不可能完成的任务。

 

抉择：自研还是二开？

项目的起点是围绕着从头自研还是买一套系统二开的讨论开始的，站在技术角度一个月的时间自研明显是来不及的，但领导一度坚持自研，可能他有自主权以及安全性的考量吧，为了说服领导，我们把一个电商的基本模块列了一下：商品、会员、店铺、订单、支付、售后，每个模块功能点都是以百计的，整个系统功能点会是以千计的，10人的团队，一个月，自研这是绝不可能的，何况我们的人除了架构师，都没有什么电商研发经验。

我们还找了几个市面上的现成的电商产品给领导演示，因为电商系统已经是比较成熟的领域了，大部分都是标准化，功能齐全，肯定可以减少大量的工作量的。但采用别人的产品的确存在以下风险：

• 产品是否稳定？如果不稳定，陷入bug中，得不偿失

• 源码是否100%开源，是否在将来受限？

• 源码是别人写的，团队上手难度如何？文档齐全吗？是否可以快速二次开发？

• 厂商支持程度如何？比如bug修复速度？售后响应时间，是否可以提供人力支持

• 我们对产品架构肯定不了解，厂商架构是否可以给予架构支持

 

经过团队详细讨论，虽然采购别的产品二开有上述风险，但自研实在不可能完成，所以还是决定采购产品，领导在看到我们功能的整理以及产品的演示后也最终同意这个案。

 

产品选型

产品的选择的主要过程就是尽量规避上述风险了，我们团队的人员都是java工程师，所以还是要找基于java开发的。我们找了几家供应商：ShopNc,Javashop，ejavashop，朗尊，有的外地的不过来，有的是不提供上门服务😂，有的产品不行（在这里就不说是谁家了，都不容易），最终我们敲定了Javashop，主要基于以下几点：

• 响应很快，当天就来人了

• 产品完善、稳定，基本满足需要

• 代码全部开源

• 提供人力外派

• 提供架构支持

大概介绍一下过程：

初步接触Javashop的人和产品感觉还算靠谱，当天过来销售把基本情况聊了一下，合作意愿很强烈，但销售不太懂技术，无法对项目进行靠谱的评估，第二天又要求他们架构试过来一起评估。

他们架构师了解了我们的需求后，给出的结论是：一个月肯定不能上线（真够实在的，也是为了负责吧😂），主要是我们的酒店、票务、家政等模块要二次开发，接入他们的商品、订单模块，工作量的确很大，但目前市面上没有完全满足我们的产品，没有办法，只能靠我们自己了，当时想的只能是尽力而为了。

但保险起见还是要求他们配合我们做poc测试，我们将自己的场景带入进去，看看到底可不可行，看看产品的稳定度。说实在的这对于厂商来说是有风险的，poc测试的工作量比较大，他们付出的成本也不小，如果Poc测试不通过，相当于他们白干了，但是Javashop同意配合我们做测试，看来他们对于自己的产品还是很有信心的。poc测试过程还算顺利，实物的功能售前售后都可以满足，促销功能比较全，比我们想的还多，最麻烦的还是缺少虚拟商品这块，这也是我们要重点解决的。

 

架构选型：要用微服务吗？

Javashop的产品有两种架构的版本：微服务架构和传统的垂直架构，高层可能为了追赶潮流，要求要用微服务的架构，但我们评估后认为微服务的好处固然很多，但不是银弹，服务发现、服务调用、部署运维都大大增加工作量：

• 开发上服务的依赖增加开发环境的难度，必要服务总要在开发环境保持可用。

• 开发阶段代码更新频率高，被依赖的服务频繁部署，服务与服务之间互相依赖，这要求有完善的开发环境，以及人员熟练的掌握基于服务的开发。

• 联调阶段如果出现bug，追踪bug的难度高于非服务调用方式，因为服务调用的链路复杂。

• 同样的，服务化的部署工作量也比传统的高。

 

另外考量的是javashop的垂直架构的版本也是基于spring boot的，前后端分离，后期如果需要改造为服务化也不是很难，我们还是说服了领导采用了传统的垂直架构，毕竟上线是第一位的，说实话这种项目是否能长久是个问题，集团可能也是要试验，如果业务成功呢了，有技术性的需要再改造服务化才是靠谱的。

 

开工：熟悉代码和架构

开工主要是两件事了：熟悉代码和架构。

代码的熟悉还算顺利，javashop有比较齐全的文档，但我们也没那么多时间看文档，还是叫他们的人给整体培训了，代码没有什么特殊的，都是标准的spring boot的那些东西，前端是vue框架的，我们的人也都熟悉，所以很快也就上手了。

这里还要再次给Javashop的相关人员点赞，我们是集团型的企业，流程上大家都懂，合同比较慢，在合同还没有签署的情况下他们就直接把源码开放给我们，并且他们人员驻场跟我们一起干，这对快速上手帮助很大，信任就是效率啊，如果互相扯皮，不给钱就不干活，那可能就不知要拖到什么时候了，两败俱伤。

同时进行的还有架构，在架构过程中发现我们还是对Javashop了解不够，又请了Javashop的架构师来我们现场，进行了一天闭门会议，把整体架构敲定。

一、抽象出订单中心

1）实物订单以及新的虚拟订单、第三接口都走订单中心

2）要支持虚拟订单流程

二、抽象出支付中心

集团有需要，供其他业务支付使用，工期考虑，放在第二期。

三、抽象出商品中心

主要针对虚拟商品进行改造，以及对接票务。

四、第三方系统对接

1）票务作为商品从接口接入进来。

2）因为工期太紧张，酒店、门票的闸机对接暂时都走人工。

 

上线

架构搞定，任务排好，开发过程就剩下加班了，日夜奋战吧，这个我相信做开发的都深有体会，就不过多分享了，唯一想说的：别太追求技术，上线第一，能上线还有二期，不上线，技术再完美也没用。

最后的结果是一个月上线？是不可能的，最终经过两个月的奋战，项目上线了，还是得到了高层的认可，可能领导也知道一个月不可能完成吧，另一个与是为了给压力吧？无论如何上上下下对系统还是比较满意的，也开始运维了，订单也逐步多起来了。二期也开始策划中，改服务化的要服务化，对接闸机，对接酒店等等。

总结

最后总结一下心得：

• 领导大多不懂技术，要据理力争，选择最适合的方案。

当然我们的目的不是为了自己，而是为了项目更可行，像我们这个项目，如果真像领导说的自研，那可没谱了。后来看了人家的代码，电商系统还是复杂着呢，坑也比较多。

• 一切以业务为主导，而不是以技术为主导。

永远别忘了技术是为业务服务的，咱们搞技术的容易热切的追求新技术，或完美的技术解决方案，但我们真正要做的是以最小的成本（时间成本、人力成本）满足业务的需要。

• 不追求一蹴而就，分期完成

别贪大，小步快跑，上线优先，一些能通过人解决的，先别着急开发，运营跑跑看，业务都通畅了，不差这点技术对接。

• 选择靠谱的厂商

仔细测产品，看人品，看响应。。。也得看运气🤣，当然是在没有腐败的前提下，还好我们绝对不存在，如果你们公司有这个情况，劝你离开吧。。。

• 架构的重要性

还是要选最适合团队的，而不是最流行的。架构一定要前期想清楚想明白，再动手，磨刀不误砍柴工。

• 加班

必须滴么~😂😂😂