电商资讯 2021-01-15 10:15:15
这次介绍的项目是自学整理出来的，可能只是开源社区的一艘船。不过我还是希望能为这个项目写一个wiki，针对小白或者初级开发者，让大家可以亲自了解和搭建自己的电商后台系统。
是的，这个项目是开源的，但是我希望你在下载源代码之前能仔细阅读这个系列。开源地址将在本系列的最后一章给出。谢谢你。
众所周知，一个真正的企业级项目开发过程，编码思维、经验、技巧、高质量的在线作品，都需要人力、物力和成本。同样，我们的项目需要你挤出时间慢慢消化！
让我们来看看我们最熟悉的淘宝建筑
当然，没有一个网站平台一开始那么丰富，而且是一步一步进步的。
这一次我们也将从核心模块——演化细节，到核心架构——设计思路，最终实现高性能、高并发、高可用性的电子商务实用项目。
这一次我们将讨论数据库和界面、项目初始化、用户模块、分类模块、商品模块、购物车模块、送货地址模块、付款模块和订单模块
既然是前言，我们先来了解一下一个大型Java项目架构的演化分析。
首先，从一个小网站来说，一台服务器就够了，数据库和应用程序都部署在一台服务器上。
随着用户和数据量的增加，硬盘支持不了，然后一个服务器也支持不了。我们可以把应用服务器和数据服务分开，给应用服务器配置更好的CPU和内存，给数据服务器配置更好更快的硬盘。在下图中，三个服务器用于提高性能。
即使文件服务器宕机，该架构仍然可以使用。随着访问并发性的增加，为了减少接口访问时间，提高服务性能，我们需要继续优化演进。我们会发现，每次都有很多数据不需要从数据库中读取，所以我们增加了缓存，主要是因为80%的访问集中在20%的数据上(28原则)。只要缓存合适，系统性能也会提高。缓存分为两种类型：本地缓存本地缓存和远程分布式缓存远程单机缓存(远程分布式缓存)。下图显示了分布式缓存集群(哪些服务使用远程缓存，哪些服务使用本地缓存)
此时，随着QPS接入的不断完善，服务器的处理能力是有限的。比如Tomcat会成为瓶颈。即使购买了更好的硬件，也总有上限，成本也不低。这时候我们需要做一个服务器集群(负载均衡调度服务器)，这样就可以横向扩展我们的服务器，解决服务器处理能力的瓶颈。
这时候我们要思考几个问题，比如什么是所谓的负载均衡调度策略，适合什么场景。当我们登录到服务器A时，会话信息存储在服务器A上，假设我们的(iphone ash)负载均衡将它的信息分配给其他服务器，但是不够分散或者不够统一，可能会导致一些服务器压力过大，而另一些服务器没有压力。这时机器网卡的带宽可能会成为瓶颈。这时候我们使用轮询或者最小连接负载的策略，可能导致访问服务器a之后访问服务器B时无法读取Session信息，这时候我们需要解决Session管理的问题，我们使用Session Sticky(粘制会方言)来处理这个问题。
比如每次吃饭都要保证自己用筷子。只要我们把筷子存放在餐馆里，我们每次都可以在这家餐馆吃饭。处理方法是：对于同一连接中的数据包，负载均衡进行一次NAT转换，转发给后端固定的服务器进行处理。如下图所示，该方案解决了会话共享的问题(缺点：一旦服务器重启，所有会话都会消失，负载均衡服务器变成有状态服务器，难度大。
我们来看看第二种解决方案。两台服务器都通过复制保存Browser1的会话信息(缺点：应用服务器间带宽问题，服务器间会话信息持续同步，大量用户在线时服务器占用内存过多，不适合大规模集群)
看第三个方案，基于cookie，就是每次吃饭都自带筷子，可以去任何餐厅吃饭，使用携带会话信息的cookie访问服务器，也解决了会话共享的问题(缺点：cookie长度有限，存储在浏览器中，安全性没有保证)
接下来看第四种解决方案。我们将会话设为会话服务器。browser1通过负载平衡请求服务器，服务器将会话信息存储在会话服务器中。当我们想要得到它的时候，我们就逆转它。(缺点：会话服务器目前是单点，如何解决单点并保证可用性)
我们还可以将会话服务器做成一个集群，它适用于大量会话和web服务的情况。在更改模式之后，我们还应该修改应用程序存储会话的业务逻辑。接下来，我们来看看数据库。读写必须通过数据库。当用户数量达到一定量时，数据库又会成为瓶颈。我们将如何解决？
我们可以使用数据库读写分离，主从库，通过统一的数据访问模型进行访问，把所有的读操作引入从服务器，把写操作引入主库。由于数据库读写分离，应用程序也应该有相应的变化。使用数据访问模块可以让应用开发者忽略读写分离的存在，让多数据源读写代码不入侵我们的业务(代码层的演进，如何支持多数据源，如何打包而不入侵业务，如何利用现有的ORM框架实现数据读写分离，是否替换ORM，其优缺点？)
当我们的访问量太大，I/O太大时，我们数据的读写分离又会遇到这些问题，比如主从库在复制时是否延迟(不同机房部署，跨机房传输)，应用中数据源的路由问题。然后，为了提高服务器，我们增加了CND和反向代理服务器，使用CDN可以解决异地访问速度的问题，反向代理可以缓存用户在机房的资源。
这时，文件服务器又出现了瓶颈。我们将文件服务器改为分布式文件服务器集群。我们要考虑：如何不影响网上业务访问，是否需要业务部门的帮助清理数据，是否需要备份服务器，是否需要重新做域名解析。
这时，我们的数据库出现了新的瓶颈。我们选择了一种特殊的方式对数据库进行垂直拆分，可以解决写数据、并发、量大的问题。拆分数据库后，会带来一些新的问题：跨业务事务(分布式事务)
当访问量、数据量、日志等。某些数据太大，无法达到瓶颈，那么我们将水平分割数据库。我们将用户分成用户1和用户2，并将同一数据表的数据水平分成两个数据库。这时候就要解决单数据库的瓶颈了。
水平拆分后的SQL路由存在一些问题。假设我们想知道Users1或者Users2中是否存在一个用户，由于数据库拆分，主键的策略会有所不同，同时也会面临分页问题(后台管理系统在显示时也要考虑分页)。完成后，我们发现应用服务器的搜索量正在增加，所以我们提取应用服务器的搜索功能来制作搜索引擎，并使用NoSQL来提高某些场景下的性能。
当然，以上架构还是存在一些问题。例如，负载平衡服务器是一个单点，因此负载平衡服务器也可以集群化，用于主从热备用和自动切换解决方案。
过程中：安全、数据分析、监控、防作弊…继续发展：SOA架构、服务、消息队列、任务调度、多机房…
所以任何高大项目的技术架构和开发技术都不是一朝一夕可以实现的。
随商信息技术（上海）有限公司 b2b2c多用户商城系统是基于PHP技术的企业级电子商务平台系统，系统支持平台自营、招商加盟和多商家入驻、集成微信商城、移动端APP商城、微信小程序于一体。公司主营业务包含商城系统定制开发、新零售系统解决方案、电商平台系统定制开发、商城网站建设服务等等，随商为大、中、小企业提供一个安全、高效、强大的电子商务解决方案，协助企业快速构建、部署和管理其电子商务平台，拓展企业销售渠道，致力于推动PHP技术和电子商务行业的发展而不断努力。