在 Gilt 公司尝试使用微服务技术三年以来,我们可以看到一些明显的优点,体现在团队自主权、由API 定义边界、将复杂的问题分解为较小的问题等方面。不过,在工具的支持、集成环境和监控方面,还存在着诸多挑战。 Yoni Goldberg 在 QCon 伦敦大会上的一场演讲中,为听众介绍了他们在转向微服务架构时所遇到的各种挑战。
Gilt 是一家做限时抢购业务的公司,Goldberg 是该公司的首席软件工程师,他为我们介绍道:Gilt 是一家于2007 年成立的典型的创业公司,刚开始时使用的技术是 Ruby on Rails 。仅两年之后,他们就需要在系统中运行几千个 ruby 进程,并且数据库也开始显得不胜负荷。
从那时起,他们转为使用 JVM 技术,并且开始了一个 Goldberg 称之为宏观 / 微观服务的时代,他的观点是,宏观服务更多地是针对某个特定的领域,例如销售或支付。而微服务是指将宏观服务分解为较小的服务。他们也为这些服务引入了专用的数据存储系统。他们首先为核心业务创建了 10 个宏观服务,这些服务目前还在应用中,同时也是其它所有服务所依赖的核心。使用这些核心宏观服务的是一系列的支持性服务,例如用户偏好服务,这些服务不是必不可少的,也不会由于这些支持性服务的故障使你的整个业务停顿下来。在这些服务之上,还有另一套服务,负责为所有用户创建视图。这套新的架构解决了 99% 的可伸缩性方面的问题,但也带来了一些其它问题。开发者在使用新服务的过程感到系统缺乏整体性,而且在代码方面缺乏清晰的自主权。其它的问题还包括部署、以及过长的整合周期。
为了克服这些问题,他们增加了微服务的数量,并且为团队授予了更大的权力,让他们不仅负责开发服务,同时也负责测试、部署和监控。这也同时澄清了自主权,基本上一个团队会负责一个服务。对于 Goldberg 来说,这套方案的最大优势在于每个微服务的范围减小了,因此变得更易于理解与探究。同时,他们通过将网页分解为较小的片段,生成了许多小型的 web 应用程序。(LOSA)
这些微服务之间产生了大量的内部依赖。在 Goldberg 看来,开发者所面对的最大挑战就是,对于每个变更,都需要确保不会因此造成其它服务的故障。如果某个变更是破坏性的,那就需要在多个小步骤中完成整个过程,在变更完成后,所有的客户端必须转为使用新的终结点,之后才可以删除旧的终结点。他们所经历过的一个问题是,许多 web 应用程序都在进行相同的方法调用,例如创建某个用户档案。为了克服这一点,他们创建了一种 Goldberg 称之为中间微服务的东西,这个服务知道要创建用户档案需要进行什么样的方法调用,web 应用可以根据这一信息进行正确的调用。
Goldberg 所提到的最后一项挑战是数据的归属。由于他们转向了每个微服务一个数据库的方式,因此生产了大量的小型数据库。他们需要找到某种方式,以管理每个数据库的 schema。他们选择了在某个关系型数据库中进行管理,并且使用了版本系统以跟踪它们的变更。
评论