1、推荐比较好用的跨境外贸电商系统或跨境外贸电商网站？有ERP推荐更好
电商系统可以参考第三方跨境电商ERP系统来辅助管理运营,不妨了解一下跨境壹号EPR系统,不过他们家价格有点小贵, 但是用的人也不少,主要针对大中型跨境卖家,小卖家就用不上了
2、我听我盆友说我那个淘淘的那个Java电商项目不是一般的难，如果对spring，springmvc，
没有什么的，你听的比较夸张
正所谓：世上无难事，只要肯登攀
你说的：spring，你可以看看，他就是一个配置文件xml，主要的特性就是控制反转, 方便管理而已
springmvc，这个就是单独的用他做项目都可以，你可以看一个这样的demo，也是比较简单的。
mybatis，这个就是跟数据库打交道的比较多
其实你不需要一起研究
你可以分开研究，这样化整为零，就简单多了
配置不需要特别高，我的XP系统照样跑的，如果配置高了，还怎么满足客户的需求呢？
如果客户的IE浏览器版本太低？那怎么办？
学项目找工作？
其实面试的时候也是看看你平时会用什么框架，做过什么项目，
你可以说SSH，这个是最流行的
当然有公司会用iBATIS
还有单纯的springmvc
还有些基础知识，理论知识。
3、假设自己是一名电商网站的负责人，请写出网站未来五年的发展规划？
一、小型电商网站的架构
刚从传统软件行业进入到电商企业时，觉得电商网站没有什么技术含量，也没有什么门槛，都是一些现有的东西堆积木似的堆出来罢了。然而，真正进入到这个行业之后，才发现并非如此。有人说过，好的架构，是演化出来的，电商网站的架构也是如此。现在好的电商网站，看似很复杂，很牛逼，其实也是从很小的架构，也是从没什么技术含量开始的。所以，架构的演化过程，就是在技术团队不断追求极致的过程。
今天就来总结小型电商网站的架构演进。一套电商系统最初期的架构，往往会采用一个比较典型的LAMP架构，前端加上Apache/PHP，后端是MySQL。这个算是比较流行的。不过，目前还有一套.net的技术架构，可能大家很少提到。很不幸，我就是在一个.net平台为基础的电商公司。所以，今天也是要总结.net 平台的电商架构。
1技术架构
如何打造一个小而精的电商网站架构
一般初期的电商网站，基本就几个业务子系统：网站前台、商家前台、系统管理后台、App、M站等。业务量也不是很大。所以，MVC + 缓存 + 数据库基本就搞定了。
单就开发效率而言，.net MVC 的技术架构不会比LAMP开发速度慢。所以，一些企业，为了快速推出自己的电商平台，也会采用.net 架构。
2基础架构
如何打造一个小而精的电商网站架构
上图为基础架构层面。这是一个很简单的基础架构。
前端网站和M站，考虑到访问量和系统的可用性，基本会采用分布式部署。通过代理服务器进行请求分发。
其它的业务子系统，像商家前台和管理系统，基本上都是单机或是主从部署。
各个DB ，Redis 服务和文件和图片服务，搜索引擎Solr服务等，采用主从部署。
3详细架构
如何打造一个小而精的电商网站架构
整个系统架构里面，还有一个比较重要的组成部分，那就是监控系统。例如：流量监控、硬件监控、系统性能监控等， 还有就是对某个页面进行监控，设置页面的其中一块进行监控等。它是提高整个平台可用性的一个重要手段。多平台、多个维度的监控，能够确保系统的可用性。一旦出现异常，特别在硬件或者性能方面出现异常，监控系统也能立刻发出警告，这样也好防范于未然。
总而言之，一个好的系统架构应该从扩展性、安全性、性能和可靠性来考虑。罗马不是一天建成的，架构适合就行，可以先行之而后优。通过渐进演化的过程，逐步让系统越来越完善。
二、日志与监控系统的解决方案
监控系统主要用于服务器集群的资源和性能监控，以及应用异常、性能监控、日志管理等多维度的性能监控分析。一个完善的监控系统和日志系统对于一个系统的重要性不必多说。总之，只有实时了解各系统的状态，才能保证各系统的稳定。
如何打造一个小而精的电商网站架构
如上图所示，监控平台监控的范围很广，从服务器性能及资源，到应用系统的监控。每个公司都有特定的平台统一监控的需求及解决方案，但监控平台的任务和作用基本是一致的。
1日志
日志是监视程序运行的一种重要的方式，主要有两个目的：1.bug的及时发现和定位；2.显示程序运行状态。
正确详细的日志记录能够快速的定位问题。同样，通过查看日志，可以看出程序正在做什么，是不是按预期的设计在执行，所以记录下程序的运行状态是必要的。这里将日志分为两种：1.异常日志；2.运行日志。
我们主要是使用log4net，将各个系统的日志，持久化记录到数据库或者文件中，以方便后续的系统异常监控和性能分析。如何集成log4net，这里不多说。
日志记录的几个原则：
日志级别一定要区分清楚，哪些属于error、warning、info等。
记录错误的位置。如果是分层系统，一定要在某个层统一处理，例如我们的MVC架构，都是在各个Action中Catch异常并处理，而业务层和数据库层这些地方的异常，都是Catch到异常后，往上一层抛。
日志信息清晰准确有意义，日志尽量详细点，以方便处理。应该记录相关系统、模块、时间、操作人、堆栈信息等。方便后续处理。
4、电商平台系统有哪些?
1、B2C
适合开展b2c电子商务的销售型企业和个体，通过互联网为消费者提供一个新型的购物环境，b2c网络购物网站建设来减少中间环节从而减低成本和增加效益，这种模式节省了客户和企业的时间和空间，大大提高了交易效率。同时又能有效的控制商场运营的成本，开辟了一个新的销售渠道。
2、B2B
B2B使企业之间的交易减少许多事务性的工作流程和管理 费用，降低了企业经营成本。网络的便利及延伸性使企业扩大了活动范围，企业发展跨地区跨国界更方便，成本低廉。
3、C2C
一套基于PHP+MySQL技术MVC架构开发的Web电子商务程序。C2C电子商务网站程序的主要功能有：采用了缓存更新处理，积木式查询显示，前台HTML模板管理，支持鼠标拖曳排版功能。
C2C电子商务网站管理系统首页商品和店铺的自助推荐功能，支持拍卖及一口价模式，支持在线充值（CHINABANK），支付宝按钮支付，商品支持多图片，多级分类设置，同时拥有虚拟币，用户收费店铺，商品登陆收费，
求购信息平台，新闻发布，广告JS管理，友情链接，交易提醒邮件，交易信用评价，站内短信，信息脏话过滤，后台分权限管理等功能，旨在能为广大网民朋友提供一个网络公平竞价交易的商务平台。
4、O2O
C2C电子商务系统实际上与b2c、b2b有共同之处，O2O核心概念为线上成交线下交易，被运用最为主流的O2O是团购型网站。另一种O2O为线上宣传，线下付款与成交，此项目主要针对大型或必须详细知道产品质量的行业，如大型机械类。
(4)mvc电商扩展资料
电子商务整体结构分为电子商务应用层结构和支持应用实现的基础结构，基础结构包括三个层次和两个支柱。三个层次自下而上分别为网络层、多媒体消息/信息发布层、一般业务服务层，两个支柱分别是技术标准和政策、法规。三个层次之上为各种特定的电子商务应用，可见三个基础层次和两个支柱是电子商务应用的条件。
在网上进行交易，交易双方在空间上是分离的，为保证交易双方进行等价交换，必须提供相应货物配送手段和支付结算手段。货物配送仍然依赖传统物流渠道，对于支付结算既可以利用传统手段，也可以利用先进的网上支付手段。
此外，为保证企业、组织和消费者能够利用数字化沟通渠道，保证交易顺利进行的配送和支付，需要由专门提供这方面服务的中间商参与，即电子商务服务商。
5、JAVA电商开源项目有哪些
这里比较的都是国外的开源项目，备选项目有：
Smilehouse Workspace、Pulse、Shopizer、ofbiz、bigfish、broadleaf
1、Smilehouse Workspace 是一个采用 Java 开发的电子商务应用程序。用来做产品、定案和客户信息管理。（从官网看，更像是一个管理系统）
2、Pulse没有使用spring，使用了hibernate，不清楚V端用了什么，使用的开源列表例如以下
http://pulse.torweg.org/site/Pulsar/en_US.CMS.displayCMS.307./third-party-software-included-with-pulse
3、Shopizer基于spring、Spring Security、hibernate、elasticsearch、Spring MVC、jquery、JBoss Infinispan （更偏向CMS系统。文档常常访问不了。程序不太稳定，网友反映有非常多bug）
https://github.com/shopizer-ecommerce/shopizer/wiki
www.shopizer.com/documentation.html
http://www.shopizer.com/documentation.html#!/?
scrollTo=prepackaged
4、ofbiz类似ESB，要做电商修改比较大，它定义了自己的实体引擎、规则引擎等等，和spring的生态系统不兼容，须要又一次学习（学习曲线比较陡），并且非常多功能和业务对中小企业来说用不上。
5、bigfish是基于ofbiz的电商，实体引擎等是继承自ofbiz，和spring的生态系统不兼容，须要又一次学习
6、broadleaf基于spring、Spring MVC、Spring Security、JPA and Hibernate、Compass andLucene、Quartz、Thymeleaf
除了免费社区版外。它还有收费企业版。
目标是开发企业级商务站点，它提供健壮的数据和服务模型、富client管理平台、以及一些核心电子商务有关的工具。如今已经发展到4.x版本号了。社区也非常活跃，而且也有对应的商业版本号。对于有一定开发能力的中小企业来说，BroadleafCommerce是一个不错的电商平台首选，
6、电商前端架构设计
什么是前端架构
说到架构，很容易拉出一系列的概念知识点，像系统架构、软件架构、框架等等，这些不是今天探讨的重点，大家可以下去百度来理解。架构的本质是什么？其实也是一种管理。通常我们所说的管理，都是指对于任务和人员的管理，而架构管的是机器和代码。比如说，机器的部署属于运维的物理架构，SOA属于服务架构，那么，前端的架构指什么呢？
长期以来，前端所处的位置是比较偏应用层，很薄的一层，而架构又要求深度和广度，所以之前在前端里面做架构，好比在小水塘里游泳，稍微扑腾两下就到处碰壁。但最近这几年来，随着一些列新的技术和概念的出现，前端的范围被大大拓展了，所以这一层逐渐变得大有可为。
单纯从语言的角度来说，html、js、css是最简单最容易上手的开发语言，不考虑模块化、工具、压缩优化，任何人都可以快速上手，完成一两个功能简单的页面。在规模很小的项目中，前端技术要素彼此不会直接产生影响，因此无需架构相关的思考。由于前端语言这种灵活松散的特点，使得前端项目规模在达到一定规模后，工程问题凸显，成为发展瓶颈，原来孤立的技术要素开始彼此产生影响，各种技术要素彼此之间开始出现关联，要用模块化开发，就必须对应某个模块化框架，用这个框架就必须对应某个构建工具，要用这个工具，就必须对应某个包管理工具……这个时候，需要有人从比较高的角度去梳理、寻找适合自己团队的集成解决方案。而这一系列解决问题的工具和手段就是所谓的前端架构。
架构的组成
组件框架
架构不等于框架这一点很好理解，相信大家都能够很深入的说明这里的差别，框架是架构的重要组成部分，架构决定框架的选型，框架决定架构的技术路线。架构围绕框架进行一系列的流程工具建设，从而形成完善自动的开发体系。
+框架不等于类库，这里就是很多人困惑的点，你用的什么框架？jquery、underscore、linq、seajs、requirejs等等，每个人都能够列举一大堆。但这个是不准确的，一套编码框架是有一系列的元素组成：
开发模式，我们如何来实现代码的职责分离。以前整个前端是mvc中v这一层，而现在前端内部也进行了mvc的逻辑细分，Javascript的MVC框架现在很多，有的强化m、有的强化c。每一个框架其实都有其特点的，并且有越来越多的创新改造，比如现在最流行的是mvvm。有angular、react等等。我们是为了引入mvvc才把他们纳入到我们的开发体系，而不是因为他是一个好用的类库。
通讯，模块化、组件化是前端在推进开发模式过程中的一个过程产物，为了有效的进行组件隔离和独立，现在有各种各样的通信模型出来，不过由于实现简单，代码少，他往往是合入到某个类库里面，但本质也是一个类库。比较成熟的比如：消息总线、事件模拟、缓存中转、flux模型等等。
模板，我们用什么样的方式来集中的处理数据往html的转换过程，这里就不用多展开，这种类库现在太多了，光我们公司就有很多套，大家在代码行、缓存管理、预编译、运算性能、强大的语法等等各个维度不段追求各种极致。
基础类库 最后才是传统类库，相信现在已经没有同学会在项目中去约束团队中的dom操作、常用函数、方法、异步化等等各种很基础东西，这个时候我们一般就是引入jq、zepto、underscor这些封装好的东西就行了。核心就是为了改善编码生产力。
对于框架的选型要从两面看，一是看该框架的本领，二是看你们团队的能耐。从经验上给几个点建议：
这里也可以顺便展开聊一下现在前端产品的形态分类：
从这些分类里面，我们这些年派生出了所谓全端和全栈的概念。但本质上怎么走还是要由所在产品的形态来决定。
内容型Web站点 侧重渲染方面的优化，前端逻辑比重小
操作型B/S系统 以数据和逻辑为中心，界面较规整
hybrid内置型，要处理缓存和一些本地接口，包括PC客户端和移动端。现在的本地应用，基于很多考虑，都变成了混合应用，也就是说，开发这个应用的技术，既包含原生的代码，也包含了嵌入的HTML5代码
Web游戏，前端的逻辑非常重，在代码结构上要求非常高的可管理性和更复杂的设计模式。
桌面应用型，现在有一些PC端的混合应用开发技术，比如node-webkit和hex，前者的典型应用是XDK，后者的典型应用是有道词典，此外，豌豆荚的PC客户端也是采用类似技术的，也有一些产品是用的qt-webkit。这类技术可以方便做跨平台，极大减少开发工作量。
大工程应该尽量避开谷歌产品，他的很多技术开源项目都是玩票性质的，GWT、Closure、Darty就是前车之鉴。曾今提出过很多的新技术，到现在还是独家的，变出太大。包括现在angular，喜欢做断崖式升级，做做运营后台系统问题不大，如果是线上系统的话，每次升级就是一次人月神话中的典型焦油坑。
关注应用场景，像刚才说到的boss后台是一种；另外我的平台是否有沉重的历史包袱，需要兼容ie6，还是可以轻装上阵；产品对于seo是什么样的态度？是否需要考虑自适应？或者我的团队足够大，能够各搞一套？；产品特征是强内容还是强交互或者是游戏性。这些都是选择不同框架的主要出发点。
没有最好，只有最适合自己的，基本上，针对每个平台，我们都可以列出一些主流框架，但不意味着你们都能驾驭得住。小马过马，老牛没过膝，松鼠淹个半死，就是这么回事。但无论我们选择什么框架或决定自己动手造轮子，都勿忘初心，技术必须让我们工作生活更为轻松愉快——我们只选择我们能驾驭住的框架，我们不能保证它在一年后是否会过时落后。
而且按照我个人这么多年的经验来看，任何框架都会过时，往往不是因为他不够好，而是因为一定有更好的出来。我们再选择一个框架或者一个类库的时候就要想好，未来我如何抛弃他。至少不能成为我们引入新的框架的绊脚石。现实的工作中很多的团队往往会陷入到年复一年的用今年的新框架去重构去年老框架代码的历史循环中去。对于引入框架如何尽量延长他的生命力，我个人的意见是选择框架时去追求概念，而不是潮流，当我的架构可以接受新的设计概念的时候才去考虑引入新的框架。用设计理念的选择代替框架的选择。之所以这么说是因为我观察到我们部门的后端架构的开发理念跟我进公司的时候是差不多的。更多你可以参考成都网站建设