转载

一种现代化的微服务架构

在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。他们选择了在某个关系型数据库中进行管理，并且使用了版本系统以跟踪它们的变更。

可以在这里下载到Goldberg的演讲幻灯片，演讲的视频将在今后几个月之内发布到InfoQ网站上。

查看英文原文： A Modern Microservices Architecture

正文到此结束