什么是微服务架构?( 四 ) _微服务架构

什么是松耦合

微服务架构的最核心特性是服务之间的松耦合性。服务之间的交互采用API完成，这样做就封装了服务的实现细节。这允许服务在不影响客户端的情况下，对实现方式做出修改。松耦合服务是改善开发效率、提升可维护性和可测试性的关键。小的、松耦合的服务更容易被理解、修改和测试。

我们通过API来实现松耦合服务之间的协调调用，这样就避免了外界对服务的数据库的直接访问和调用。服务自身的持久化数据就如同类的私有属性一样，是不对外的。保证数据的私有属性是实现松耦合的前提之一。这样做，就允许开发者修改服务的数据结构，而不用提前与其他服务的开发者互相协商。这样做在运行时也实现了更好的隔离。例如，一个服务的数据库加锁不会影响另外的服务。但是你稍后就会看到在服务间不共享数据库的弊端，特别是处理数据一致性和跨服务查询都变得更为复杂。

共享类库的角色

开发人员经常把一些通用的功能打包到库或模块中，以便多个应用程序可以重用它而无须复制代码。毕竟，如果没有Maven或npm库，我们今天的开发工作都会变得更困难。你可能也想在微服务架构中使用共享库。从表面上看，它似乎是减少服务中代码重复的好方法。但是你需要确保不会意外地在服务之间引入耦合。

例如，想象一下多个服务需要更新Order业务对象的场景。一种选择是将该功能打包为可供多个服务使用的库。一方面，使用库可以消除代码重复。另一方面，如果业务需求的变更影响了Order业务对象，开发者需要同时重建和重新部署所有使用了共享库的服务。更好的选择是把这些可能会更改的通用功能（例如Order管理）作为服务来实现，而不是共享库。

你应该努力使用共享库来实现不太可能改变的功能。例如，在典型的应用程序中，在每个服务中都实现一个通用的Money类（例如用来实现币种转换等固定功能）没有任何意义。相反，你应该创建一个供所有服务使用的共享库。

服务的大小并不重要

微服务这个术语的一个问题是会将你的关注点错误地聚焦在微上。它暗示服务应该非常小。其他基于大小的术语（如miniservice或nanoservice）也是如此。实际上，大小不是一个重要的考虑因素。

更好的目标是将精心设计的服务定义为能够由小团队开发的服务，并且交付时间最短，与其他团队协作最少。理论上，团队可能只负责单一服务，因此服务绝不是微小的。相反，如果服务需要大型团队或需要很长时间进行测试，那么拆分团队或服务可能是有意义的。另外，如果你因为其他服务的变更而不断需要同步更新自己负责的服务，或者你所负责的服务正在触发其他服务的同步更新，那么这表明服务没有实现松耦合。你构建的甚至可能是一个分布式的单体。

微服务架构把应用程序通过一些小的、松耦合的服务组织在一起。结果，这样的架构提升了开发阶段的效率，特别是可维护性、可测试性和可部署性，这也就让组织的软件开发速度更快。微服务架构也同时提升了应用程序的可扩展性，尽管这不是微服务的主要目标。为了使用微服务架构开发软件，你首先需要识别服务，并确定它们之间如何协作。现在我们来看看如何定义一个应用程序的微服务架构。

4 总结