Zendesk与微服务维护的艺术
挑战
Zendesk 是用 MySQL 数据库建立的单体 Rails 应用程序，在公司自有硬件上的共址数据中心中运行。但随着公司规模扩大，“我们意识到：把越来越多的东西塞到一个单体 Rails 上会拖慢团队的速度，”高级总工 Jon Moter 说：“部署真的很难，风险也很大。”公司决定搬到微服务和容器上，但还是要找到一个能够顺利实施的方法。
解决方案
团队在2015年中旬的时候研究了协调技术，Moter 说：“Kubernetes 似乎就是为解决我们的问题而来。Google 对容器略知一二，所以他们的态度是‘就这样吧，我们就赌这一次。’”
影响
如今，Zendesk 大约70%的应用程序都是在 Kubernetes 上运行的，所有的新应用都会在 Kubernetes 上运行。它给 Zendesk 节省了时间，带来了更大的灵活度和更快的速度。以前，变更一款应用的资源组合“简直头大，”Moter 说：“最快也得花费几天时间才能把硬件换好。”但在 Kubernetes，用团队自己开发的简易 UI，一、两分钟就能搞定。
一些数据
改变资源组合不再需要数日时间，只需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 说：“不论从哪方面看，都让人感到振奋鼓舞。”