• 实体回顾

• 实体大小：Content-Length

  • 实体主体长度确定规则

• 实体摘要：Content-MD5

• 媒体类型：Content-Type

  • 字符编码
  • 多部分媒体

• 内容编码：Content-Encoding

  • 编码过程
  • 编码类型
  • 编码协商

• 传输编码：Transfer-Encoding

  • 首部介绍

  • 分块编码

    • 持久连接
    • 报文分析

  • 编码规则

  • 内容编码与传输编码结合

• 缓存相关

  • 新鲜度
  • 验证码

• 实例操控

  • 范围请求
  • 差异编码

• 国际化

  • 字符集编码：Content-Encoding
  • 语言标记：Content-Language
  • 国际化URL
  • 其他问题

• 主机托管

  • 让建站更容易
  • 让网站更可靠
  • 让网站更快速

• CDN技术概述

  • CDN概述
  • 内容缓存
  • 负载均衡
  • 全局负载均衡

API简介

Zabbix API开始扮演着越来越重要的角色，尤其是在集成第三方软件和自动化日常任务时。很难想象管理数千台服务器而没有自动化是多么的困难。Zabbix API为批量操作、第三方软件集成以及其他作用提供可编程接口。

Zabbix API是在1.8版本中开始引进并且已经被广泛应用。所有的Zabbix移动客户端都是基于API，甚至原生的WEB前端部分也是建立在它之上。Zabbix API 中间件使得架构更加模块化也避免直接对数据库进行操作。它允许你通过JSON RPC协议来创建、更新和获取Zabbix对象并且做任何你喜欢的操作【当然前提是你拥有认证账户】。

Zabbix API提供两项主要功能：

• 远程管理Zabbix配置

• 远程检索配置和历史数据

使用JSON

分区既是为了解决单一广播域问题，也是对安全的一种考虑。

概述

默认情况下，所有的servers属于单一广播域，如果你有一个代理安装在你的网络中所有的机器上，那么你发送给有这个代理的机器的消息就会直接被所有机器收到而无论使用滤器(filters)，这在常规使用中能工作的很好但是在下面这些场景中会出现问题：

• A.拥有一个非常大而拥挤的网络。假设有成千上万机器需要每隔10秒回复请求，大量的消息会被创建，你想给流量分区。

• B.不同的地方拥有多个数据中心，网站流量和延迟很大。你想在每个数据中心复制监控和自动化管理，但是所有都在一个广播域仍会看到大量流量缓慢链路。

• C.需要完成多个独立安装，但仍想保持MCollective中心管理功能。

• D.平面网络(plat network)安全问题。SimpleRPC拥有一个安全框架提醒用户和网络拓扑但是核心网络没有。

Sub collectives允许你定义广播域并且配置一个mcollective属于这些域中的一个或多个。

消息流

• 消息流程

下图展示了MCollective系统的基本消息流。MCollective通过广播范式进行请求分配。客户端发送消息然后广播给整个广播域的节点。

整个流程如下：

步骤及描述

这部分集中概括MCollective所解决问题及选择MCollective的原因，并比较MCollective与SSH循环的优势所在。并简单讨论MCollective给Puppet带来的改变。

• 解决问题

系统发现(System discovery)

信息收集(Inventory Collection)

任务执行(Task Execution)

配置管理(Configuration Management)

这一部分主要包括了后面经常会用到的MCollective术语。

最重要的概念是server,client。这与C/S架构中客户端/服务器端没有必然关系，在MCollective中是多个server<----->一个client的结构

• Server

服务端，简单说就是数据提供方。它是mcollective守护进程，一个负责托管代理和管理中间件连接的应用程序服务器。 + Client

客户端，简单说是数据/信息接收方。它是创建命令让代理去执行的应用程序，特别地这会是一台安装有客户端程序的机器用户可以使用像mco ping这样的命令来与代理交互。通常客户端会使用MCollective::Client库来与Collective通信。

• Node

由于mcollective采用广播范式分发请求，安全是一个复杂的主题。

这些讨论主要集中在加强基于SSL和基于AES+RSA的安全插件,这些虽然不是默认做法或者说仅仅是个选项，但却是目前最安全的做法。SSL安全插件和AES安全插件提供强有力的主叫(caller)识别，这被SimpleRPC框架用于授权和审计。

正如每个组织都会有它们自己的需求，因此几乎安全系统所有的部分都是插件化的。下面是对目前使用的基于SSL的验证、授权和审计情况的介绍。

上面图显示了一个MColletive系统的建立和可能涉及的其他讨论领域。这里主要集中讨论ACtiveMQ中间件，一些细节可能会随着中间件的选择不同而有不同。

这部分的内容只是概述这个过程及可能涉及到的安全问题，对于每一部分将会可能涉及的详细讨论都将穿插在具体小结里。

在概述中已经提到，MCollective的设计采用了摒弃SSH循环、去中心化结构，汲取现代化工具发布订阅中间件和现代化理念使用目标数据实时发现网络资源。这部分就是关于发布订阅中间件的背景介绍。

注：此部分内容主要来源于维基百科

中间件

中间件是指网络环境下位于操作系统等系统软件和应用软件之间的一种连接分布计算实体的分布式软件，它通过提供简单、一致和集成的分布编程环境，简化分布应用的设计、编程和管理。从本质上讲，中间件是一个分布软件层，屏蔽了底层分布环境（网络、主机、操作系统、编程语言）的复杂性和异构性，主要解决异构网络环境下分布应用软件之间的互连、互通和互操作问题，可以提高应用系统的可移植性。自20世纪80年代以来，以CORBA、J2EE、RMI、COM+等技术为代表的中间件技术取得了长足的发展，得到了工业界和学术界的青睐，已经成为分布式系统的主流技术之一。从本质上讲，上述典型中间件的通讯模型属于点到点和同步请求/应答方式。

随着具有异步性、异构性和高度松耦合特性的Internet和大规模Intranet的出现和飞速发展，传统中间件面临的分布计算环境发生了深刻变化。现在的分布式系统可能涉及到数以万计的实体，这些实体可能在地理上分布到世界各地，它们的行为随时间动态地演化，系统实体之间是松耦合的，系统可能涉及异构的数据源，系统要求分布的系统管理。从本质上讲，这类系统的特点是松耦合、异步性、动态性和异构性。传统的中间件具有的点到点和同步通讯模型实际上具有紧耦合的特性，不适合开发这类系统。

这种变化客观上需要一种通讯模型支持具有松耦合、异步性、动态性和异构性等特性的应用需求，P/S通讯模型是满足这种需求的模型之一。以这种通讯模型为基础的P/S中间件得到了工业界和学术界的普遍关注，已经成为研究的热点。