KubeCon + CloudNativeCon North America Virtual | November 17-20, 2020 | Don’t Miss Out | Learn more

Zendesk与微服务维护的艺术

挑战

Zendesk 是用 MySQL 数据库建立的单体 Rails 应用程序,在公司自有硬件上的共址数据中心中运行。但随着公司规模扩大,“我们意识到:把越来越多的东西塞到一个单体 Rails 上会拖慢团队的速度,”高级总工 Jon Moter 说:“部署真的很难,风险也很大。”公司决定搬到微服务和容器上,但还是要找到一个能够顺利实施的方法。

解决方案

团队在2015年中旬的时候研究了协调技术,Moter 说:“Kubernetes 似乎就是为解决我们的问题而来。Google 对容器略知一二,所以他们的态度是‘就这样吧,我们就赌这一次。’”

影响

如今,Zendesk 大约70%的应用程序都是在 Kubernetes 上运行的,所有的新应用都会在 Kubernetes 上运行。它给 Zendesk 节省了时间,带来了更大的灵活度和更快的速度。以前,变更一款应用的资源组合“简直头大,”Moter 说:“最快也得花费几天时间才能把硬件换好。”但在 Kubernetes,用团队自己开发的简易 UI,一、两分钟就能搞定。

使用的CNCF项目

Kubernetes

改变资源组合不再需要数日时间,只需1-2分钟

出现中断,几分钟即可自行修复,修补不再需要数个小时

70%应用程序在Kubernetes上运行

2007年上线,目标是帮助机构组织便捷地使用客户服务。Zendesk 提供的产品包括实时信息、语音聊天和数据分析。

所有的产品和服务都在单体 Rails 应用上提供,该应用程序利用 MySQL 数据库,在公司自有硬件上的共址数据中心中运行。

最初的7年中,系统运行良好。但随着 Zendesk 日益壮大,2014年上市,目前已有145,000个付费账号和3,000名员工,显然需要我们对基础设施进行改造,这就需要我们开始使用微服务、容器和 Kubernetes。

“我们意识到:把越来越多的东西塞到一个单体 Rails 上会拖慢团队的速度,高级总工 Jon Moter 说:“部署真的很难,风险也很大。Zendesk 的团队散布在全球各地,但所有工程设计室都被捆绑在同一个应用上。”

转向微服务是一个符合逻辑的做法。但在当时,我们仍有一个中心运维团队,“资源供给效率非常低下,”他说:“要建立、部署一项服务,通常需要提前一个季度提出硬件需求。”此外,“大量” Chef 逻辑用于配置服务器,“登台环境和生产环境大不相同,因为网络不同,一个在 AWS 上,另一个在数据中心,”Moter 说:“很多不一致的情况。”

有些团队最后提出把代码放在一起,或者“最后形成几个小型单体,映射到办公室所在的单体应用里。”他补充说。

2014年底,Zendesk 高级技术工程师开始研究寻找一个更好的解决方案。他们迅速决定采用 Docker 容器,随后便开始了长达6个月的微服务最佳实践研究,探索在 Zendesk 应用的有效方法。

Moter 团队制作了一套称为“ ZDI ”(Zendesk Docker 集成)的工具。这套工具能帮助开发者瞬间建立容器。但“我们不希望 Docker 树立起一个仅限开发者使用的形象;我们希望也能把它们用于登台和生产环境,”他说:“我们开始创建一个在节点上运行的最小代理,依据 Consul 键值存储中的数值运行 Docker 容器。但后来我们意识到这是在建自己的编排器,这好像并不是一个好办法。”

“在2015年夏天的时候,编排只有几个选项,”Moter 说:“Kubernetes 似乎就是为解决我们的问题而来。Google 对容器略知一二,所以他们的态度是‘就这样吧,我们就赌这一次。’”

Moter 和自己的小团队获批研究怎样利用 Kubernetes 改进 Zendesk。实现集群在生产中运行用了差不多一年时间(期间,公司也从数据中心迁移到了大约15个在 AWS 的集群中)。2017年初,第一个有真实客户流量的应用在 Kubernetes 部署成功。第一批客户对我们的成果热情满满,良好的口碑促进了更多的应用。如今,Zendesk 大约70%的应用程序都是在 Kubernetes 上运行的,所有的新应用都会在 Kubernetes 上运行。

为了帮助开发者,Moter 团队进一步强化了开源部署工具,也就是Zendesk使用的 Samson。“现在 Samson 直接连接到各个 Kubernetes 集群,读取你们 GitHub repo 里的YAML文件,然后做一点转化,” Moter 说。

“Kubernetes 似乎就是为解决我们的问题而来。”

— ZENDESK 高级总工 JON MOTER

比如说,如果生产和登台环境中的复本数量或 CPU、RAM 数量不同,在 Samson 的 UI 里面就可以调整,Samson 会在发给 Kubernetes API 之前做出修改。

以前,变更一款应用的资源组合“简直头大,” Moter 说:“最快也得花费几天时间才能把硬件换好。”但在 Kubernetes,我们可以进入 Samson,扩展复本数量,微调 CPU 和 RAM,点击重新部署,只消一两分钟,就可以运行完全不同的资源组合了。

Kubernetes 也在其他方面节省了 Zendesk 的时间。

最近 AWS 出现故障,造成大量 EC2 问题,导致一个域的可用性区域突然中断。Zendesk 在 EC2 上运行 Kubernetes 和非 Kubernetes 任务。“Kubernetes 基本可以在几分钟内自行修复,不需要任何人为介入,” Moter 说:“而大量在 Kubernetes 以外运行的其他应用,就需要团队进行人工修补了。”

这些改进“给了团队更大的灵活性,” Moter 说:“团队开发和部署微服务时要简单易行,就要让他们能够按照自己的想法选择频繁或不频繁地进行部署。微服务推论更简单,验证测试通过也更容易,能够更快捷地加速和减速,这样团队就能更加快速地完成任务了。”

“这么多公司,彼此要么是竞争对手,要么来自不同的行业,大家相互协作、共享最佳实践、携手合作,不论从哪方面看,都让人感到振奋鼓舞。”

— ZENDESK 高级总工 JON MOTER

共用的编排平台也能让团队更容易得到统一的工具、统一的监督,还有更容易预测控制面板,Moter 补充说道:“这样就能简化参与人员的工作,让他们遵守标准模板类别,设置监控器,用一种比较统一的方法发出警报。同时,平台也能帮我们处于随时在线的状态。我们的办公室遍布世界各地,因此对于随时待命的人来说,我们24小时都有其中一间办公室是白天。”

随着云原生生态系统越来越复杂,Moter 的团队也开始使用内部的“平台作为一项服务(Platform as a Service)”。这是一个简化的界面,能够用于大多数团队80%的使用案例。“期待每个开发团队都能全面了解 Istio、Kubernetes 和网络,还有……是非常多,”他说。(如果你们对这些感兴趣的话,他补充说,我们正在招聘。)

对于其他想要使用 Kubernetes 的单位,Moter 给出了自己的建议:“Kubernetes 很好,但这个系统比较复杂。需要单位内部有一部分员工充分了解 Kubernetes,还需要大范围的员工至少了解一点点 Kubernetes 的知识。不能仅依靠外包单位去了解所有知识,然后就想当然认为一切工作都能顺利完成。我们需要形成一个学习曲线。”

同样,Moter 补充说:“先尝试几个小型应用,然后再开始最大规模的应用。可能开始会感觉很担心,但只要最终证实 Kubernetes 能在一个更加重要的应用上顺利运行时,你就会信心倍增。不要凭空等待,抓紧时间找到解决最大、最棘手问题的方法,趁一切都不太晚。”

着手工作之后,如果遇到解决不了的问题,总有我们的社区。“这么多公司,彼此要么是竞争对手,要么来自不同的行业,大家相互协作、共享最佳实践、携手合作,” Moter 说:“不论从哪方面看,都让人感到振奋鼓舞。”