管理微服务涉及五个关键原则。这些原则帮助运维团队管理基于微服务的应用程序。它们还促使开发人员考虑应用程序怎样运维，因为开发人员和运维共同都负责提供一个健壮且高质量的服务。为了实现这一点，在设计和开发应用程序时，让开发人员尽早参与运维是很重要的。在以后的时间重构这些决策是容易出错的、麻烦的，而且肯定不那么有效。
下面介绍一下IBM建议的管理微服务的5个关键原则
1. 运维
运维的工作是在生产环境中执行操作活动用以确保应用程序有合适的能力来应对负载，同时确保IT的工作遵从公司或政府的政策，等等。
微服务的运维推荐加入新技术的支持，这样运维任务就会十分轻松。例如，在负载管理中，微服务提供弹性支持，根据使用情况，基础设施可以自动伸缩。这些新的构建应用程序的方法，可以在工具、架构或开发没有进行大规模的变更的情况下对应用裁剪。
虽然微服务不需要使用容器来实现，但同时使用微服务与容器这两种技术是有益的。当您使用容器时，软件所需要的所有东西都被打包成独立的、轻量级的捆绑包，使部署和操作更加容易。建议使用Kubernetes开源系统，用于自动化容器应用程序的部署、扩展和管理。Kubernetes为许多运维任务提供了如下功能:
1. 基于资源需求的工作负载均衡，
2. 自动化的部署和回滚服务
3. 服务发现和服务的负载平衡
4. 服务的水平伸缩
5. 服务的自愈
正如您所看到的，许多典型的运维任务可以通过Kubernetes完成，这样您就可以专注于其他的运维活动。其中一个任务就是检查“合规”。例如，您可能需要检查是否符合安全、公司政策或由行业或政府强制执行的标准。这些检查应该已经在开发和测试阶段运行了。在生产中运行也是明智的，因为许多政策都在不断变化。
另外需要注意的是备份和归档。为满足灾备和监管需求，我们必须定期备份，这种备份可以是基于RPO(recovery point object),或者使用RTO(recovery time objective),。一个好的微服务设计，将与存储相关的活动外部化，这样这些存储任务就可以被限制在处理持久化的服务上。
2. 监控
每个微服务都必须被监视。在考虑使用监控解决方案之前，先要明确您的指导原则是服务用户的体验，该服务可能是一个人(面向前端服务)或系统(用于后端服务)。因此，关键的监控指标通常是可用性、性能、响应时间、延迟和错误率。
基于不同的监控方案，对于CPU，内存，磁盘的监控指标会显著不同。例如，随着IaaS和PaaS等基于云的运维模型的出现，应用程序所有者参与的监控工作也会减少。
对于微服务而言，为每个微服务建立一个HealthCheck API是良好的习惯。由于开发人员最了解关键资源和对他们的服务的检查，他们实现HealthCheck API是最合理的。
Prommetheus是一个开源的监控框架，而Fluentd是一个记录数据收集者。这两种工具都与Kubernetes合作。它们提供了某种程度的HealthCheck API，从而为开发人员利用它提供了便利。
另一个需要监视的重要内容是应用程序日志，因为它们提供了运行应用程序的行为，典型的用例是在事件诊断分析过程中对日志的解析和调查。临界警报可能也会在日志中公开，因此一个监控解决方案应该寻找log监控模式并警告操作团队。尽管微服务是松散耦合的，但它们彼此依赖。它们是在不同的编程语言中开发的，它们的执行特性是分布式的，并且具有高度的动态特性，因此必须将日志集中到一个中心位置，并从那里执行搜索和分析。
服务行为跟踪同样十分重要，可以使用一种技术：相关标识符。使用关联ID不仅有助于确定给定事务的执行路径，而且还支持添加时间上下文，例如添加延迟信息，添加服务层次结构，以及过程或任务执行时的串行或并行信息。推荐使用Open Traceing， 一个分布式跟踪的开放标准。
3. 事件与警告管理
监视解决方案可以检测到服务的问题，但是仍然会出现大量的警报。在这种网状体系结构中，服务依赖于彼此，因此一个服务中的性能下降可能导致每个依赖服务中的级联故障。为了避免仅仅发现问题而不是去寻找原因，事件管理系统是必要的。事件管理系统集成了来自各种服务监视、日志监视、基础设施监控以及警报。为此，需要事件管理系统结合微服务的拓扑信息和部署状态信息，对时间进行统一管理。在微服务的框架下，这些信息变化迅速，所以必须在合适的时间收集数据。像配置管理数据库(CMDBs)这样的传统方法有很高的风险，它保存的可能只是不完整或陈旧的信息。建议动态数据必须在系统检测时直接从(容器)管理系统中检索并保存。
这种信息同步的结果是报警信息包含准确的定位，具有可操作性。每个事件都应该与一个Runbook相关联，以便运维团队知道如何响应警报以及采取什么缓解措施。理想情况下，这些Runbooks是用脚本的形式编写的，这样事件管理系统就可以自动执行，并且只对一个人的问题进行处理。
当然，你不希望运维人员浪费时间盯着控制台，所以系统会在收到新警报时通知他们。通知可以通过各种渠道发送:电子邮件、短信或即时消息。
4. 合作
在运维团队被告知新的事件之后，他们会从诊断开始。第一步是在错误中隔离组件。在隔离之后，调查将继续观察到底发生了什么，以及可以做些什么来尽快恢复服务。在许多服务相互依赖的体系结构中，许多人可能需要协作。微服务的关键概念之一是支持多语言和多平台，支持专家间的交互，包括开发人员。“ChatOps”这个术语描述了这个过程，在这个过程中，人们使用即时消息通信平台来进行中小企业之间的协作。通过ChatOps平台，所有的交互都被记录在一个中心位置，您可以浏览日志，查看采取了哪些操作。
ChatOps并不局限于人类之间的相互作用。通过使用Bot技术，可以集成DevOps和服务管理工具。例如监视系统，它将显示在过去24小时内响应时间分布的图表，也可显示最近的部署任务。
此外，通过统一的信息展示平台，可以改善系统的可见性，从而加速系统恢复素服。由于基于微服务的应用程序在自然环境下的部署中是动态的，自动伸缩的、动态实例化的，所以对应用程序的准确理解是一个挑战。统一的信息展示平台可以展示系统拓扑、部署活动和操作状态，显示可用性和性能指标。还应该从用户的角度来展示关键服务指示器。
5. 故障分析
通过协作，运维团队最终确定了正确方法来缓解和恢复服务。为了防止这一事件再次出现，必须对其根源进行分析。团队间不能相互指责，推卸责任。将目标定为发现根本问题，而不是找到责任人。只有通过这种方式，人们才愿意分享自己的见解，并帮助他人从经验中学习。
根本问题发现后，下一步是寻找解决方法。系统应用甚至系统架构可能因此而修改。建议采用Agile的管理方式，将解决方案规划进每一个Spring，按部就班的实施。
运维面临的系统故障更多的来自系统的升级。为了实现系统平稳升级，许多公司采取了不同的方法。一些公司将运维工作推给了DevOps团队。在这个模型中，开发人员来负责系统可靠性。另一种方法是建立专门的系统可靠性团队。这个团队负责解决系统可靠性问题，至少要花50%的时间在工程上。例如，通过自动化减少重复工作，并帮助开发团队实现变更，升级。
