在过去的几个月里,我们已经听到很多关于微服务的优缺点了。微服务真的只是SOA 吗? 微服务确实有助于进行复杂系统架构吗?不论大家怎么说,有一些公司已经转向或正准备转向基于微服务的方法了。他们在实践过程中分享自己获得的正面或负面的经验,是很自然的事。最近, Droplet 公司的 Tom Livesey 分享了他们的经验。为了给讨论增添一些背景信息,Tom 首先介绍了 Droplet 的需求:
就像很多初创公司希望快速推出初始产品一样,刚开始我们用一个单片 Rails 应用来处理从支付到推送通知在内的所有功能。尽管当时还不需要扩展规模,但我们想,如果把一些功能分离出来,也许有好处。于是,我们逐渐分离出了一个个的功能,现在我们有 20 个服务,他们大多采用 Sinatra 或 Go。
Tom 的文章谈到了他们在开发过程中获得的七点经验教训。
别做太多:微服务的“微”字是关键。我觉得,在关于代码规模与行数方面,没有硬性规定;你要认真考虑的是,服务做的是什么,功能是否精简且具有良好的定义。
这一点是值得注意的,因为我们已经听到,有些人认为微服务就一定要规定代码量,它们甚至进一步考虑新建一个术语,叫纳米服务。接着,Tom 提到,他们决定把所有能发布的都发布出来:
为了处理异步事件(比如发送电子邮件和推送通知),有必要采用某种消息队列机制,从而允许其他服务来侦听某些事件,并做出相应的响应。[…] 我们的原则是,不论一个功能对系统中的其他部分来说有多么讨厌或多么微不足道,能发布就发布出来。发布(publishing)相当容易,发布者不用关心有多少订阅者对这个事件感兴趣,只需触发,其他都不用管。这一点非常强大,令微服务能够以极快的速度被构建与部署。
关于微服务与数据,Tom 这样描述:
在我们构建新版 Droplet 时,我们花费几周时间增添了大约 10 个新服务。[…] 该服务侦听所有的账户更新事件,并对自己的数据做出相应更新。各个服务应该有自己的数据存储,在服务之间分享数据库不是一个好的做法;不过,缓存来自其他服务的数据是没问题的,只要有机制能保证缓存数据是最新的。
在过去的几年里,有关 SOA 与契约的讨论已经很多了。无论是契约成熟度模型、契约版本化或 SOA 模式,这些年来,契约一直是 SOA 开发(包括 Web 服务,REST 或其他实现方法)中的重要部分。Tom 也谈到了契约的重要性:
更改服务接口,意味着所有使用它的服务都要修改。受影响的可能是 1 个服务,也可能是 1000 个服务。所以,为了能够满足所有未来的客户方,你需要预先考虑,采用好的 API 实践。当然你也可以对 APIs 进行版本化,或采用版本化的数据表示,但预先做好设计更省事。
Tom 在文章的最后表示,Droplet 认为在微服务上的投入是值得的:
不可否认,采用微服务作为基础设施是需要一定投入的。虽然在 Droplet 我们最近才实现“收支平衡”,但我们确实体会到了好处——构建和部署服务简直太快太简单了。无论是简单地采用现有工具来解决问题,还是尝试新技术,都不会对系统中其余部分有大的影响——这点很棒。
就像在过去几年中,我们不断听到有关其他 SOA 与 REST 方法的经验一样,关于微服务的实战经验肯定会越来越多。这些经验可能会影响人们的选择。在必要时,它们也会促进最佳实践和模式的产生,从而推动微服务的发展。
评论