大家好！ 我敢肯定，你们中的许多人都曾在我们的商店中购买过T恤，球，运动鞋，运动鞋或其他运动器材，但从技术角度来看，很少有人知道Sportmaster是什么。
来自web.archive.org的2003 Sportmaster有点我的名字叫Dmitry，我是Sportmaster的一名高级Java开发人员，今天我想谈谈我们的在线商店，关于他现在成为您认识他的方式：我们是如何开始的，我们是如何开发的发生了什么，没有发生什么，关于今天的问题以及关于未来的计划。 有意思吗 欢迎来到猫！
公司在网络上的存在的历史可以追溯到1999年，当时Sportmaster的第一个网站就在这里，这仅仅是一张名片和批发购买者的商品目录。 实际上，该公司的在线商店自2001年以来就有其历史。 当时，该公司没有自己的团队来开发在线项目，并且在线商店设法更改了几个自制平台（现在我们甚至不记得有多少个）。 下一个集成商在2011年使用CMS 1C Bitrix在PHP中为我们创建了第一个相对稳定的解决方案。 事实证明该站点很简单，实际上使用了Bitrix盒装功能，并进行了小量定制以下订单。 对于硬件，启动配置包括2个应用程序服务器和1个数据库服务器。
同时，该公司开始在在线销售领域积极建立自己的能力，主要是在业务方面。我必须说，这很快就开始了，开发团队被迫从各个方面迅速发展以满足其需求。 在不到一年的时间里，三个团队立即开始对网站的开发和支持做出回应-集成商本人，Sportmaster的内部团队（当时只有几人）和另一个承包商-实际上，它的出现是由于集成商那时，我无法提供人们所需的能力。
当时我们有什么问题？ 有很多问题，但最重要的是我们的网上商店运作不稳定。
我们甚至可以从该公司发布某种时事通讯的事实中跌倒，然后约2000-2500人来到该网站，或者，正如我现在所记得的那样，Yandex上的广告横幅使我们陷入了深深的打击。 当然，这样的事情是不可接受的，因为这不仅损失了利润，而且损失了公司的形象-总的来说，我们了解到需要进行一些更改。 首先，我们意识到带有我们的工作负载（当时还不是很大，但仍然很小）的标准解决方案是行不通的。 然后，正常情况下，我们大约有1000位访客在线，高峰时有2500位访客，此外还有每年x2的开发计划。
立即在硬件方面增强：我们又添加了2个应用程序服务器，并组成了2个数据库服务器的集群。 当时我们的堆栈是nginx，MySQL，PHP。 同时，我们尝试优化当前解决方案-搜索瓶颈，尝试重写所有可能的方法。 由于瓶颈是基础，因此它始终是第一个“消亡”的人，因此我们决定最大程度地卸载它。 实现了狮身人面像，用于通过所选过滤器和连接的缓存进行全文搜索和带有方面的商品图块的输出。 瞧-昨天这些负载对我们来说是致命的，我们开始放轻松了。
与此同时，并行启动了一个试点项目，他们希望在此框架内进行站点的技术更新-转移到根本不同的平台上。 有很多想法和想法-当时，一切事物的个性化，个人推荐，邮件，折扣和其他有用的东西越来越受欢迎，我们当然也想利用所有这些。 我们从中很好地研究了市场上可以买到的东西，并按照“价格先涨，然后降温”的原则购买了最昂贵的平台。 实施计划是在集成商的帮助下进行的，在新的有条件的IM在新平台上投入运行之前，我们仍然得到有条件的旧IM的支持和进一步开发。
但是由于当前站点的功能开发速度非常快，因此我们决定从奥斯丁零售链当时较小，较简单的在线商店开始实施新的电子商务平台，该平台也由IT Sportmaster团队提供服务。 在此过程中，我们意识到，这件东西很重且功能复杂，但在技术上已经过时，因此，寻找人们完全实施它是一个巨大的问题。 此外，在项目开始之前进行规模调整，大大减少了对硬件和许可证数量的需求-事实证明，寿命更加残酷。 一般而言，我们了解一件事：我们不会对此做Sportmaster。 由于要迁移到该平台的团队已经在招聘过程中，因此他们决定根据企业对新平台的要求，开始开发自己的解决方案的原型。
选择了以下技术堆栈：Java，Spring，Tomcat，ElasticSearch，Hazelcast。
结果，到2014年底，我们已经准备好完全自主编写的IM版本，并已成功切换到该版本。 她是您今天看到的该网站的第一个版本。 自然，当前版本具有更多的功能和技术，但是基本平台是相同的。
主要任务
当然，当我们谈论大型在线商店时，我们所谈论的是不仅愿意应付日常事务，而且愿意应付高峰负荷的意愿-使企业和最终用户保持稳定。
这里的主要方法是水平扩展的能力以及数据缓存方法在不同级别上的应用。 现在，就像前一段时间一样，我们决定优化对数据的访问。 但是我们不能使用常规页面缓存。 一般而言。 这是一项业务要求，并且要求非常合理-如果您在特定时间向站点用户显示了错误的价格或产品的错误可用性，则很可能会导致拒绝购买并降低客户忠诚度。
如果客户订购了15双袜子，价格为299卢布，那没关系，在商店里，他发现实际上只有14双，每双300卢布，您可以以某种方式生活。 接受，购买是什么，并在您的灵魂中继续这一疤痕。 但是，如果数量上的差异很严重，或者您正在寻找特定的尺码-并且在您阅读格仔短裤的满意主人的评论时买断了，这里的一切已经变得更糟了。 也就是说，立即失去一个满意的客户（至此为止），并浪费时间和金钱在呼叫中心的工作上，该客户将呼叫该呼叫中心以了解发生了什么事情以及原因。
因此，用户应始终查看商品余额的最新价格和最新数据，因此我们的缓存很智能，并且知道数据库中的数据何时更改。 对于缓存，我们使用Hazelcast。
顺便说一下关于剩菜
在此必须注意的是，商品残留物的深度很小。 而且有很多订单需要提货（非常多）。 因此，客户通常应在正确的商店中保留货物并跟踪余额。 一次，在Bitrix上，残留物问题被一个事实所解决，即它们仅将超过10个单位的任何残留物视为无穷大。 也就是说，大于10的所有值始终等于10，但是较低的值对于我们来说已经很有趣了，我们将其考虑在内，然后将其上传到网站。
现在不再可以执行此操作，因此，我们每15分钟从所有商店中下载一次剩菜。 我们有大约500家商店，再加上一些区域仓库，再加上几个零售连锁店。 所有这些都必须及时更新。 令人毛骨悚然的事实是，快递公司的工作条件经常在俄罗斯联邦的规模上发生变化，因此，还必须加载交货参数。 此外，连续不断的货物流被运送到公司的仓库，这就是为什么仓库中的货物数量会发生变化的原因。 因此，还需要再次将其拉出。
这是商品项目标识符（SKU）的形成方式。 我们有大约40,000种所谓的商品颜色模型。 如果我们进一步扩大商品的规模，我们将获得约200,000 SKU。 对于所有这些，需要以500家商店的规模来更新200,000。
我们还有数以万计的城市和村庄，我们从商店或仓库向他们运送货物。 因此，事实证明，仅一个产品页面（城市* SKU）的缓存可变性是值的百万分之一。 我们的方法是这样的：当用户输入产品卡时，将即时计算特定商品单元的可用性。 我们查看快递员在用户所在地区的工作，查看他们的工作时间表，计算交付链并考虑其持续时间。 同时，并行分析附近商店中的遗骸，从而可以安排运输。
为了更轻松地管理所有这些，我们在应用程序中提供了一定数量的非常快的缓存-有了这个，我们可以通过ID快速获取所有必要的数据，并即时对其进行整理。 快递公司也是如此-我们将它们分组到集群中，然后集群已经保存到数据库中。 每隔15分钟，所有这些都会更新一次，对于每个传入的请求，我们都会计算出一些带有必要参数的快递员，将其汇总并迅速将其分发给买方-一切正常，我们肯定有50号绿色短裤，您可以立即在附近的这三个商店中拿起笔，或在马路对面的商店（甚至是家中）订购3天，然后选择。
对于莫斯科来说，这种情况似乎是不必要的，但是对于地区而言，这是完全不同的事情，他们经常向一些商店订购商品（也许您还需要专门到达这些商店）。
人物
现在，该站点每秒接收到数千个请求，同时考虑到静态消息和每秒对应用程序服务器的500-1000个请求。 应用程序服务器的数量没有改变，但是它们的配置已大大增加。 每天平均获得约3,000,000次观看。
有时会在网站上找到DDoS。 同时，他们用僵尸网络，还有我们俄罗斯联邦的亲戚来敲门。 很久以前，曾有尝试敲诈来自墨西哥和台湾的僵尸网络的案例，但现在不再如此。
市场上有很多针对DDoS的云防护解决方案，是的，而且是相当不错的。 但是对于某些安全策略，我们不能使用这种云解决方案。
现在呢
我们开始制作一个平台解决方案，将各个团队不是垂直地分开（其中一些人看到一个站点，第二个人看到另一个站点），而是水平地突出显示公共平台层，将其分成多个部分，从而围绕它形成一个团队。 在他们身上，我们已经关闭了该站点，不仅包括公司的任何内部和外部客户，还包括该公司。 因此，我们有很多复杂而有趣的工作。
由于明显的原因，前端的堆栈在此期间并没有真正改变-Java，Spring，Tomcat，ElasticSearch和Hazelcast仍然可以满足我们的需求。 另一件事是，现在站点背后隐藏了许多基于各种技术的后台系统。 而且，当然，重新设计正在进行中（因为需要优化内部系统以及与它们一起使用的整体需求，而且我们不会忘记业务需求和新的业务功能）。
您可以放心地向我个人（或发表评论）关于改善站点的任何建议-包括新功能，视觉组件和整体用户体验。 我们将尽力快速做出反应并考虑到所有问题。 如果您想成为团队的一员并从内部了解这一切，
欢迎 。