magento2 扩展日志_可扩展的magento 2架构

magento2 扩展日志

I write this post with mixed feelings as a company in my portfolio has recently decided to no longer on-board new Magento development projects due to various reasons beyond the scope of this post. However, we are still here to help with companies that are looking for a hand on designing infrastructure, maintaining the systems side of Magento environments, and migrating working Magento instances to the cloud.

我写这篇文章时充满了困惑，因为我的投资组合中的一家公司最近出于各种原因，决定不再参与新的Magento开发项目。 但是，我们仍然在这里为正在寻求基础架构设计，维护Magento环境的系统方面以及将工作的Magento实例迁移到云中的公司提供帮助。

For those of you who are not familiar, Magento is one of the most popular E-Commerce platforms used by e-tailers of all sizes. Perhaps it gained its popularity due to the fact that it’s an opensource project with a freely distributed community edition helping lots of companies build out powerful e-commerce websites quickly at extremely low costs. It has also in the past been one of the only few choices in its class that could efficiently handle large amounts of SKUs until the recent years where some of its competitors have caught up a bit. According to Wikipedia, there are over 100,000 stores globally that run on Magento and the software itself has been downloaded more than 2.5 million times. In 2018, Magento was acquired by Adobe for 1.68 billion US dollars, effectively becoming one of the members of Adobe’s brigade of web presence building tools.

对于不熟悉的人来说，Magento是各种规模的电子零售商使用的最受欢迎的电子商务平台之一。 也许由于它是一个具有免费分发的社区版本的开源项目，该项目帮助许多公司以极低的成本快速建立了强大的电子商务网站，所以它之所以受到青睐。 过去，它也是同类产品中能够有效处理大量SKU的仅有的少数选择之一，直到最近几年，其一些竞争对手对此有所追赶。 根据Wikipedia的数据 ，全球在Magento上运行的商店超过100,000家，该软件本身已被下载超过250万次。 2018年，Magento以16.8亿美元的价格被Adobe收购，实际上成为Adobe的Web现场构建工具大队的成员之一。

As you can tell from the above, even though we always advice customers to build out their e-commerce sites the right way from the start with custom builds rather than using pre-built template based platforms for many very good reasons, it’s extremely easy for budget conscious businesses to be tempted to go with a template based platform to reduce up-front costs instead. Whether this is a good decision or not is yet another topic beyond the scope of this post. However the point is that because of this phenomenon, we have over the years done quite a bit of work with Magento and some of the other platforms like WooCommerce, Odoo, and even Shopify.

从上面的内容可以看出，尽管出于很多很好的原因，尽管我们始终建议客户从定制构建开始就以正确的方式构建自己的电子商务站点，而不是使用基于预先构建的模板的平台，但对于精打细算的企业倾向于使用基于模板的平台来降低前期成本。 这是否是一个明智的决定，这是本文范围之外的另一个话题。 但是，关键是由于这种现象，我们多年来与Magento以及WooCommerce ， Odoo甚至Shopify之类的其他平台进行了大量的工作。

背景 (Background)

Around two years ago, a friend’s company running 3 e-commerce websites on a single Magento 1.9 instance came to me and asked for some help with their site. Apparently, at the time, the site would keep on crashing especially during high season and that was causing them business opportunities. I took a look at it and it was a typical growth situation. Basically, everything was running on a single VPS that just wasn’t cutting it anymore. So without going into too much detail, we essentially decoupled their Magento instance to an AWS EC2 auto-scaling group mounting EFS shares (we talked about containerization but the in-house team wasn’t quite ready for such a big leap) and Aurora to handle the database along with slapping Cloudflare in front of the whole thing to do some CDN and caching. They then had a somewhat scalable infrastructure from there and a single point to upload media and configure magento for all EC2 web instances. Off we went on a launch and the problem was solved.

大约两年前，一个朋友的公司在一个Magento 1.9实例上运行了3个电子商务网站，并向我求助于他们的网站。 显然，当时，该站点将继续崩溃，尤其是在旺季期间，这给他们带来了商机。 我看了看，这是典型的增长情况。 基本上，所有内容都在单个VPS上运行，而现在不再削减了。 因此，无需过多讨论，我们基本上将他们的Magento实例与安装EFS份额的AWS EC2自动伸缩组脱钩(我们谈到了集装箱化，但内部团队尚未为实现如此大的飞跃做好充分准备)，而Aurora处理数据库以及将Cloudflare打在整个事情的前面，以进行一些CDN和缓存。 然后，他们从那里有了一个具有一定可扩展性的基础架构，并且可以通过单个点上传媒体并为所有EC2 Web实例配置magento。 我们出发了，问题解决了。

Magento 1.9 New Architecture

Magento 1.9新架构

Fast forward to a few a months ago, Magento 1 using Paypal was falling out of PCI compliance and Paypal urged everyone to upgrade to Magento 2. So we regrouped with the client and discussed a plan of action. This time around, they were ready for containerization and AWS Fargate was at the same time finally mature enough for us to give it a run for its money. The hard part now is to migrate the Magento 1 data to Magento 2. This is the most painful part which I will definitely not cover here but let’s just say that we were able to successfully migrate all of the pertinent data over to a new Magento 2 instance running in Docker after a lot of pain and many sleepless nights. If anyone is thinking about doing this, I would strongly suggest you don’t go cheap and hire a strong firm that’s specifically focused on Magento with lots of experience doing migrations of this type. The difference is night and day.

几个月前，使用Paypal的Magento 1脱离了PCI合规性，Paypal敦促每个人都升级到Magento2。因此，我们与客户重组并讨论了一项行动计划。 这次，他们已经准备好进行容器化了，AWS Fargate终于终于成熟了，足以让我们为它赚钱了。 现在最困难的部分是将Magento 1数据迁移到Magento2。这是最痛苦的部分，我肯定不会在这里介绍，但是我们只能说我们能够将所有相关数据成功迁移到新的Magento 2中。经过很多痛苦和许多不眠之夜后，实例在Docker中运行。 如果有人在考虑这样做，我强烈建议您不要便宜，雇用一家专门针对Magento的强大公司，并具有进行此类迁移的丰富经验。 区别是白天和黑夜。

新建筑： (The New Archtecture:)

Now that we have a pretty solid Magento 2 instance running in Docker on our local dev environment with the migrated data from Magento 1, we are ready to throw this onto AWS. We first imported the database to Aurora and created the Redis instance. Then, we started up an EC2 instance called DevOps and ran the image with it to reconfigure it for using Aurora and made some of the directories on EFS to be test mounted by the container. After that, we committed the image and pushed it to a newly created ECR registry.

现在，我们已经在本地开发环境中的Docker上运行了一个非常可靠的Magento 2实例，并从Magento 1迁移了数据，现在可以将其投放到AWS上了。 我们首先将数据库导入Aurora并创建Redis实例。 然后，我们启动了一个名为DevOps的EC2实例，并对其运行图像以对其进行重新配置以使用Aurora，并在EFS上建立了一些目录以供容器进行测试安装。 之后，我们提交了映像并将其推送到新创建的ECR注册表中。

We are then ready to give it a run on Fargate, we created the cluster and task definitions so that the image we have prepared is launched to have 2 minimum containers with an auto-scaler that maxes out at 4 containers sitting behind an Application Load Balancer which are configs derived from our past traffic based estimates. So why Fargate you might ask? Here is my logic behind it:

然后，我们准备在Fargate上运行它，我们创建了集群和任务定义，以便启动我们准备的映像，以使其具有2个最小容器，并具有一个自动缩放器，最多可将4个容器放在Application Load Balancer后面。这些配置是根据我们过去基于流量的估算得出的。 那么，为什么要问Fargate？ 这是我背后的逻辑：

1. No servers or orchestration infrastructure to manage
   无需管理服务器或业务流程基础架构
2. Handles EFS mounting and launching/monitoring of docker containers for you via task definitions
   通过任务定义为您处理EFS的安装以及docker容器的启动/监视
3. Load Balancer is automatically adjusted on launch and auto-scaling
   在启动和自动缩放时自动调整负载均衡器
4. Overall cost reduction to only paying for what’s used compared to EC2
   与EC2相比，整体成本降低，仅需支付使用费用

Of course, we reused the bastion host that has OpenVPN (external) and ssh (internal LAN only) enabled to allow our customers to configure Magento and upload images to EFS that persists across all containers. It will also serve as the gateway for the client to access DevOps for making docker image changes and accessing the new analytics system we will be installing after.

当然，我们重用了启用了OpenVPN(外部)和ssh(仅内部LAN)的堡垒主机，以允许我们的客户配置Magento并将图像上载到可在所有容器中持久保存的EFS。 它还将用作客户端访问DevOps的网关，以进行docker映像更改和访问我们将要安装的新分析系统。

As mentioned, the client wanted to run some analytics on the data in Magento so it was only logical to create a read replica of the production database so that they can run an EC2 instance and install whatever they wanted to grab data and analyze with. So that’s exactly what we did.

如前所述，客户希望对Magento中的数据进行一些分析，因此创建生产数据库的只读副本是合理的，这样他们就可以运行EC2实例并安装任何想要获取数据并进行分析的对象。 这就是我们所做的。

And that’s it! We logged into Cloudflare, swapped out the CNAME of the domains to the new load balancer and went live. This sums up all the components of a modern scalable Magento 2 architecture as diagrammed above. There are more improvements that can be done or even components that’s already there which I didn’t really talk much about like varnish and maybe even CI/CD but what’s clearly within the diagram alone is already a solid enough foundation for general scaling and growth and definitely ready for you to add more or improve upon without any unwanted architectural issues.

就是这样！ 我们登录到Cloudflare，将域的CNAME换成新的负载均衡器并开始使用。 总结了上图所示的现代可扩展Magento 2架构的所有组件。 还有更多可以改进的地方，甚至什至已经存在的组件我还没有真正谈论过，例如清漆，甚至CI / CD，但仅在图表中显然已经为总体缩放和增长奠定了坚实的基础。绝对可以为您添加或改进而没有任何不必要的体系结构问题。

If there are any questions or suggestions, please feel free to drop a comment below or get directly in touch!

如有任何疑问或建议，请随时在下面发表评论或直接联系！

翻译自: https://medium.com/@hkdb/a-scalable-magento-2-architecture-107f5fe7a813

magento2 扩展日志