微内核体系结构
如今，对基于微服务的体系结构的驱动对于许多大型的分布式应用程序似乎是有意义的。 这种架构风格有助于改善诸如可伸缩性之类的内容，并有助于降低构建每个微服务的代码的复杂性。
我将尝试通过讲故事来突出这些问题，请耐心等待，因为我是这种写作风格的新手。
开发者的远征
杰玛（Gemma）是一位高级开发人员，刚刚加入了一家新公司，该公司出售在线漫画。 您可以通过商店的新书购买漫画，也可以导航到您的收藏并通过各种数字设备阅读它们。 它有一个在Angular中构建的和ave的前端，响应速度非常快并且非常受欢迎。
管理所有交易，所有帐户更新和所有漫画书的软件是一个用Java编写的大型项目，测试和部署变得越来越痛苦。 前几个月出现了一些问题，导致所有站点服务都关闭了。 这总是使公司付出金钱和声誉。 发布也是一个手动过程，在发布窗口期间，问题经常使站点短暂瘫痪。 本质上，如果发生诸如内存泄漏之类的事情，它将破坏我们系统的唯一实例。
另一个关键问题是，该站点无法处理大量的流量高峰，每次出现新的Riri Williams漫画时，该站点都会濒临死亡，而且有时Gemma和她的团队都会在星期六的凌晨2点接到电话一切都失败了。
管理层越来越担心竞争对手会开始赢得越来越多的客户，因为他们对网站越来越频繁的停机时间越来越不满意。 显然，这些问题必须Swift有效地解决。
球场
当Gemma加入公司时，她了解开发人员采用基于微服务的方法的趋势，并且她一直在阅读一些基础知识。 从她的研究中，她发现微服务可以帮助提高弹性，并允许她更快地对应用程序的某些部分进行更改，而平台故障的总体风险较小。
她向管理人员提出了这个概念，他们同意让她管理从单一架构到一系列微服务的过渡。
初始设计阶段
在设计这种新的微服务体系结构时，Gemma着眼于遵循域驱动的设计方法，并开始分解她的整体应用程序。
她将所有帐户功能划分为一个域，将商店划分为一个域，将漫画查看器划分为一个域。
这种体系结构的主要优点之一是，当Gemma对帐户服务中的某项内容进行更改时，如果出现问题，无需花掉商店服务即可使公司花费大量金钱。 从本质上讲，通过将所有内容分离到具有上下文限制的服务中，她保护自己免受失败的一个关键点的困扰。
发展阶段
一旦我们新的基于微服务的系统的主要设计完成，接下来就是开发阶段。 出于这个故事的目的，我们将略微介绍一下，但是整体上将我们的整体重构为一系列微服务，从而使Gemma在语言选择方面有所不同。
团队的核心部分精通Python，并决定重写Python中的某些服务，以提高整体代码的可读性。 出于对性能的担忧，商店服务仍然使用Java，但是团队中的开发人员喜欢回到自己的根源并再次探索他们喜欢的语言，并使这两个服务都通过REST API调用进行通信。
总体而言，该阶段被证明是成功的，唯一的问题是在重构阶段没有开发任何新功能。 Gemma在最初的建议中向管理层强调了这一点，但是卖掉了他们，因为他们认为重写完成后他们将能够更快地部署代码，并且具有更高的稳定性。
初始部署策略
经过几个月的重构和重写代码，现在是黄金时间。 最初部署这些重构服务时，可能会感到压力，但是在进行转换之前，您可能需要花费尽可能多的时间。 Gemma和她的团队部署了服务并执行了完整的集成测试，一旦他们确信将它们移至生产环境中。 在此阶段，他们进行了一系列的探测测试，并开始迁移其网站以使用新部署的服务，同时保持旧的服务仍在运行。
通过使其旧服务保持运行，如果新服务在生产工作负荷下仍处于挣扎状态，他们可以采取适当的回滚策略。
蓝绿色+ Canary部署
对于他们以前的产品，有必要在关闭旧版本到启动新版本之间进行短暂的停机。 Gemma意识到她可以利用蓝绿色部署消除任何停机时间。
她决定在多个区域中运行每个服务的2个或更多实例，并在此之前使用负载均衡器。 当她希望部署系统的较新版本时，可以将其中一个实例关闭，部署更新的版本并执行完整的集成测试，然后再将其重新添加到负载均衡器并允许流量通过。 然后，她可以迭代遍历其余实例，直到替换了所有旧版本。
最终结果
改用基于微服务的架构3个月后，Gemma和他的同事减少了停机时间，提高了弹性，并且团队能够以迭代的方式开始进行变更，并且更加自信。
但是，这还不只是阳光和毛cup，随着弹性的提高和服务数量的增加，部署整个资产的复杂性也增加了。 整个系统中跟踪问题的复杂性也是如此。
结论
希望这种讲故事的方法能够融合基于微服务的方法的一些主要优点，这对我来说是个新事物，所以我希望得到反馈！
在下一篇文章中，我们将关注Gemma和co如何应对日益复杂的管理其多种服务和跟踪整个资产的问题。
微内核体系结构
2289
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
