公司 ricardo.ch 地点 瑞士苏黎世 行业 电子商务

挑战

瑞士在线市场 ricardo.ch 在速度方面遇到了问题,并且开发和运维之间存在“经典的隔阂”,双方无法很好地协同工作。“他们想协同工作,但他们没有共同的基础,”平台工程主管 Cedric Meury 说。“这是导致我们速度减慢的根本原因之一。”该公司开始将遗留的单体应用分解为微服务,并且需要编排来支持其自身数据中心中的新架构,同时还需要将开发和运维人员聚集在一起。

解决方案

该公司采用了 Kubernetes 进行集群管理,Prometheus 进行监控,以及 Fluentd 进行日志记录。第一个集群于 2016 年 12 月在本地部署,第一个服务在三个月后投入生产。迁移工作大约完成了一半,该公司计划在 2018 年底前完全迁移到 Google Cloud Platform

影响

将单体应用分解为微服务“提高了速度,而 Kubernetes 对此至关重要,”Meury 说。生产环境的部署次数已从每周不到 10 次增加到每天 30-60 次。以前,“当生产环境中的某些东西出现问题时,工单或投诉会被扔给运维部门,这是一个经典问题。现在,人们有机会首先自行查看运维并进行故障排除,因为一切都以标准化的方式部署,”Meury 说。他看到了日常互动中的影响:“几周前,我看到一位产品经理为包含一些变量的 JSON 文件提交了一个拉取请求,另一个人接受了它。甚至在几分钟或几秒钟后就部署了,这在以前是不可想象的。以前需要很多环节才能完成,整个单体应用很难理解,即使是对于工程师来说。因此,以前的请求会进入庞大而低效的看板,并希望有人会在几周或几个月后完成更改。”以前,与基础设施和平台相关的项目需要几个月甚至几年的时间才能完成;现在,开发人员和运维人员可以协同工作,在几周甚至几天内通过 Kubernetes 部署基础设施部件。从长远来看,该公司还希望通过从自定义数据中心和虚拟机转变为容器化基础设施和云服务来实现 50% 的成本节约。

2016 年 Cedric Meury 加入 ricardo.ch 时,他看到了运维和开发之间存在明显的分歧。事实上,他们之间存在实际的距离:工程团队在法国工作,而该组织的其他部门则位于瑞士。

“这些部门之间存在经典的隔阂,甚至时常出现一些愤怒和挫败感,”Meury 说。“他们想协同工作,但他们没有共同的基础。这是导致我们速度减慢的根本原因之一。”

这种隔阂损害了 ricardo.ch 的速度,ricardo.ch 是一个瑞士在线市场。该网站在高峰期每天处理高达 260 万次的搜索,来自网络和移动应用程序,为 320 万会员提供实时拍卖。技术团队的主要挑战是确保“商品的竞价以正确的顺序到来,并在拍卖结束之前到达,并且以公平的方式进行,”Meury 说。“我们有实时要求。我们还提供一个自动竞价系统,它需要准确无误。对于分布式系统,您面临的挑战是确保排序正确。这是我们目前正在处理的问题之一。”

为了解决速度问题,ricardo.ch 首席技术官 Jeremy Seitz 成立了一个名为 EPD 的新软件工厂,该工厂由 65 名工程师、7 名产品经理和 2 名设计师组成。“我们把这三个部门聚集在一起,以便他们能够理顺流程,并进行更紧密的交流,”Meury 说。

该公司还开始将遗留的单体应用分解为 100 多个微服务,并且需要编排来支持其自身数据中心中的新架构。“分解单体应用提高了速度,而 Kubernetes 对此至关重要,”Meury 说。“Kubernetes 的容器化和编排帮助我们大大减少了开发和运维之间的冲突,也使我们能够站在同一立场上使用相同的语言。”

Meury 组建了一个平台工程团队来选择工具(包括用于日志记录的 Fluentd 和用于监控的 Prometheus,以及 Grafana 可视化),并为第一个 Kubernetes 集群奠定了基础,该集群于 2016 年 12 月在本地安装。几周内,新平台可供团队使用,并为他们提供培训课程和文档。然后,平台工程团队与工程师合作,帮助他们在新平台上部署他们的应用程序。第一个投入生产的服务是 ricardo.ch 的招聘页面。“这是一个前端开发的练习,因此开发人员可以使用新的堆栈进行实验,”Meury 说。

Meury 估计,一半的应用程序已迁移到 Kubernetes。计划在 2018 年底前将所有内容迁移到 Google Cloud Platform。“我们仍然在我们自己的数据中心运行一些服务器,但是我们所有的容器化工作以及将我们的服务描述为 Kubernetes 清单将使我们能够非常轻松地进行这种转变,”Meury 说。

影响是巨大的。从自定义数据中心和虚拟机迁移到容器化基础设施和云服务预计将为公司节省 50% 的成本。生产环境的部署次数已从每周不到 10 次增加到每天 30-60 次。以前,“当生产环境中的某些东西出现问题时,工单或投诉会被扔给运维部门,这是一个经典问题,”Meury 说。“现在,人们有机会首先自行查看运维并进行故障排除,因为一切都以标准化的方式部署。这减少了时间和不确定性。”

Meury 还看到了日常互动中的影响:“几周前,我看到一位产品经理为包含一些变量的 JSON 文件提交了一个拉取请求,另一个人接受了它。甚至在几分钟或几秒钟后就部署了,这在以前是不可想象的。以前需要很多环节才能完成,整个单体应用很难理解,即使是对于工程师来说。因此,以前的请求会进入庞大而低效的看板,并希望有人会在几周或几个月后完成更改。”

开发和运维之间的分歧也减少了。“几个月后,我收到一些人的请求,他们说,‘嘿,你能帮我安装 Kubernetes 客户端吗?我想实际看看发生了什么,’”Meury 说。“人们直接查看系统的状态,使他们与运维部门更加紧密地联系在一起。”以前,与基础设施和平台相关的项目需要几个月甚至几年的时间才能完成;现在,开发人员和运维人员可以协同工作,在几周甚至几天内通过 Kubernetes 部署基础设施部件。

对系统的洞察能力也扩展到了公司的其他部门。“我发现我们的一位客户支持代表会查看 Grafana 指标,以了解系统是否运行良好,这太棒了,”Meury 说。“Prometheus 直接连接到客户服务。”

ricardo.ch 的云原生之旅可能对运维团队的影响最大。“我们的运维团队来自基于硬件的背景,现在他们正在重新学习如何在更加虚拟化和云原生的世界中进行操作,到目前为止取得了巨大的成功,”Meury 说。“因此,除了仍然操作本地数据中心防火墙之外,他们还学习用 Go 编写代码或同时进行一些 Python 脚本编写。以前的网络管理员正在编写 Go 代码。这真的很酷。”

对于 Meury 来说,这一旅程可以归结为以下几点。“我的一位同事在 KubeCon 上听了所有的演讲,他被我们平台上目前缺乏的所有工具、技术和框架所淹没,”Meury 说。“但与此同时,他很高兴知道未来我们仍然有很多可以探索、改进和努力的方向。我们正在从到处看到问题(例如,‘这个坏了’或‘这个宕机了,我们必须修复它’)过渡到‘我们如何真正改进和自动化更多,并使开发人员最终为最终用户提供更好的体验?’。”