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