我想分享有关将整体应用程序迁移到微服务的故事。 请记住，那是在2012年至2014年期间。这是我在dotnetconf（RU）上的演讲的抄录 。 我将分享一个有关更改基础架构各个部分的故事。

项目说明

主要项目思想是从Internet上检索文章，对其进行分析，保存并创建用户供稿。 一方面，我们的基础架构必须可靠，但另一方面，我们的预算却很大。 结果，我们同意：

• 允许系统性能下降。
• 我们的基础架构的某些部分可能会停机30分钟。
• 万一发生灾难，停机时间可能会是几天。

爬行者

这是基础架构的简单组成部分。 抓取工具应下载，分析并保存。 第一个实现是单个爬虫，但是，世界正在发生变化，并且出现了许多不同的爬虫。 爬虫通过MsSQL相互通信。

对于爬虫来说，停机时间不是问题，因此扩展它们真的很容易：

• 自动配置。
• 添加业务指标。
• 收集错误。

Msql的

我们的数据库约为1TB。

MsSQL群集

有多种创建群集的方法：

1. SQL镜像。
2. Windows故障转移群集-并非如此，因为没有san / Nas。
3. AlwaysOn-对我们来说这是全新的，而且没有专业知识，因此，对我们而言并非如此。

结果，我们决定使用1st。 我想注意到，由于异步模式，我们没有使用见证服务器，因此我们为自动切换主机->从机＆手动从机->主服务器创建了脚本。

MsSQL性能

时钟在滴答作响，性能在下降，我们正在寻找瓶颈。 有时，这并不容易，即通过磁盘io优化SQL查询，这时我们发现由于缺少RAM而导致性能低下。 但是，这还不够，作为一个临时解决方案，我们从HDD迁移到SSD。 一方面，它极大地提高了性能，但另一方面，这不是一个长期的解决方案。

消息队列

我们的应用程序已迁移到消息队列。 我们只在数据库中写入结果。 结果，我们减少了数据库负载。 但是我们面临一个问题：如何组织消息队列集群？ 首先，我们创建了一个冷备用数据库。

网页

Web部件由两部分组成：静态内容和用户动态内容。

WEB静态

基础结构的WEB静态部分约为2TB，它必须：

• 存储图像。
• 转换图像。
• 检索原始图片并根据需要裁剪。

存在2个主要问题：如何同步文件以及如何创建Web群集。 有几种方法可以同步文件：购买存储，使用DFS并在每个服务器上保存文件。 这是一个艰难的决定，但是，我们决定选择第三种方式。 对于网络群集，我们决定使用NLB和CDN。

WEB平衡器

对于高负载项目使用单个服务器并不是一个好主意，您必须以某种方式平衡流量。 在我们的案例中，有4种方法：

1. 硬件平衡器-对我们来说太昂贵了。
2. IIS和ARR-太复杂了，无法支持。
3. Nginx-足够好，但是，我们在健康检查方面遇到了一些问题。
4. Haproxy-这是开销最小的解决方案。

我们选择了第四种方式。 我们通过DNS轮循和用户（通过Cookie）来平衡haproxy。

Mongodb

几个月后，我们面临SQL性能再一次不够好的问题。 但是，这是一个复杂的问题，经过长时间的讨论，我们决定从CAP定理中选择“ 可用性和分区容差” 。 结果，我们实现了一个MongoDB集群（分片和副本）。 有一个有趣的经历：如何创建MongoDB备份，如何升级以及许多MongoDB错误。

备份与监控

我们实施了3-2-1规则：

• 至少3份。
• 至少2种不同的存储类型。
• 至少必须在外部某处存储1个副本。

此外，我们创建并测试了灾难恢复计划。 您可以在此处阅读有关监视的信息 。

应用程序更新

如您所见，基础架构并不像馅饼那么简单。 我们必须以某种方式对其进行更新。 休闲更新如下所示：

1. 做一些准备。
2. 冉移民。
3. 更新Web应用程序。
4. 更新后端应用程序。

对于登台/预生产/生产环境，所有逻辑步骤都相同，但是在细节上略有不同。 因此，我们使用OOP魔术创建了PowerShell脚本。 这是改善我们的CI / CD基础结构的持续过程。

结论

关于将3台台式机迁移到可靠的基础架构中，这是一个了不起的故事。 要有耐心并制定计划。

聚苯乙烯

• dotnetconf（RU） 。
• 滑梯（RU）
• 影片（RU）
• 是交叉路口