Shopify是如何迁移到模块化单体架构的？
极客时间编辑部
讲述：丁婵大小：1.78M时长：03:52
最近，Shopify 高级工程师科尔斯顿·威尔丁（Kirsten Westeinde）在 Shopify Unite 2019 大会上讨论了 Shopify 向模块化单体架构的演变。这包括使用设计收益线（ design payoff line ）来决定何时进行此更改，如何实现更改，以及为什么将微服务排除在目标架构之外。
一个关键的结论是，单体不一定是一个糟糕的架构，它具有许多优点，比如单个测试和部署管道。在项目开始时，当必须快速交付新特性时，这一点特别有用。只有在跨越了“设计收益线”时，也就是糟糕的设计阻碍特性开发的那一点，才应该开始改进架构。
就 Shopify 而言，改进其架构并不意味着转向微服务，而是转向模块化单体架构。这结合了单体（例如单个测试和部署管道）和微服务（例如代码模块化和解耦）的优点。
威尔丁认为，单体架构是一个很好的项目起点，她建议新产品和新公司开始时使用单体架构。同时，她列举了其中的一些优点：
一个项目包含所有代码；
只有一个代码库，测试和部署都很简单；
所有数据都可用，无需跨服务传递；
一组基础设施。
由于这些优点，Shopify 一开始只是一个小型的 Ruby on Rails 单体，随着时间的推移，逐渐发展成为一个非常大的代码库。当这种情况发生时，它意味着 Shopify 开始变得不可维护，并且因此很难交付新特性。例如，更改一段代码会对看似无关的代码造成意想不到的副作用，并且构建和测试应用程序花费的时间太长。
威斯丁援引 Martin Fowler 的设计耐力假说（ design stamina hypothesis ）解释道，是时候重构他们的架构了，一旦功能开发被糟糕的设计所阻碍，设计收益线就会被跨越，这意味着投入资源来修复它是有意义的。
最初，Shopify 将微服务视为一种可选的、更易于维护的架构。然而，由于分布式系统的复杂性，它被排除在外，取而代之的是更易于维护的单体架构。威斯丁称，他们意识到他们的设计目标是提升系统的模块化，比如使用微服务，同时保持一个单一的可部署单元，像一个单体。为了实现这一点，Shopify 采用了模块化的单体模式。这使得代码之间有了边界，但要使代码都在同一个位置并且部署到同一个位置。迁移路径如下：
代码重组：最初，代码的组织方式类似于典型的 Rails 应用程序，顶层部件以技术组件命名，如控制器。这被更改为基于业务功能进行组织，如“账单”和“订单”，从而更容易定位代码。
隔离依赖关系：每个业务组件彼此隔离，然后通过公共 API 供外部使用。他们内部开发了一个名为 Wedge 的工具，它跟踪每个组件的隔离情况。它构建一个调用图，然后计算出哪些调用（比如跨组件的调用）违反了规则。
强制边界：一旦每个组件都实现了 100% 的隔离，它们之间就有了强制的边界。其思想是，当代码试图访问它没有显式依赖的组件的代码时，就会出现运行时错误。以这种方式声明依赖关系也将使它们在依赖关系图中可视化。
最后，威斯丁表示，良好的软件架构是一项不断演化的任务，而应用程序的恰当解决方案完全取决于你的操作规模。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
精选留言
由作者筛选后的优质留言将会公开显示，欢迎踊跃留言。
收起评论