微服务实战经验分享

在过去的几个月里，我们已经听到很多关于微服务的优缺点了。微服务真的只是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方法的经验一样，关于微服务的实战经验肯定会越来越多。这些经验可能会影响人们的选择。在必要时，它们也会促进最佳实践和模式的产生，从而推动微服务的发展。

查看英文原文：Lessons Learnt Using Microservices