来支持下，顺便问下关于fecshop性能的问题

1.首先，高并发问题，不是一个简单的问题，是一系列的问题，不仅仅是一个程序就能搞定的，程序所做的是更好的支持将来的分布式。

2.对于一个电商网站，更多的压力是在首页，分类，搜索，产品页面，因此，产品，分类，评论，page等都是放到mongodb，mongodb支持高并发读写，而且mongodb的横向扩展也是非常的方便，而对于购物车下单页面，访问的就会比较少，而且这些处理一般涉及到事务，因此，cart coupon order等事务型表放到mysql中。

这种设计可以更高的应付高并发.

3.fecshop提前做了很多架构层次上的处理，譬如：

3.1.图片，js，css采用独立的路径，域名，完全可将图片分离出来放到一个独立的服务器上面，然后通过NFS挂载到各个php中

3.2 session cache等放到redis里面，php横向扩展，部署多个php，session cache公用，这样多php还是比较容易

3.3 程序结构采用懒加载组件和服务模式，用到后才会初始化，更少的减少不需要的php资源的浪费

3.4 fecshop支持php7，php7的性能比php5块将近一倍。

3.5 重构，fecshop毕竟是一个大众化的产品，不可能满足各种情况的需要，但是，fecshop作为一个电商开源框架，更多的做的是在架构层次支持重构，譬如，您可以将产品部分，重构成elasticSearch支持，将订单部分重构成分库分表，因为fecshop有services层，重构起来就比较容易，只要将底层的某个services的方法 全部重构，就可以重构掉这个部分，譬如，我向把cart由原来的保存到mysql改成放到热地是里面，那么我只要重写 cart services里面的所有方法即可完成，通过这种方式，您的网站业务扩大后，重构是相对比较容易的。

3.6 mongodb 可以很方便的做复制集，横向扩展，可以很容易的部署多台。

4 fecshop在本身的优化：

4.1 cache层的加入，有全页缓存，动态数据ajax加载，这样首页，分类，产品页都可以缓存起来，购物车，登录信息可以ajax加载，减少开支

4.2 选择高性能Yii2框架作为支持，稳定，安全。

5 作为一个开源商城，除了性能，还要考虑升级，扩展，协作

5.1 由于商城系统的复杂性，原始的框架MVC结构，显的有点力不从心，Fecshop框架 加入了Block层， Controller层只负责调度， Model只负责数据库映射，中间的处理逻辑由block来完成，View层 负责显示，这样各司其职， 以免造成controller文件过于庞大。

5.2 加入独立功能块，有点类似Yii2的Widget，目的是为了让一些侧栏公用块 可以通过配置的方式 添加，同时，还可以具有设置缓存的功能，譬如侧栏的产品浏览记录， newsletter等独立显示块可能在很多 页面用到，通过独立功能块可以配置方便的载入。

5.3 Fecshop多模板系统，Fecshop设置了多个模板路径，各个模板路径下的文件被加载 的优先级不同，其中，Fecshop的模板路径下的文件最全面，但是优先级最低， ，第三方模板路径优先级其次，用户本地模板路径优先级最高， 用户可以通过 复制相应路径下的view或者js，css文件到本地模板路径，存在于高优先级 模板路径的文件会被优先加载，这样用户可以通过多模板系统的原理进行模板的 制作，同时，不影响Fecshop模板的升级，如果Fecshop view文件升级后被修改， 那么用户可以比对本地模板文件与升级模板文件的代码的不同， 复制更改的代码到本地模板路径 即可。第三方的模板路径的优先级介于本地模板路径和Fecshop 模板路径之间。

5.4 重写机制，Fecshop的功能基本都可以被用户重写，包括servies层，Modules， Controller，Block，Views，View Layout， 以及Js Css Img等，都可以被用户重写，其中 Js，Css，Img，Views，View Layout 是通过多模板 路径优先级来实现的，其他的是通过配置文件的覆盖更改来实现重写，这样，用户 就可以很方便重构Fecshop或者第三方的功能和模板。

5.5 升级最小化干扰，Fecshop的核心文件是放到vendor/fancyecommerce/fecshop 路径下面，和第三方扩展，用户二次开发路径完全隔离开， Fecshop可以通过composer进行核心功能的升级，用户只需要通过composer升级 即可。

5.6 Fecshop 多入口模式，分为 appadmin（后台）， appfront（PC前端），apphtml5（手机web）， appserver（手机app服务），appapi（erp，或者其他接口对接）， 不同的业务，不同的设备，进入不同的入口，各个入口共用服务层services， 但是modules部分独立，这样相互干扰最小，可以相互独立开发。

5.7 后台封装化，fec_admin扩展可以快速的实现增删改查类型的表单列表， 方便用户快速的做增删改查。

总之，作为在电商行业从事7年+，很多性能，扩展，协作的问题都考虑进去，在哲学角度讲，强大意味着复杂，更完美对应的是更多支出（人力，财力），fecshop更多的事情是做一个底层开源框架，做精做好，功能不在于五彩斑斓，使用不在于多么的受小白喜欢，现在的安装基于composer，的确很多的人不习惯，以后会慢慢的考虑这些。

fecshop作为一个BSD开源产品，也存在很多的不足，希望大家多多提意见，每个人都要自己的技术和视野的不足，欢迎大家提干货意见，对于一些xx，连基本的安装都搞不定，连电商的业务就没有接触到，就来高谈阔论大道理，这些就不必了，浪费时间，提意见，首先你得是一个电商资深人士。

fecshop也不尽完美，目前的库存处理是在mongodb里面，这样做的原因也是一个折中方案：

1.在电商行业，一般都是多渠道销售，无论各个渠道控制的多么严格，总会存在超卖现象，譬如在自营网站，ebay，amazon平台卖货，总会存在这种情况，超卖，因此对于销售平台，库存不是要求100%严格的，因此，即使fecshop的库存在mongodb里面，没有事务，小概率的没有回滚机制造成的库存不准确，也没有太多的问题。

另外，电商网站的支付存在很多不确定因素，譬如有的信用卡支付的订单，可能要超过几个小时，才能得到订单支付状态，为了更好的销售，可能会有超卖模式。

2.仓库里面的库存，不应该在电商网站中控制，而是在erp里面控制，erp里面是精准的库存个数，各个销售渠道，订单支付成功，并确认后，从erp中扣取库存。

[题外话]对于库存管理，不是一个简单的事情，存在多仓处理，除了实际库存，为了执行的需要还会有虚拟库存 可用库存等等等很多库存名称，譬如，订单在打印物流单之前，需要先查看是否存在库存，如果存在，那么先扣除可用库存，也就是说，商品还没有发货，没有扣除实际库存，但是需要先占用库存，那么就需要一个可用库存的概念。

3.一般公司都会有采购部门，无货，可以去1688等平台采购，实在采购不到，可以联系退款，能用人解决的小概率事件，就不要用程序来解决了，完美意味着更多的财力和人力的输出，公司前期应该更多的心思放到产品，业务，销售，运营环节，而不是扣一些芝麻绿豆的事情。

那么有同学说，为什么不放到mysql中呢？

如果放到mysql中，复杂度就会升级，譬如产品页面不显示无库存的产品，mysql和mongodb无法做join操作，如果用in查询，如果一个分类下面产品几万甚至几十万，那么用in查询就会非常慢，因此，现在就用这么一种折中的方案， 库存在mongodb里面，而没有放到mysql中，

当然，这个可以根据自身的情况做重构。

完美意味着更多的人力和财力支出。

这些以后会讨论一下，是否有更好的方式，如果找到好的方式，我们就重构一下。

老大，回复的这么详细！

利于纵向扩展和分布式架构，可以快速解决并发处理能力

:blush: :smiley: :relaxed: :smirk: :relaxed: :laughing: :smile: :bowtie: :tw-1f1eb-1f1f7: :tw-1f1eb: :tw-1f1ec-1f1e7: :tw-1f1ec: :fa-font: :fa-bold: :fa-italic: :fa-text-height: :fa-text-width: :editormd-logo-1x:

多谢回复哈，额，真没想到能回复这么多........

@jackhyq #3楼 现在产品的库存处理，放到了mysql里面了。

@diveking #6楼 @fecshoper #4楼 @fancy #5楼 @jackhyq #3楼 产品的库存处理，放到了mysql里面了。

之前放到mongodb里面不合理，放到mysql里面比较合理，库存涉及到事务处理