通过故事介绍基于微服务的架构—第 1 部分
通过故事介绍基于微服务的架构—第 1 部分
如今，基于微服务架构的趋势似乎对许多大型分布式应用有意义。这种架构风格有助于提高可伸缩性，并有助于降低构建每个微服务的代码的复杂性。
我将尝试用讲故事的方式来强调这些问题，因为我是这种写作风格的新手，请原谅我。
开发商的运动
Gemma 是一名高级开发人员，刚刚加入一家销售在线漫画书的新公司。你可以通过他们的店面购买新的漫画书，或者你可以浏览你的收藏，并通过你的各种数字设备阅读它们。它有一个温文尔雅的棱角分明的前端，非常敏感，非常受欢迎。
Iron Man clearly tops the charts.
管理所有交易、所有账户更新、所有漫画书的软件是一个用 Java 编写的大项目，测试和部署变得越来越困难。前几个月出现了一些问题，导致所有网站服务都停止了。这总是让公司付出金钱和名誉的代价。发布也是一个手动过程，在发布窗口期间，问题经常会使站点短暂停机。从本质上讲，如果发生类似内存泄漏的事情，它将导致我们系统的唯一实例崩溃。
另一个关键的事情是，该网站无法处理大量的流量高峰，每次新的莉莉·威廉姆斯漫画出来，该网站就濒临死亡，有几次 Gemma 和她的团队都会在周六凌晨 2 点接到电话，说一切都关闭了。
管理层越来越担心竞争对手会开始赢得越来越多的客户，因为他们对网站越来越频繁的宕机越来越不满。显然，这些问题必须迅速有效地解决。
球场
当 Gemma 加入该公司时，她知道开发人员采用基于微服务的方法的趋势，并且她已经阅读了一些基础知识。通过研究，她发现微服务有助于提高弹性，并允许她更快地对应用程序的几个部分进行更改，同时降低平台宕机的总体风险。
她向管理层提出了这个概念，他们同意让她管理从整体架构到一系列微服务的过渡。
最初的设计阶段
当设计这种新的微服务架构时，Gemma 考虑遵循域驱动设计方法，并开始分解她的单片应用程序。
她将所有账户功能划分为一个域，将商店划分为一个域，将漫画书浏览器划分为一个域。
这种架构的主要好处之一是，当 Gemma 对帐户服务中的某些内容进行更改时，如果出现问题，公司不会因为取消商店服务而花费大量资金。本质上，通过将所有东西分离成具有有界上下文的服务，她保护了自己，避免了一个关键点的失败。
发展阶段
一旦我们新的基于微服务的系统的主要设计完成，接下来就是开发阶段。为了这个故事的目的，我们将稍微掩饰一下这一点，但是整体上，将我们的 monolith 重构为一系列微服务允许 Gemma 在语言选择方面进行一些混合。
团队的核心部分精通 Python，并决定用 Python 重写一些服务，以提高整体代码的可读性。由于对性能的担忧，store 服务仍然使用 Java，但是团队中的开发人员喜欢回到他们的根源，再次探索他们最喜欢的语言，并让两个服务通过 REST API 调用进行通信。
总的来说，这个阶段被证明是成功的，唯一的问题是在重构阶段没有开发新的功能。Gemma 在最初的提案中向管理层强调了这一点，但说服他们的想法是，在重写完成后，他们可以更快地部署代码，并且更加稳定。
初始部署策略
经过几个月的重构和重写代码，现在是时候了。当涉及到这些重构服务的初始部署时，可能会有压力，但是在进行转换之前，您可以根据需要花尽可能多的时间。Gemma 和她的团队部署了这些服务，并执行了一整套集成测试，一旦他们确信可以将这些服务迁移到他们的生产环境中。在这个阶段，他们执行了一系列探测测试，并开始迁移他们的网站，以使用他们新部署的服务，同时让旧的仍然运行。
通过让旧服务继续运行，他们有了一个不错的回滚策略，以应对新服务在生产工作负载下的困难。
蓝绿色+淡黄色部署
对于他们以前的 monolith，在拆除旧版本和启动新版本之间有一小段停机时间是必要的。Gemma 意识到，她可以通过利用蓝绿色部署来消除任何停机时间。
她决定跨多个区域运行每个服务的 2 个或更多实例，并在此之前安装一个负载平衡器。当她希望部署系统的新版本时，她可以关闭其中一个实例，部署更新的版本并执行完整的集成测试，然后再将其重新添加到负载平衡器并允许流量通过它。然后，她可以迭代地处理剩余的实例，直到所有的旧版本都被替换。
决赛成绩
在切换到基于微服务的架构 3 个月后，Gemma 和 co 的停机时间减少了，弹性提高了，团队能够更快、更有信心地开始迭代进行更改。
然而，这并不完全是阳光和毛茛，随着弹性的提高和服务数量的增加，部署整个资产的复杂性也增加了。通过系统追踪问题的复杂性也在增加。
结论
希望这种讲述故事的方法能够体现基于微服务的方法的一些主要优势，这对我来说有点新，所以我希望得到反馈！
在下一篇文章中，我们将继续关注 Gemma 和 co 如何应对管理其多个服务和跟踪其房地产问题的日益增加的复杂性。