【微服务架构】9 管理和运维

9 管理和运维

微服务与单块应用的运行方式有几方面不一样。在微服务中，单应用可以变成一个分布式系统，由多个相关联的微服务组成。因此，我们必须管理高度分离的系统，以及每个服务之间的通信。

运行中的服务比单块应用中的服务运行更高。当加载的特征变化后，一个微服务应用应该快速调整多个运行的服务进行响应。因此，我们必须自动化的部署新的、移除旧的服务实例，来确保所有的应用运行合适的状态。

在每个生产系统中，有必要进行健康检查，来获取应用运行的信息。在微服务中，也需要对每个服务实例进行健康检查。

本节包含以下三块内容：

1. 指标和监控检测
2. 日志 (Logging）
3. 模板（templating）

指标度量和健康检查

指标度量和健康检查是获取运行中服务状态的一种必要方法。

动态供应（dynamic provision）

使用动态供应，为了自动化保持微服务系统在最佳状态下运行。这种状态时系统适合保持应用用户负载需求之间的平衡。让足够多的服务实例是有效工作，来支持吞吐量和保持应用延迟的最小化。例如一个微服务实例可能变得过载，这时可以弹性的启动另外一个服务实例来扩展。这种变化应该自动化的运行，而不需要管理员干涉。类似的，负载低的、无用的微服务实例将会停止，释放虚拟系统的资源。

然而，在某些情景下，需要通知管理员某些阈值已经达到了，需要他们采取行动来避免系统宕机，当然，这是异常场景。

服务发现是微服务中关键的服务之一。服务注册与发现服务会跟踪可用的微服务实例，以及他们当前的健康状态。新的服务实例应该开始处理请求，来减小原来实例的负载。知道新注册的服务后，负载均衡器可以动态的执行，可以最优的性能向多个服务实例中分发负载。一个微服务在被关机前，应该完成正在执行的请求才行正常关机，不应该再接收新的请求。

微服务系统需要高度自动化来实现上述这些行为。可以使用基础设施管理的各种工具了帮助我们，很多打包的方式可以实现这个任务目标。在微服务包中的运行环境具有一些支持自动化的特性。使用Liberty作为运行环境，可以提供我们某些领域的自动伸缩和动态路由。

自动伸缩（auto scaling）提供一种动态伸缩的能力。自动伸缩功能由两个Liberty特性完成：Scaling 控制器和scaling成员。Auto Scaling动态调整JVMs的使用数量，来支持负载。这个特性提供弹性运维，并减少管理员的需求，增强中间件的恢复力。Auto scaling的条件由伸缩策略定义。这类条件包括服务实例最小或最大个数，以及每个服务器资源的阈值。

微服务运维通常采用一种模式，始终保持一定数量的微服务实例处于运行状态，或经常保持最小数量以及权限运行的级别下放大。通过这种设置的一个微服务应用，在它自身的设计边界内运行，并且在异常负载下能扩大服务至可接受数量来承载这些压力。使用Liberty的自动伸缩特性，对于一个简况的系统，我们可以定义服务实例的最小运行数量。我们可以管理系统来保持这些数量的实例处于在线状态。

自动弹性度量，主要包括以下几个方面：

1. CPU
2. Heap
3. Memory

健康检查

我们需要识别微服务应用中的实例所发生的问题，这样我们可以确保整个系统处于健康的状态。为了获取这些微服务的信息，Liberty具有一些其他的功能，健康管理，可以帮助我们采取一种策略驱动的方式，监控应用服务器的环境，并当发现非健康时采取行动。我们可以定义健康政策，包括我们环境中的健康条件，以及当发现非健康条件时的应对行动。

健康管理能避免服务因发现常见的问题而瓦解，基于健康政策配置来创建诊断行动。健康管理功能由两个特性组成：
1.监控管理员 2.健康分析员

以下预定义的健康条件可供参考：

1. 过多的请求超时条件
2. 过多的响应时间 条件
3. 内存条件：过多的内存使用
4. 内存条件：内存泄露

当这些健康条件产生时，可以执行一个预定义的行为。以下行为可参考：

1. 重启服务器
2. 将线程的内存转储
3. 将JVM堆内存转储
4. 将服务器切换为维护模式
5. 将服务器退出维护模式

上述行为可能产生更多信息（线程、堆内存转储）来获取对问题更好的理解。这种特性使得Performance Monitoring Infrastructure（PMI）来处理其他运行中的服务器。

日志（Logging）

日志是应用中重要的一部分。也是微服务系统中重要的一部分。

在一个微服务系统中，业务事务可能横跨多个微服务，如果我们微服务使用一个消息中间件，那么这部分也属于业务事务。因此，我们需要跟踪系统中整个请求，直到响应从系统中离去。一种监控这些请求的方式是，使用关联ID（correlation ID），在消息中间中使用相同的关联ID来对应微服务中的请求。

我们可以创建关联ID在请求进入系统时，然后，发送相同的关联ID到其他微服务，当调用它时。其他的服务只需要检查是否存在一个关联ID，并且传递到它的调用中。这个关联ID能够放到HTTP的请求头中，使用特定的字段来保存这个值。可以使用REST过滤器来处理这个头部字段，可以中心化这段处理逻辑。

使用关联ID提供以下几点好处：

1. 容易找到级联式错误
2. 跟踪用户的请求，来获取更多用户典型的行为信息。
3. 可以找到没有使用或很少使用的微服务，并讲这些服务排除；或者找到重度使用的微服务，然后，将这些从这些服务中挖掘更多商业价值

使用日志框架来记录关联ID的日志到文件中有很多好处，某些框架可以使用日志上下文，SLF4J、Log4J实现了Mapped Diagnostic Context（MDC） 或 Nested Diagnostic Context（NDC），可以将关联ID放到这些里面。因此，每条日志状态写入日志文件，包括NDC或MDC。另一个好处，我们可以从NDC或MDC中获取，如果我们使用了多线程来响应请求，那么每个线程记录相同的NDC/MDC.

日志的输出格式应该由一个中心的机制进行定义，这样聚集不同微服务所产生的日志更加容易。日志的等级（例如，FATAL、ERROR、WARN、INFO、DEBUG、TRACE、ALL）应该清晰的定义，并且在相关的每个微服务中使用。否则，我们可能无法理解两个不同微服务团队的日志。

在使用动态供应的微服务系统中，我们必须确保微服务所在的服务器在关机时删除日志文件。在这种情况下，最好使用日志基础设施，它长期运行来收集微服务输出的日志信息。这个日志系统可以帮助我们收集分布在不同系统中的日志文件。搜索不同服务器上的日志文件是一个非常费时的操作。在生产环境中，这些操作将会受限，在这些系统中通常我们都没有权限或最小的权限。

因此，更好的方法是在微服务应用中建立一个日志基础服务，例如ELK（Elastic Logstash Kibana）：

1. Elasticsearch 搜索与分析引擎
2. Logstash 数据收集和传输管线
3. Kibana 数据可视化

模板（Templating）

从管理者的视角，将实现系统或微服务模板化，对于我们开发团队是有价值的事情。模板在这里是指，定义一个代码片段的骨架，能有用于生成微服务所需的部分。

典型的微服务模板包括以下常见的能力：

1. 与服务发现进行通信，注册服务实例
2. 与其他微服务进行通信
3. 与消息系统进行通信
4. 日志
5. 安全

使用模板我们将获得以下几点能力：

1. 快速开始一个开发团队
2. 所有团队使用相同的跨功能服务

以下是可用的模板生成工具：

1. WildFly Swarm Project Generator
2. Spring Initializr
3. Liberty app accelerator

如果所有的团队使用Java来实现微服务，那么我们不需要一个多语言编程环境，那么我们必须定义一个模板，一个最能契合我们需求的模板。