微服务设计——1.2　主要好处

微服务有很多不同的好处，其中很多好处也适用于任何一个分布式系统。但相对于分布式系统或者面向服务的架构而言，微服务要更胜一筹，它会把这些好处推向极致。 1.2.1　技术异构性 在一个由多个服务相互协作的系统中，可以在不同的服务中使用最适合该服务的技术。尝试使用一种适合所有场景的标准化技术，会使得所有的场景都无法得到很好的支持。 如果系统中的一部分需要做性能提升，可以使用性能更好的技术栈重新构建该部分。系统中的不同部分也可使用不同的数据存储技术，比如对于社交网络来说，图数据库能够更好地处理用户之间的交互操作，但是对于用户发布的帖子而言，文档数据库可能是一个更好的选择。图1-1 展示了该异构架构。 图1-1：微服务帮助你轻松地采用不同的技术 微服务可以帮助我们更快地采用新技术，并且理解这些新技术的好处。尝试新技术通常伴随着风险，这使得很多人望而却步。尤其是对于单块系统而言，采用一个新的语言、数据库或者框架都会对整个系统产生巨大的影响。对于微服务系统而言，总会存在一些地方让我可以尝试新技术。你可以选择一个风险最小的服务来采用新技术，即便出现问题也容易处理。这种可以快速采用新技术的能力对很多组织而言是非常有价值的。 不过为了同时使用多种技术，也需要付出一些代价。有些组织会限制语言的选择，比如Netflix 和Twitter 选用的技术大多基于JVM（Java Virtual Machine，Java 虚拟机），因为他们非常了解该平台的稳定性和性能。他们还在JVM 上开发了一些库和工具，使得大规模运维变得更加容易，但这同时也使得我们更难以采用Java 外的其他技术来编写服务和客户端。尽管如此，Twitter 和Netflix 也并非只使用一种技术栈。另一个会影响多技术栈选用的因素是服务的大小，如果你真的可以在两周内重写一个服务，那么尝试使用新技术的风险就降低了不少。 贯穿本书的一个问题是，微服务如何寻找平衡。第2 章我们会讨论如何做技术选择，其中主要专注于演进式架构；第4 章主要关注集成，你将学会如何避免服务之间的过度耦合，从而可以使其彼此独立地进行技术演化。 1.2.2　弹性 弹性工程学的一个关键概念是舱壁。如果系统中的一个组件不可用了，但并没有导致级联故障，那么系统的其他部分还可以正常运行。服务边界就是一个很显然的舱壁。在单块系统中，如果服务不可用，那么所有的功能都会不可用。对于单块服务的系统而言，可以通过将同样的实例运行在不同的机器上来降低功能完全不可用的概率，然而微服务系统本身就能够很好地处理服务不可用和功能降级问题。 微服务系统可以改进弹性，但你还是需要谨慎对待，因为一旦使用了分布式系统，网络就会是个问题。不但网络会是个问题，机器也如此，因此我们需要了解出现问题时应该如何对用户进行展示。 第11 章会就弹性处理和对故障模式的处理做更多讨论。 1.2.3　扩展 庞大的单块服务只能作为一个整体进行扩展。即使系统中只有一小部分存在性能问题，也需要对整个服务进行扩展。如果使用较小的多个服务，则可以只对需要扩展的服务进行扩展，这样就可以把那些不需要扩展的服务运行在更小的、性能稍差的硬件上，如图1-2 所示。 图1-2：可以针对那些需要扩展的微服务进行扩展 Gilt 是一个在线时尚零售商，他们就是因为这个原因而采用了微服务。2007 年，他们还是一个单一的Rails 应用，2009 年，Gilt 的系统无法解决其负载。通过将系统的核心部分抽离出来之后，Gilt 在流量处理方面有了大大的改进。如今Gilt 有450 多个微服务，每一个服务都分别运行在多台机器上。 在使用类似Amazon 云服务之类的平台时，也可以只对需要的服务进行扩展，从而节省成本。通过架构来节省成本的情形还真是不多见。 1.2.4　简化部署 在有几百万代码行的单块应用程序中，即使只修改了一行代码，也需要重新部署整个应用程序才能够发布该变更。这种部署的影响很大、风险很高，因此相关干系人不敢轻易做部署。于是在实际操作中，部署的频率就会变得很低。这意味着在两次发布之间我们对软件做了很多功能增强，但直到最后一刻才把这些大量的变更一次性发布到生产环境中。这时，另外一个问题就显现出来了：两次发布之间的差异越大，出错的可能性就更大！ 在微服务架构中，各个服务的部署是独立的，这样就可以更快地对特定部分的代码进行部署。如果真的出了问题，也只会影响一个服务，并且容易快速回滚，这也意味着客户可以更快地使用我们开发的新功能。Amazon 和Netflix 等组织采用这种架构主要就是基于上述考虑。这种架构很好地清除了软件发布过程中的种种障碍。 微服务部署领域的技术在过去几年时间里发生了巨大的变化，第6 章会对该话题做更深入的讨论。 1.2.5　与组织结构相匹配 我们经历过太多由于团队和代码库过大引起问题的情况。当团队是分布式的时候，问题会更明显。我们也知道在小型代码库上工作的小团队更加高效。 微服务架构可以很好地将架构与组织结构相匹配，避免出现过大的代码库，从而获得理想的团队大小及生产力。服务的所有权也可以在团队之间迁移，从而避免异地团队的出现。在第10 章讲解康威定律时会对该话题做更深入的讨论。 1.2.6　可组合性 分布式系统和面向服务架构声称的主要好处是易于重用已有功能。而在微服务架构中，根据不同的目的，人们可以通过不同的方式使用同一个功能，在考虑客户如何使用该软件时这一点尤其重要。单纯考虑桌面网站或者移动应用程序的时代已经过去了。现在我们需要考虑的应用程序种类包括Web、原生应用、移动端Web、平板应用及可穿戴设备等，针对每一种都应该考虑如何对已有功能进行组合来实现这些应用。现在很多组织都在做整体考虑，拓展他们与客户交互的渠道，同时也需要相应地调整架构来辅助这种变化的发生。 在微服务架构中，系统会开放很多接缝供外部使用。当情况发生改变时，可以使用不同的方式构建应用，而整体化应用程序只能提供一个非常粗粒度的接缝供外部使用。如果想要得到更有用的细化信息，你需要使用榔头撬开它！第5 章会讨论如何将已有的单块应用程序分解成为多个微服务，并且达到可重用、可组合的目的。 1.2.7　对可替代性的优化 如果你在一个大中型组织工作，很可能接触过一些庞大而丑陋的遗留系统。这些系统无人敢碰，却对公司业务的运营至关重要。更糟糕的是，这些程序是使用某种奇怪的Fortran变体编写的，并且只能运行在25 年前就应该被淘汰的硬件上。为什么这些系统直到现在还没有被取代？其实你很清楚答案：工作量很大，而且风险很高。 当使用多个小规模服务时，重新实现某一个服务或者是直接删除该服务都是相对可操作的。想想看，在单块系统中你是否会在一天内删掉上百行代码，并且确信不会引发问题？微服务中的多个服务大小相似，所以重写或移除一个或者多个服务的阻碍也很小。 使用微服务架构的团队可以在需要时轻易地重写服务，或者删除不再使用的服务。当一个代码库只有几百行时，人们也不会对它有太多感情上的依赖，所以很容易替换它。