服务引导（图2-6中的步骤2）发生在微服务首次启动并需要加载其应用程序配置信息的时候。图2-8为引导处理提供了更多的上下文。
任何应用程序开发人员都知道，有时需要使应用程序的运行时行为可配置。通常这涉及从应用程序部署的属性文件读取应用程序的配置数据，或从数据存储区（如关系数据库）读取数据。
微服务通常会遇到相同类型的配置需求。不同之处在于，在云上运行的微服务应用程序中，可能会运行数百甚至数千个微服务实例。更为复杂的是，这些服务可能分散在全球。由于存在大量的地理位置分散的服务，重新部署服务以获取新的配置数据变得难以实施。
将数据存储在服务器外部的数据存储中解决了这个问题，但云上的微服务提出了一系列独特的挑战。
（1）配置数据的结构往往是简单的，通常读取频繁但不经常写入。在这种情况下，使用关系数据库就是“杀鸡用牛刀”，因为关系数据库旨在管理比一组简单的键值对更复杂的数据模型。
（2）因为数据是定期访问的，但是很少更改，所以数据必须具有低延迟的可读性。
（3）数据存储必须具有高可用性，并且靠近读取数据的服务。配置数据存储不能完全关闭，否则它将成为应用程序的单点故障。
在第3章中，将介绍如何使用简单的键值数据存储之类的工具来管理微服务应用程序配置数据。
2.4.3 服务注册和发现：客户端如何与微服务通信
从微服务消费者的角度来看，微服务应该是位置透明的，因为在基于云的环境中，服务器是短暂的。短暂意味着承载服务的服务器通常比在企业数据中心运行的服务的寿命更短。可以通过分配给运行服务的服务器的全新IP地址来快速启动和拆除基于云的服务。
通过坚持将服务视为短暂的可自由处理的对象，微服务架构可以通过运行多个服务实例来实现高度的可伸缩性和可用性。服务需求和弹性可以在需要的情况下尽快进行管理。每个服务都有一个分配给它的唯一和非永久的IP地址。短暂服务的缺点是，随着服务的不断出现和消失，手动或手工管理大量的短暂服务容易造成运行中断。
微服务实例需要向第三方代理注册。此注册过程称为服务发现（见图2-6中的步骤3，以及图2-9中有关此过程的详细信息）。当微服务实例使用服务发现代理进行注册时，微服务实例将告诉发现代理两件事情：服务实例的物理IP地址或域名地址，以及应用程序可以用来查找服务的逻辑名称。某些服务发现代理还要求能访问到注册服务的URL，服务发现代理可以使用此URL来执行健康检查。
然后，服务客户端与发现代理进行通信以查找服务的位置。
2.4.4 传达微服务的“健康状况”
服务发现代理不只是扮演了一名引导客户端到服务位置的交通警察的角色。在基于云的微服务应用程序中，通常会有多个服务实例运行，其中某些服务实例迟早会出现一些问题。服务发现代理监视其注册的每个服务实例的健康状况，并从其路由表中移除有问题的服务实例，以确保客户端不会访问已经发生故障的服务实例。
在发现微服务后，服务发现代理将继续监视和ping健康检查接口，以确保该服务可用。这是图2-6中的步骤4。图2-10提供了此步骤的上下文。
通过构建一致的健康检查接口，我们可以使用基于云的监控工具来检测问题并对其进行适当的响应。
如果服务发现代理发现服务实例存在问题，则可以采取纠正措施，如关闭出现故障的实例或启动另外的服务实例。
在使用REST的微服务环境中，构建健康检查接口的最简单的方法是公开可返回JSON净荷和HTTP状态码的HTTP端点。在基于非Spring Boot的微服务中，开发人员通常需要编写一个返回服务健康状况的端点。
在Spring Boot中，公开一个端点是很简单的，只涉及修改Maven构建文件以包含Spring Actuator模块。Spring Actuator提供了开箱即用的运维端点，可帮助用户了解和管理服务的健康状况。要使用Spring Actuator，需要确保在Maven构建文件中包含以下依赖项：
-
<dependency>
-
<groupId>org.springframework.boot</groupId>
-
<artifactId>spring-boot-starter-actuator</artifactId>
-
</dependency>
如果访问许可证服务上的
http://localhost:8080/health端点，则应该会看到返回的健康状况数据。图2-11提供了返回数据的示例。
如图2-11所示，健康状况检查不仅仅是微服务是否在运行的指示器，它还可以提供有关运行微服务实例的服务器状态的信息，这样可以获得更丰富的监控体验。
2.5 将视角综合起来
云中的微服务看起来很简单，但要想成功，却需要有一个综合的视角，将架构师、开发人员和DevOps工程师的视角融到一起，形成一个紧密结合的视角。每个视角的关键结论概括如下。
（1）架构师——专注于业务问题的自然轮廓。描述业务问题域，并听取别人所讲述的故事，按照这种方式，筛选出目标备选微服务。还要记住，最好从“粗粒度”的微服务开始，并重构到较小的服务，而不是从一大批小型服务开始。微服务架构像大多数优秀的架构一样，是按需调整的，而不是预先计划好的。
（2）软件工程师——尽管服务很小，但并不意味着就应该把良好的设计原则抛于脑后。专注于构建分层服务，服务中的每一层都有离散的职责。避免在代码中构建框架的诱惑，并尝试使每个微服务完全独立。过早的框架设计和采用框架可能会在应用程序生命周期的后期产生巨大的维护成本。
（3）DevOps工程师——服务不存在于真空中。尽早建立服务的生命周期。DevOps视角不仅要关注如何自动化服务的构建和部署，还要关注如何监控服务的健康状况，并在出现问题时做出反应。实施服务通常需要比编写业务逻辑更多的工作，也更需要深谋远虑。
2.6 小结
要想通过微服务获得成功，需要综合架构师、软件开发人员和DevOps的视角。
微服务是一种强大的架构范型，它有优点和缺点。并非所有应用程序都应该是微服务应用程序。
从架构师的角度来看，微服务是小型的、独立的和分布式的。微服务应具有狭窄的边界，并管理一小组数据。
从开发人员的角度来看，微服务通常使用REST风格的设计构建，JSON作为服务发送和接收数据的净荷。
Spring Boot是构建微服务的理想框架，因为它允许开发人员使用几个简单的注解即可构建基于REST的JSON服务。
从DevOps的角度来看，微服务如何打包、部署和监控至关重要。
开箱即用。Spring Boot允许用户用单个可执行JAR文件交付服务。JAR文件中的嵌入式Tomcat服务器承载该服务。
Spring Boot框架附带的Spring Actuator会公开有关服务运行健康状况的信息以及有关服务运行时的信息。