拒绝 Shopify 的微服务:他们做了什么

一则或许对你有用的小广告

欢迎加入小哈的星球 ,你将获得:专属的项目实战 / Java 学习路线 / 一对一提问 / 学习打卡/ 赠书活动

目前,正在 星球 内带小伙伴们做第一个项目:全栈前后端分离博客项目,采用技术栈 Spring Boot + Mybatis Plus + Vue 3.x + Vite 4手把手,前端 + 后端全栈开发,从 0 到 1 讲解每个功能点开发步骤,1v1 答疑,陪伴式直到项目上线,目前已更新了 204 小节,累计 32w+ 字,讲解图:1416 张,还在持续爆肝中,后续还会上新更多项目,目标是将 Java 领域典型的项目都整上,如秒杀系统、在线商城、IM 即时通讯、权限管理等等,已有 870+ 小伙伴加入,欢迎点击围观

Codeship 参加了 DockerCon 2015 !这是我们在旧金山举行的为期两天的会议上参加的演讲。如果您对 Codeship 的 Docker 支持感兴趣, 请单击此处

Simon Eskildsen 在 DockerCon 上谈到了 Shopify 如何找到一个简单的基础设施解决方案,该解决方案允许大规模的分布式和弹性路由和发现系统。

作为 Shopify 的基础架构工程师,Eskildsen 向听众解释说,Shopify 拒绝复杂服务发现协议和分布式微服务的传统概念。相反,他们使用通过 DNS 发现的更大、有弹性的应用程序。

Simon Eskildsen 在 DockerCon 2015

微服务并不能解决所有问题

Eskildsen 强调,首先,微服务并不是构建每个基础设施的最终解决方案。他指出,应用程序的弹性要重要得多。由微服务组成的分布式应用程序可能容易受到攻击。

他建议看一看他所谓的弹性成熟度金字塔。可以将测试应用于您的应用程序,增加严重性以测试弹性级别。金字塔应该随着基础设施的增长而攀升,如下图所示。

Eskildsen 表示,应用程序的一个关键指标应该是弹性,而不是可读性、关注点分离、粒度可扩展性或微服务的任何主要参数。应用程序的设计应该有点经验,而不是任意设计。

那么 Shopify 不使用微服务也许就不足为奇了。相反,Eskildsen 说公司使用的应用程序更少,但更大。

专注于发现

Eskildsen 说,发现是您的基础设施的服务、元数据和编排的真实来源。

您应该考虑该方法的目标是区域发现还是全球发现,但无论如何,发现主干应具有以下特征:

  • 没有单点故障
  • 过时读取 > 无读取
  • 读取比写入大一个数量级
  • 快速收敛

Eskildsen 指出,服务发现通常过于复杂。 DNS 即服务发现协议适用于大多数用例。出于以下几个具体原因,Shopify 决定使用 DNS 实施服务发现:

  • 它有弹性
  • 这很简单
  • 在大多数情况下它具有 API 访问权限
  • 全球支持

使用 DNS 的决定也部分基于等待 Docker 发布类似 Docker 网络的东西, 它于上周一宣布

话虽如此,Eskildsen 周一的演讲概述了针对一个相当具体问题的具体解决方案。许多 Codeship 用户将通过简单的 Docker 组合堆栈进行测试,不需要触及任何更复杂的东西,比如开箱即用的服务发现。就容器而言,微服务非常适合许多较小的服务,而不是较少的较大服务。

当然,Eskildsen 关于放慢速度和考虑简单解决方案的主要观点将始终适用于任何基础设施设计。

幻灯片