构建未来：微服务架构

在讨论已经运行几年的电子商务系统的 2-3 年架构路线图时，典型的问题是——我们是否需要采用微服务架构？

微服务现在是一个热门的流行词，因此很自然地将它们用于系统的演进。 然而，将单体系统重新架构成微服务的主要驱动力实际上是业务和运营性质的，例如：

1. 为业务增长而架构：随着系统为更多的客户提供服务并处理更多的交易，它需要更多的容量和资源。 但是，并非系统的所有部分都可以以相同的速度增长。
2. 处理流量高峰：理想情况下，系统应该能够自动扩展，或者至少以不将基础设施推到最大容量的方式动态扩展，以便始终支持高峰流量。
3. 更快的上市时间：添加或修改一项功能需要数天或数周而不是数月，并且不需要过多（通常是昂贵的）回归测试和重新启动运行整个环境的所有应用程序，这对企业具有重要价值。 对此的答案是模块化和可替换性设计，微服务促进了这一点。
4. 快速、即时地更改内容和用户体验：许多传统的在线系统在服务器端动态生成内容，来自同一个 Web 应用程序，该应用程序还包含结帐功能、我的帐户和其他功能（即单体）。 这意味着，虽然面向客户的内容可以是最新的、可能是个性化的和可管理的，但不断地重新生成内容会消耗大量的 CPU 周期，从而创建对数据存储和潜在其他子系统的在线依赖性。

微服务架构的最终目标是将此应用程序分解为相对独立的服务，这些服务提供默认内容、提供库存状态信息以及提供个性化的报价和建议。 然后可以调整、扩展和管理这些服务，以实现最佳用户体验。

这里的想法是让一个系统由几个独立的、可扩展的、可替换的服务组成。

一砖一瓦：逐步移动系统

那么问题来了，我们如何执行这个计划？ 从头开始重写系统通常是不可接受的。 对当前平台进行了投资，对功能进行了测试和验证，或者需要在当前系统中完成其他功能增强。

通过在路线图开发计划中包括重新架构活动，就目标架构达成一致并开始逐步将系统移向目标可能是更好的方法：

1. 确定可以解决最优先业务问题的更改，并为重构/迁移制定计划。 例如“将内容管理与系统的事务部分解耦”，因此可以更快地将更改推送到站点。
2. 添加功能（例如“您可能还喜欢”或“如果您花费额外的 X...”）而不是将其混合到当前应用程序中时，请考虑它是否可以作为公开界面的独立服务提供价值，并且可以独立管理。 它不需要在开始时作为独立进程运行或可自行部署，但应以最少的易于理解的依赖项进行良好封装。
3. 在对子系统（例如 MyAccount）进行重大更改时，请考虑此时是否适合将其单独制作为应用程序或服务。 同样，重要的因素是考虑依赖关系——在代码和运行时级别上。

如果通过对 MyAccount 服务进行更改需要重新编译和重新部署所有其他模块，那么它还不是迁移的好选择。 但可能还有其他候选模块涵盖了他们自己的特定领域关注点：

• • 客户电子邮件通讯服务
  • 结帐即服务
  • 物品可用性服务
  • 商务搜索引擎
  • 各种个性化、咨询或推荐服务
  • 产品评论/评级服务

以正确的方式扩展您的项目：定义微服务架构流程和计划

正如您所看到的，随着服务数量的增加并增加了解决方案复杂性的感觉，这张图片很快就会开始感到忙碌。 为了解决这个问题，团队需要特别注意项目的以下方面：

架构清晰性：这并不一定意味着“预先设计大”的方法，但团队需要就系统将由哪些服务组成，以及如何构建、部署服务有共同的愿景和理解, 并被监控。 团队需要准备好采用不同的实践（API-first）、框架（Spring Cloud）、通用应用程序基础设施元素——API 网关、身份验证服务器、服务注册中心等。并非所有这些都是必需的，但必须是一个有意识的架构决定，它们是否将成为系统的一部分。

DevOps：这是另一个流行的流行语，但在这种情况下非常重要。 随着系统的增长，服务的数量可能会变得不堪重负，因此在微服务​​世界中，DevOps 是必不可少的元素。 这意味着构建、测试部署、重新启动、自动缩放、警报等的自动化和流线化。我们不是在处理部署到几个应用程序服务器的单个二进制文件。 可能有几十个较小的功能，每个都可能在多个实例中运行，这不是任何人想要手动支持的东西。 想象一下从所有这些正在运行的应用程序中手动收集日志......

微服务架构：正确使用

错误地迁移到微服务有很多方法：仅仅跟随技术热潮，没有真正的商业案例，识别过于依赖彼此的不合适的服务，未能采用 DevOps 实践来解决复杂性，而不是开发团队中的正确技能等。

然而，通过适当的计划和风险管理，经过一段时间（以及 PM 的压力、怀疑和恐慌），团队应该开始感受到一些积极的影响：

• 系统或其重要部分可以更好地扩展
• 无需在半夜重新启动其他所有内容，即可更轻松地交付新功能
• 系统组件具有更明确的用途，因此更易于开发、测试和替换

架构路线图是帮助确定未来两三年系统演进方向的工具。

它需要与业务路线图、战略技术和行业方向以及团队技能和能力保持一致。 随着微服务等新架构概念和方法的引入，其重要性尤其增加。