公司 ricardo.ch 地点 Zurich, Switzerland 行业 电子商务

挑战

ricardo.ch,一家瑞士在线市场,当时正面临着速度方面的挑战,以及开发和运维之间“经典的鸿沟”,双方难以良好协作。“他们想要协作,但缺乏共同基础,”平台工程主管 Cedric Meury 说。“这是拖慢我们速度的根本原因之一。” 公司开始将遗留的单体巨石分解为微服务,并需要编排技术来支持其自有数据中心的新架构——同时也将开发和运维团队整合起来。

解决方案

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

影响

将单体巨石分解为微服务“带来了更高的速度,Kubernetes 对此提供了至关重要的支持,”Meury 说。生产环境部署次数从每周不到 10 次增加到每天 30-60 次。Meury 说,以前,“当生产环境出现问题时,工单或投诉就会被甩给运维团队,这是经典问题。现在,由于一切都以标准化的方式部署,人们有机会先查看运维情况并自行进行故障排除。” 他在日常互动中看到了影响:“几周前,我看到一位产品经理为一个包含某些变量的 JSON 文件提交了 pull request,另一个人接受了它。仅仅几分钟甚至几秒钟后,它就被部署了,这在以前是不可想象的。以前需要经过一连串的步骤,整个单体应用即使对工程师来说也难以理解。因此,以前的请求会进入庞大、低效的看板,然后可能需要数周甚至数月才能有人完成更改。” 以前,基础设施和平台相关的项目需要数月或数年才能完成;现在,开发人员和运维人员可以协作,通过 Kubernetes 在几周甚至几天内部署基础设施组件。从长远来看,公司还预计从定制数据中心和虚拟机迁移到容器化基础设施和云服务将节省 50% 的成本。

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

“那是这些部门之间经典的隔阂,甚至偶尔还有一些愤怒和沮丧,”Meury 说。“他们想要协作,但缺乏共同基础。这是拖慢我们速度的根本原因之一。”

这种隔阂损害了 ricardo.ch 这个瑞士在线市场的速度。该网站在高峰日处理来自网页和移动应用的多达 260 万次搜索,通过其实时拍卖服务着 320 万会员。Meury 说,技术团队的主要挑战是确保“物品的竞价以正确的顺序到达,并在拍卖结束前完成,并且这种方式运作公平。” “我们有实时性要求。我们还提供自动化竞价系统,它需要准确无误。对于分布式系统,你需要确保顺序正确。这是我们目前正在处理的事情之一。”

为了解决速度问题,ricardo.ch 的 CTO 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。Meury 说:“我们仍然在自己的数据中心运行一些服务器,但所有的容器化工作以及将我们的服务描述为 Kubernetes 清单,将使我们能够相当容易地完成这次转变。”

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

Meury 也在日常互动中看到了影响:“几周前,我看到一位产品经理为一个包含某些变量的 JSON 文件提交了 pull request,另一个人接受了它。仅仅几分钟甚至几秒钟后,它就被部署了,这在以前是不可想象的。以前需要经过一连串的步骤,整个单体应用即使对工程师来说也难以理解。因此,以前的请求会进入庞大、低效的看板,然后可能需要数周甚至数月才能有人完成更改。”

开发和运维之间的隔阂也减少了。Meury 说:“几个月后,有人向我提出请求,说,‘嘿,你能帮我安装 Kubernetes 客户端吗?我想亲自看看正在发生的事情。’ 人们直接查看系统状态,使他们与运维工作更近、更近。” 以前,基础设施和平台相关的项目需要数月或数年才能完成;现在,开发人员和运维人员可以协作,通过 Kubernetes 在几周甚至几天内部署基础设施组件。

洞察系统状态的能力也扩展到了公司的其他部门。Meury 说:“我发现我们的一位客户支持代表会查看 Grafana 指标来了解系统是否运行正常,这太棒了。” “Prometheus 直接与客户服务关联。”

ricardo.ch 的云原生之旅也许对运维团队影响最大。Meury 说:“我们的运维团队拥有硬件背景,而现在他们正在重新学习如何在更虚拟化和云原生的世界中工作,迄今为止取得了巨大成功。” “因此,除了仍在管理本地数据中心防火墙外,他们同时还在学习使用 Go 语言编程或进行一些 Python 脚本编写。以前的网络管理员正在编写 Go 代码。这简直太酷了。”

对 Meury 来说,这段旅程归结起来就是这样。Meury 说:“我的一位同事听了 KubeCon 的所有演讲,他对所有那些工具、技术、框架——那些目前在我们的平台中缺失的——感到目不暇接,但同时,他也非常高兴地知道将来还有这么多我们可以探索、改进和努力的事情。我们正在从到处看到问题——比如,‘这个坏了’或‘这个宕机了,我们必须修复’——转变为思考‘我们如何才能真正改进和实现更多自动化,并让开发人员和最终用户感到更满意?’”