Ancestry.com的Docker之路以及最终为何选择Kubernetes


【编者的话】容器泛型的提出对软件的部署意义深远,新的软件架构选择Docker之路相对轻松,但是对于老牌的非Linux背景技术公司来说,这并非易事。Ancestry是一个传统的在线数据公司,并且以前是以.net底层为基础,这样的转型更是困难。下文是Ancestry工程师介绍他们的Docker转型之路,以及最终为何选择Kubernetes。
000.jpg

Ancestry.com的软件工程师Paul MacKay在最近的微服务虚拟峰会(Microservices Virtual Summit)上发表了演讲,他提出了一些关于容器使用的问题,以及面对变化,他们如何升级技术架构栈。

Ancestry是一个具有200亿浏览记录、9000万独立的家谱树形数据、涉及100亿用户详细信息的站点。站点保存了40万会员的信息,包括1750万被分享的照片、文档、故事等记录。这些信息数据加起来超过9PB。

我们现在一共有9个集群分别部署在本地和AWS服务。在生产环境集群中,我们有好几百个节点(node)、成千上万的独立服务和数以千计的运行在Docker和Kubernetes的pods。

1996年我们开始转型互联网在线业务,并保持3-4人的团队规模。一开始我们从微软的C#和.NET技术栈起步。随着时间的推移,我们从.NET 、SQL Server和IIS开始向开源社区的Java、Node.js、Python等以Linux为基础的技术迁移。
111.png

但是,三年前当我们在一个会议上见到Docker的演示时,他们通过增加容器的组合改造了应用运行的环境,这就创造了需要改变他们想要运行堆栈的方式。

他说:“我们能够向管理层证明,部署和扩展这些服务成本不高,部署时间也会减少。”迁移到Docker也使他们能够更有效地利用我们的计算资源。

坎坷的道路

首先,采取新的技术相当困难。他说,Ancestry的开发工程师并不在于开发新的基础架构,而是要为客户开发新功能。必须要认识到一点:采用新技术将占用为用户开发新功能的资源。

他解释说:由于是新技术,所以这可能具有很大的风险性。因此,为什么新技术在关注点、资源、成就上是值得优先去做,为什么要先避开新特性需求的开发,这一点必须要让高层管理人员相信。

他说:“有一个全力支持的领导至关重要,他不仅能给你提供你需要的时间和资源,而且还能给你提供实验机会、新尝试的能力。” 这个人应该是一个了解可能这样做会失败,但是还是允许尽力这样尝试的人。

同时,你需要聚拢从事这方面工作的人,McKay解释说。在Ancestry,他们创建了试点小组推出新的微服务技术。这些团队不只是创造POCs(概念验证),它们同样也具有多种多样的解决实际问题的能力。

我的建议

“如果这个团队组建不成功,我们可以通过给予团队额外的支持改变这个过程,比如先从不断的团队培训开始。”他说。

McKay说,当他们准备开启微服务技术的升级改造时,他们有很多Windows开发人员开始接触Linux,他们在容器或编排方面毫无经验。为了能够胜任工作,所以他们需要接受培训。 不仅仅是工具使用的培训,而且还包括如何将服务分解成更小的块的概念和范例。 培训的目标是使他们适应新技术并且有能力采用新技术。

然后,他们提供了帮助快速部署任何规模的服务的工具。 这些工具适用于所有集群,并为新的和有经验的开发人员提供约定和最佳实践。
333.png

当你采用新技术时,你就必须不断地认真学习使用它。 必须敏捷地面对所有的需求,这个过程会偶有错误,但是没关系。 只要确保团队知道:他们需要一起工作,而且他们目标是相互成功。

回到技术

从哪个服务开始动工是他们项目开始要决策的事情。 McKay解释说,这需要从很多方面权衡,例如网络延迟,监控和协调所有这些服务的部署。 他补充说:“管理服务是有成本的,这些都不会是免费午餐”。

他说:“你需要了解如何扩展技术变更的规模 ,你需要升级整个微服务,还是只懂一个子集? 这是一次性全部变更吗? 这些原有的服务是否还有存在的意义? 这对整个生态是否还有用?“

服务的粒度最好是让开发自己决定。 “我们建议,最简单的途径就是让开发者评估容器化应用,然后自己决定服务的粒度的大小以及如何解耦。”他解释说。

运行微服务

他们开始使用Docker,并且构建了自己的Linux发行版和CoreOS。当他们看到测试版的Kubernetes演示文稿时,McKay就直接绕过其他的编排工具来支持新技术。

他为自己的试点小组创建了一个小型的Kubernetes沙盒,试点小组致力于拆分服务,并尝试使用Kubernetes进行容器化部署。

他们每天举行站立会议,以确保问题得到迅速的解决。 “有一些困难的问题要解决,”他说。 “可解决的问题......但有些问题非同一般,非常困难。”

除了参加培训外,他们还创建了最佳实践,并构建了模板和脚本,以帮助开发人员开始如何拆分服务,然后使用容器进行部署,并使用Kubernetes进行编排,McKay解释说。

从REPL到CDEL

McKay说,程序员都熟悉REPL环境(读取,评估,打印和循环)流程。而在Kubernetes中流程更改为编译,部署,执行然后循环(CDEL)。 “这意味着,我们已经排除了部署协调的障碍,也不再需要尝试各种空间和解耦。 那么现在你可以真正编译,可以得到它的部署信息,可以查询它在环境中位置,然后你也可以评估出哪些是可行的,哪些不是。

制定标准

在开展微型服务生产的一年半以后,他们制定了一些部署标准。
  • 参照Kubernetes约定,他们为每个服务创建一个命名空间,无论服务大小,使用一个命名约定(functionalgroup-servicename)。
  • 每个pod里都有一个容器在生产环境中。
  • 无论大小,每个服务都有自己的存储库。
  • 他们使用Prometheus来监视服务,确保SOA一致。
  • 允许开发人员部署发布到生产环境,根据需求给予足够得权限。
  • 他们为每个开发、阶段和生产环境创建单独的集群。
  • 他们运行自定义集群的日志记录,可以创建命名空间。
  • Kubernetes在多维数据集DNS中使用了一个集群内的DNS服务器,在部署微服务时发现了一个服务发现,这大大减少了网络延迟。
  • 无论大小,每个服务都需要一个CPU和内存配额。开发人员可以根据自己的需要准备配置。


原文链接:Ancestry.com’s Docker Story and How It Eventually Led to Kubernetes(翻译:ylzhang)

0 个评论

要回复文章请先登录注册