分布式系统实战经验

Camille Fournier在接受Stefan Tilkov采访时指出，作为软件架构师和开发人员，我们生活在一个分布式的世界中，为了简化分布式系统的构建，我们要形成一种意识，企业的价值在哪里，哪里可以合理地去冒险，哪里不可以。我们应该只处理那些真正需要解决的问题。

Fournier 以前曾在Rent the Runway和Goldman Sachs任职，她最喜欢Leslie Lamport的分布式系统定义：

分布式系统是其中一台计算机出现故障，可以导致你自己的计算机不可用的系统。

在 Fournier 看来，Lamports 的定义真正地抓住了分布式系统的本质，那不是一件简单的事情，它会出问题，而且其复杂性是如此之高，都不可能很容易地推断出来。

人们常常因为流程中有网络就将系统看作是分布式的，但一个只有一台服务器和一个 Web 浏览器构成的系统，或者一个传统的三层架构，不是 Fournier 通常所定义的分布式系统。她认为，那只会让问题不必要地复杂化；我们无需为尚未遇到的问题担心。即使你构建了一个有一定复杂性的联网系统，那也并不一定意味着，你要为构建好一个可用的系统而必须考虑整个分布式系统领域的复杂性。

在 Fournier 看来，只有当你真地要贯穿许多不同的系统时，分布式才开始成为应该处理的问题。使用一种服务架构，尤其是微服务类型的架构，就会开始遇到一些复杂的问题，但未必是可能在大规模分布式系统中出现的所有问题。她指出，分布式系统是一个工程问题，同时也是一个理论问题。也就是说，你必须运用工程问题所需要的理论解决它，但也不需要更多，只要足够解决问题就可以了。

Fournier 认为，在考虑具有一定规模（不需要像 Netflix 那么庞大）的软件的时候，服务架构，不管你是否称之为微服务，是一个非常明智的方式。在有几十名开发人员的时候，考虑将系统分成可以独立操作的实体非常有价值。把那些实体放入服务，就可以实现独立开发和数据所有权。单体架构本身并没有错，但她指出，分布式系统数量增加的原因并不只是因为我们真正需要，还是因为云的存在让构建这样的系统更加简单了。

状态让一切变得复杂。在 Fournier 看来，在考虑构建分布式系统时，其中一个重要的方面是哪里关注相干和一致状态，即在哪些部分你不希望丢失数据或让人们看到不同的状态。对于这些部分，她一般喜欢使用事务和传统的关系型数据库。一个例子是订单处理，在这种情况下，你希望确保能够完成所有的订单。在其他部分，你可能不那么关心一致性，人们看到稍微有点过期的数据，或者数据丢失，都没有问题，因为很容易重新创建。这时，Fournier 认为完全可以使用 NoSQL 数据库。

查看英文原文：Experiences Working with Real World Distributed Systems