使用Spring Boot创建微服务.pdf

使用Spring Boot创建微服务 过去几年以来，“微服务架构”的概念已经在软件开发领域获得了一个稳定的基础。作为 “面向 服务架构” （SOA）的一个继任者，微服务同样也可以被归类为“分布式系统”这一类，并且进一步 发扬了SOA 中的许多概念与实践。不过，它们在不同之处在于每个单一服务所应承担的责任范围。在 SOA中，每个服务将负责处理广范围的功能与数据领域，而微服务的一种通用指南则认为，它所负责 的部分是管理一个单独的数据领域，以及围绕着该领域的相关功能。使用分布式系统方式的目的是将 整体性的服务基础设施解耦为个别的可扩展子系统，可以通过垂直分片的方式将这些子系统组织在一 起，并通过一种通用的传输方式将它们进行相关连接。 在整体性的基础设施中，构成系统的服务在逻辑上是在相同的代码基础与部署单元中组织的。这 就能够通过相同的运行时对多个服务之间的相互依赖进行管理，同时也意味着在系统的多个组件中能 够共享通用的模型与资源。在整体性基础设施中的子系统之间的相互连接性意味着，通过抽象与功能 性函数，可以实现对业务逻辑与数据领域的极大的重用性。虽然这种重用通常是通过紧耦合的方式实 现的，但它也存在着一个潜在的好处，就是易于确定某个单一的变更将会对整个系统带来怎样的影响。 但为了实现这种便利性，要付出的代价就是牺牲了整个基础设施中单个组织的可伸缩性，同时也意味 着整个系统的能力受限于其可伸缩性最薄弱的环节。 在分布式系统中，整体性系统的组件被解耦为个别的部署单元，这些部署单元能够独立地根据可 伸缩性的需求自行升级，而不必理会其它子系统的情况。这也意味着整个系统的资源能够被更加有效 地利用，并且由于组件之间的相互依赖性不再由运行时环境进行管理，因此它们之间可以通过相对灵 活的契约进行相互交互。在传统的SOA架构中，服务的边界之内可以封装有关某个业务逻辑的大量功 能，并且可以潜在地将大量数据领域集中在一起。而微服务架构不仅继承了系统分布式的概念，同时 也承诺只对一个单一的业务功能和数据领域进行管理，这意味着从逻辑上控制某个子系统将变得非常 容易。同时也意味着管理子系统的文档化与测试的范围也将变得更简单，因此在这两方面的涵盖程度 理应有所提高。 与SOA架构一样，微服务架构也必须通过某种通用的传输方式进行相互连接，而这些年以来，HTTP 已经被证明是完成这一任务的一样强大的手段。除此之外还存在着多种选择，例如二进制传输协议以 及消息代理，微服务架构中并没有明显地倾向于其中任何一种方式，主要的选择依据是看那些能够在 服务之间建立互通信的类库的成熟度与可用性。作为一种成熟的传输协议，几乎每种编程语言与框架 都提供了HTTP 的客户端类库，因此它作为服务间互通信的协议是一个优秀的选择。微服务架构对于 与服务交互的无状态性这一方面有着特别的要求，无论采用了哪种底层协议，微服务都应该保持通信 的无状态性，并且遵循RESTful范式以求实现这一点，这在业界基本已经达成了很好的共识。这就意 味着对于某个微服务的每个请求与响应必须保证所调用的方法中的状态必须始终保持可用。说得更明 白一点，就是指该服务不能够根据之前的交互行为对于每个请求中所需的数据进行任何假设。保证了 正确的REST实现，也就意味着微服务本质上就是为了大规模而设计的，这也确保了对于任何一个服 务的后续部署能够将停机时间减至最低、甚至做到无停机时间。 要充分了解如何切分一个整体性的架构，并创建微服务可能会存在一些困难，尤其在遗留的代码 中，服务边界之间的数据领域通常是紧耦合的。根据经验来看，可以根据某个特定业务功能的边界对 基础设施进行垂直切分。多个微服务能够在某个垂直分片的上下文中以协作方式一起运行。举例来说， 设想某个电子商务网站的功能，从登陆页面开始，到客户与某个产品进行交互的页面，再到客户购买 某个产品的页面，这一连串的业务功能之间存在着清晰的界线。可以将这一套流程分解为多个垂直分 片，包括查看产品详细信息、将某个产品加入 “购物车”、以及对一个或多个产品下订单。在客户查 看产品信息的这个业务上下文中，可能会存在多个微服务，用于处理获取某个特定产品并将其详细信 息展现给用户的流程。再举一个例子，在网站的登陆页面中，可能会显示大量产品的名称、图片以及 价格。该页面可以从两个后台微服务中获取这些细节信息：一个微服务用于提供产品信息，另一个用 于获取每个产品的价格。当用户选中某个特定的产品后，网站可以调用另外两个微服务，它们将用于 为用户提供产品的评分与客户的评价。因此，为了提供用于 “查看产品详细信息”业务功能在架构上 的垂