经过多年公有云和私有云之争，企业用户的实际业务需求和ROI终于战胜了云厂商的情感，混合云大行其道，得到了充分的开发和利用。人们逐渐开始寻求最佳策略和最优方法以更好地管理、提升混合云性能。软件业已不再轻率地对待云端的各种应用，而是正在为云运维一体化(CloudOps)寻找最优方法。
为了更好的传递本文宗旨，我们将混合云分解成几个组成部分，并针对如何最优地管理混合云性能进行探讨。这样做的好处是，我们能将这几个组成部分融合为一个完整的混合云架构，并能对整体性能管理特征进行分析，然后再把这一切融入云运维一体化，这一点还是比较有战略性的。
分配能力是关键
今天的混合云已不再是几年前我们所说的混合云。以前，工作负载是静态地绑定到私有云或者公有云上。而现在，工作负载可以自由随意地在私有云和公有云间迁移，我们可以动态的、近乎实时的完成这一过程，也可以人工完成，如移动原始代码、原始数据等。
可使工作负载在私有云和公有云之间平滑迁移是混合云的一大关键特征，而所谓性能就是寻找方法使应用架构中的组件得到最优化地运行。如果将这些组件(如数据库、应用、用户界面)整合到工作负载中，就可以更容易地对应用程序进行优化，因为这些组合起来的应用组件使他们更容易被管理和优化。
创建工作负载的方法有很多，包括虚拟机、容器或者绑定在一起的应用程序等。对于如何迁移这几种工作负载进行详细探讨不属于本文的范畴，但是却对粗略完成容器移动非常有帮助。
容器是一种独立式的组件集，可包含应用代码、数据库、中间件、安全服务或者上述全部。单个应用程序可由多个容器构成，或者单个容器可包含整个系统。无论哪种方式，容器均可以在公有云和私有云中运行。
我们竭力传达的想法是有多种选择可使工作负载在公有云和私有云之间达到互通。在公有云和私有云之间分配工作负载的方法基本上是无限的。在管理性能时，你拥有利于自己的分配权。所以务必好好利用这一点。
服务监控组件
考虑到应用程序的模块、服务可在私有云和公有云中自由运行，通过各种服务(或者微服务)对性能进行管理将会很有帮助，这些服务通过应用程序或者云平台自身得到了具体化。你可以考虑使用下列逻辑组件或者技术将混合云性能作为服务组合进行管理。
1.服务探针
2.服务库
3.通信管理器
4.性能分析引擎
5.时序数据库
6.告警管理(见图1)
我将逐一探究上述内容。请记住上述均为逻辑性概念，我们还未将这些概念映射到相关技术中。
图1：混合云服务性能监控系统概念视图/逻辑视图。构建此图的目的是将其作为依据以选择符合您需求的合适的技术或者技术组合。
Public Cloud：公有云;Private Cloud：私有云;Services A：服务A;Services B：服务B;Services C：服务C;Services D：服务D;Service Agents：服务探针;Performance Analytics Engine：性能分析引擎;Communications Manager：通信管理器;Service Repository：服务库;Time Series Database：时序数据库;Alert Management：告警管理;Console: 控制台
在了解相关组件和技术之前，先来了解以下几点内容，它们在执行服务性能和监控混合云时会用得到。
对所有相关服务的性能指标进行监控，这些指标包括如运行时间、性能、关联状态及趋势等。
对趋势数据进行前瞻性分析以确定当前问题或者未来问题发生的可能性，并在问题发生前对其进行处理。
对业务流的整体性能进行监控，例如将所有业务相关组件的性能进行关联分析。
健全的服务管理计划中的性能指标和性能监控。
“自修复”能力，利用具有更正能力的监控系统对性能问题进行自动修复。
当应用程序处于高负荷时，需要动态调整监控频率，以免不能及时发现性能问题。
提供数据大屏，进行分析、可视化监控及报警处理。
从性能指标和监控系统中直接追踪性能对业务的影响。
通过对历史性能数据进行组织、分析、可视化及存储，可追踪性能问题和问题解决办法，从而前瞻性地避免故障的再次发生。
服务探针
服务探针是在公有云或者私有云(见图1)中，与现有服务并行或者在现有服务内部运行的应用组件。既可以是多项服务绑定到一个单独的探针程序中，也可以是单独一项服务绑定到一个单独的探针中。服务探针的职责为：
在生产/运营环境中，对处于服务状态的应用监控点进行性能数据抓取。
与服务库进行通讯，以确定服务身份和当前功能组件的性能阈值，并根据阈值进行相应操作。
按照服务库的定义，以预定的动态频率对时序数据库进行更新。
利用其他组件来进行通信和告警。
利用身份管理系统或者其他安全子系统来管理验证服务。
利用服务管理系统对策略进行有效利用。
也可以这样理解，服务探针与服务进行交互，以确定运行中的性能。当然，探针有时也会引发性能问题，因此也需要有节制地使用服务探针，而且只有是服务关键性能组件才可使用服务探针。
服务库
服务库包括所有的服务属性、服务策略及服务身份，以及在公有云或私有云中提供的单点服务。一般而言，服务库是服务管理系统中的一个组成部分，它可以专为性能监控而设定，也可以直接从服务管理库中复制出来。服务库的职责包括：
提供一个用来确定当前及过去服务性能阈值的场所，这些阈值可被解读并可被探针程序所执行;跨越私有云和公有云，通过API可对其进行动态地更改。
提供最新的服务身份，包括与其他服务或者系统的关联性。这样可以对不同的服务组合进行定义，这些服务组合可共同作用完成一项功能。这些服务可单独进行监控，也可以作为整体进行监控。
为代表每项服务的探针程序分别确定位置和确定绑定信息。
存储其他和服务性能管理相关的信息。
现在，服务库已不再需要单独构建，有很多现成的开源解决方案和专门的商用解决方案。在某些情况下，人们不得不适应现有的服务库。
通信管理器
通信管理器处理探针程序、服务、服务库、数据库、分析法及其他承担服务性能监控和管理职能的组件间的通信。一般会有一个队列(或者其他一些高速中间件层)，可使信息在各个系统组件中生产和传递。通信管理器的职责包括：
与服务性能管理系统中的每个组件相连接，包括提供验证和确认服务。
从每个组件中获取信息，将信息传递到正确的目标，并为目标制造信息。
维持高性能数据传输速度，即时应对服务性能告警和反应。
记录当前及未来性能预警分析的所用信息。
快速从通信故障中恢复(如回滚操作)。
性能分析引擎
性能分析引擎是可插入的软件组件，提供内置性能分析服务。在工作过程中，人们可以利用这些分析服务去动态管理服务性能。性能分析引擎的职责包括：
针对所有连接服务的性能提供实时分析服务，并对阈值、能力或者行为方面的变化给出建议。(例如：当一项服务运行状态处于阈值之下，探针会发出报警。然后分析引擎可根据时间序列数据库中该项服务的当前性能数据，或者服务中的配置文件，自动化调节。有可能是动态增加数据库的缓存大小，重新链接其它服务器或者向运维人员发出报警。)
提供专门的服务性能报告以及趋势报告。
动态获悉所收集的信息并在性能问题被识别和解决时对因果关系进行解读。
为与其他系统管理控制台集成提供管理控制台和API。
时序数据库
时序数据库既能处理结构性复杂数据又能处理非结构性复杂数据，该数据库存储的都是围绕服务性能(如时间、服务响应、数据库响应、网络延迟及其他用于服务性能概况中的信息等)记录的原始数据。时序数据库有两大关键作用，包括：
存储海量时间序列数据以对性能进行有效监控和分析。
对所有性能问题和解决方案进行记录，并在下次发生同样问题时，及时反馈。
告警管理
告警管理系统是一个软件，根据预先设定的告警策略，当服务运行状态达到告警状态时及时发出告警。告警管理系统的职责包括：
捕捉从探针程序发出经由通信管理器传输的告警;一般而言，这些告警是由超过阈值或者未达到阈值的服务而产生的。
评估每个告警的严重性并连接性能分析引擎，对问题进行分析以及采取自动纠错。如果分析引擎发出指令，告警管理系统则生成纠正措施。告警管理系统还可对运维人员发出告警。
在时间序列数据库中记录每一个告警，包括告警原因和解决方案，以对将来分析提供帮助并确定解决性能问题的正确路径。
路径追踪，更好地确定告警源头以及确定在问题解决过程中应被解决的其他服务。
工具列表
要记住我们在本文中所说明的内容在本质上仅属于概念性范畴。但是从概念性需求出发，得出实际的性能管理方案，这种想法很好。在这一概念过程中，选择相应的技术是最后一步。您有很多开源、专有系统可选，包括但不限于以下系统：
? Sensu
? Graphite-tattle
? Cepmon
? Logstash
? Librato
? PagerDuty
? Umpire alerting-controller
? Graphite
? Statsd
? Logster
? Incinga
? ZeroMQ
? Chef
? Puppet
? Zookeeper
? Riemann
? OpenTSDB
? Ganglia
? TempoDB
? CollectD
? Datadog
? Folsom
? JMXTrans
? Pencil
? Rocksteady
? Boundary
? Circonus
? Gdash
? 监控宝
? 透视宝
? 压测宝
这些工具没有通用模式，都是为性能管理的某些特定方面而专门打造的，您要从中选取几种来完成最终的解决方案。从这一堆产品中挑选适合自己业务的并不简单。我们从事云计算已有一段时间，性能多少是一种事后才考虑的想法。即便如此，当我们把注意力更多地集中在CloudOps和存在于混合云中的业务质量系统上时，我们依然需要把性能管理作为CloudOps配置策略的核心组成部分。现在就解决这一问题，否则将来它将演变成大问题。云智慧编译
原文作者：David Linthicum
====================================分割线================================
本文转自d1net（转载）