第一章 Elastic Stack入门

一、预备知识Restful

1、起源

在没有前后端分离概念之前，一个网站的完成总是“all in one”，在这个阶段，页面、数据、渲染全部在服务端完成，这样做的最大的弊端是后期维护， 扩展极其痛苦，开发人员必须同时具备前后端知识。于是后来慢慢的兴起了前后端分离的思想：即后端负责数据编造，而前端则负责数据渲染，前端静态页面调用指定api获取到有固定格式的数据，再将数据展示出来，这样呈现给用户的就是一个”动态“的过程。而关于api这部分的设计则成了一个问题。如何设计出一个便于理解，容易使用的api则成了一个问题，而所谓的RESTful就是用来规范我们的API的一种约束。

1.1、REST

作为REST，其实是Representational State Transfer（表象层状态转变）三个单词的缩写，它由Roy Fielding(Fielding是HTTP协议1.0版和1.1版）的主要设计者、Apache服务器软件的作者之一、Apache基金会的第一任主席) 于2000年论文中提出，他在论文中提到："我这篇文章的写作目的，就是想在符合架构原理的前提下，理解和评估以网络为基础的应用软件的架构设计，得到一个功能强、性能好、适宜通信的架构。REST指的是一组架构约束条件和原则。"

如果一个架构符合REST的约束条件和原则，我们就称它为RESTful架构。要理解RESTful架构，最好的方法就是去理解Representational State Transfer这个词组到底是什么意思，它的每一个词代表了什么涵义。如果你把这个名称搞懂了，也就不难体会REST是一种什么样的设计。

1.2、资源（Resources）

REST的名称"表现层状态转化"中，省略了主语。"表现层"其实指的是"资源"（Resources）的"表现层"。 所谓"资源"，就是网络上的一个实体，或者说是网络上的一个具体信息。它可以是一段文本、一张图片、一首歌曲、一种服务，总之就是一个具体的实在。要让一个资源可以被识别，需要有个唯一标识，在Web中这个唯一标识就是URI(Uniform Resource Identifier)。URI既可以看成是资源的地址，也可以看成是资源的名称。如果某些信息没有使用URI来表示，那它就不能算是一个资源，只能算是资源的一些信息而已。

你可以用一个URI（统一资源定位符）指向它，每种资源对应一个特定的URI。要获取这个资源，访问它的URI就可以，因此URI就成了每一个资源的地址或独一无二的识别符。所谓"上网"，就是与互联网上一系列的"资源"互动，调用它的URI。

2、URI设计技巧

2.1、使用_或-来让URI可读性更好

曾经Web上的URI都是冰冷的数字或者无意义的字符串，但现在越来越多的网站使用_或-来分隔一些单词，让URI看上去更为人性化。例如国内比较出名的开源中国社区，它上面的新闻地址就采用这种风格， 如http://www.oschina.net/news/38119/oschina-translate-reward-plan。

2.2、使用/来表示资源的层级关系

例如上述/git/git/commit/e3af72cdafab5993d18fae056f87e1d675913d08就表示了一个多级的资源，指的是git用户的git项目的某次提交记录，又例如/orders/2012/10可以用来表示2012年10月的订单记录。

2.3、使用?用来过滤资源

很多人只是把‘?’简单的当做是参数的传递，很容易造成URI过于复杂、难以理解。可以把‘?’用于对资源的过滤，例如/git/git/pulls用来表示git项目的所有推入请求，而/pulls?state=closed用来表示git项目中已经关闭的推入请求，这种URL通常对应的是一些特定条件的查询结果或算法运算结果。

2.4、‘,’或’;’可以用来表示同级资源的关系

有时候我们需要表示同级资源的关系时，可以使用,或;来进行分割。例如哪天github可以比较某个文件在随意两次提交记录之间的差异，或许可以使用：

/git/git/block-sha1/sha1.h/compare/e3af72cdafab5993d18fae056f87e1d675913d08;bd63e61bdf38e872d5215c07b264dcc16e4febca作为URI。不过，现在github是使用…来做这个事情的，例如/git/git/compare/master…next。

2.5、URI不应该包含动词

因为"资源"表示一种实体，所以应该是名词，URI不应该有动词，动词应该放在HTTP协议中。

举例来说，某个URI是/posts/show/1，其中show是动词，这个URI就设计错了，正确的写法应该是/posts/1，然后用GET方法表示show。

如果某些动作是HTTP动词表示不了的，你就应该把动作做成一种资源。比如网上汇款，从账户1向账户2汇款500元，错误的URI是：POST /accounts/1/transfer/500/to/2，正确的写法是把动词transfer改成名词transaction，资源不能是动词，但是可以是一种服务。

2.6、URI中不宜加入版本号

例如：

http://www.example.com/app/1.0/foo

http://www.example.com/app/1.1/foo

http://www.example.com/app/2.0/foo

因为不同的版本，可以理解成同一种资源的不同表现形式，所以应该采用同一个URI。版本号可以在HTTP请求头信息的Accept 段中进行区分。

3、表现层Representation

"资源"是一种信息实体，它可以有多种外在表现形式。我们把"资源"具体呈现出来的形式，叫做它的"表现层"Representation。比如，文本可以用txt格式表现，也可以用HTML格式、XML格式、JSON格式表现，甚至可以采用二进制格式；图片可以用JPG格式表现，也可以用PNG格式表现。

URI只代表资源的实体，不代表它的形式。严格地说，有些网址最后的".html"后缀名是不必要的，因为这个后缀名表示格式，属于"表现层"范畴，而URI应该只代表"资源"的位置。它的具体表现形式，应该在HTTP请求的头信息中用Accept和Content-Type字段指定，这两个字段才是对"表现层"的描述。

4、状态转化State Transfer

访问一个网站，就代表了客户端和服务器的一个互动过程。在这个过程中，势必涉及到数据和状态的变化。互联网通信协议HTTP协议，是一个无状态协议。这意味着，所有的状态都保存在服务器端。因此，如果客户端想要操作服务器，必须通过某种手段，让服务器端发生"状态转化"（State Transfer）。而这种转化是建立在表现层之上的，所以就是"表现层状态转化"。

客户端用到的手段，目前来说只能是HTTP协议。具体来说，就是HTTP协议里面，四个表示操作方式的动词：GET、POST、PUT、DELETE。它们分别对应四种基本操作：GET 用来获取资源，POST 用来新建资源（也可以用于更新资源），PUT用来更新资源，DELETE 用来删除资源。GET、PUT和DELETE 请求都是幂等的，无论对资源操作多少次，结果总是一样的，POST不是幂等的。

5、什么是RESTful架构

综合上面的解释，我们总结一下什么是RESTful架构：

• 架构里，每一个URI代表一种资源；
• 客户端和服务器之间，传递这种资源的某种表现层；
• 客户端通过四个HTTP动词（get、post、put、delete），对服务器端资源进行操作，实现”表现层状态转化”。

注意：REST架构风格并不是绑定在HTTP上，只不过目前HTTP是唯一与REST相关的实例。所以我们这里描述的REST也是通过HTTP实现的REST。

6、辨URI、URL、URN

RFC 3986中是这样说的：A Uniform Resource Identifier (URI) 是一个紧凑的字符串用来标示抽象或物理资源。 一个URI可以进一步被分为定位符、名字或两者都是，术语“Uniform Resource Locator” (URL)是URI的子集，除了确定一个资源,还提供一种定位该资源的主要访问机制。

所以，URI = Universal Resource Identifier 统一资源标志符，包含URL和URN，支持的协议有http、https、ftp、mailto、magnet、telnet、data、file、nfs、gopher、ldap等，java还大量使用了一些非标准的定制模式，如 rmi，jar、jndi和doc，来实现各种不同用途。

URL = Universal Resource Locator统一资源定位符，URL唯一地标识一个资源在Internet上的位置。不管用什么方法表示，只要能定位一个资源，就叫URL。

URN = Universal Resource Name统一资源名称，URN它命名资源但不指定如何定位资源，比如：只告诉你一个人的姓名，不告诉你这个人在哪。对于一个资源来说，URN好比他的名字，而RL好比是资源的街道住址。换句话说，URN 标识了一个资源项目，而 URL 则提供了一种找到他的方法。

比如同时指定基本的获取机制和网络位置。举个例子，http://example.org/wiki/Main_Page，指向了一个被识别为/wike/Main_Page的资源，这个资源的表现形式是HTML和相关的代码。而获取这个资源的方法是在网络中从一个名为example.org 的主机上，通过 HTTP( Hypertext Transfer Protocol)获得。

而URN则是一种在特定的名称空间中通过通过名字来标识资源的 URI。当讨论一种资源而不需要知道它的位置或者如何去获得它的时候，就可以使用 URN。例如，在 International Standard Book Number (ISBN)系统中，* ISBN 0-486-27557-4 用来指定莎士比亚的作品《罗密欧与朱丽叶》的一个特定版本。

指示这一版本的URN是urn:isbn:0-486-27557-4*，但是如果想要获得这个版本的书，就需要知道它的位置，这样就必须知道它的 URL。 

二、ELK介绍

1、为什么需要ELK？

官网的说法：Elasticsearch是一个开源的分布式RESTful搜索和分析引擎，能够解决越来越多不同的应用场景。看一个应用场景，常见的WEB应用日志分析。一般我们会怎么做？

登录到每台服务器上，直接在日志文件中grep、awk就可以获得自己想要的信息。但在规模较大的场景中，此方法效率低下，面临问题包括日志量太大如何归档、文本搜索太慢怎么办、如何多维度查询。这个时候我们希望集中化的日志管理，所有服务器上的日志收集汇总。常见解决思路是建立集中式日志收集系统，将所有节点上的日志统一收集，管理，访问。

这样对于大型系统来说，都是一个分布式部署的架构，不同的服务模块部署在不同的服务器上，问题出现时，大部分情况需要根据问题暴露的关键信息，定位到具体的服务器和服务模块，构建一套集中式日志系统，可以提高定位问题的效率。

一个完整的集中式日志系统，需要包含以下几个主要特点：

• 收集－能够采集多种来源的日志数据
• 传输－能够稳定的把日志数据传输到中央系统
• 存储－如何存储日志数据分析－可以支持
• UI分析警告－能够提供错误报告，监控机制

ELK就是这样一整套解决方案，并且都是开源软件，之间互相配合使用，完美衔接，高效的满足了很多场合的应用，而不仅仅是日志分析。

2、什么是ELK？

ELK是三个开源软件的缩写，分别表示：Elasticsearch、Logstash、Kibana，它们都是开源软件。

Elasticsearch是个开源分布式搜索引擎，提供搜集、分析、存储数据三大功能。

 

它的特点有：分布式，零配置，自动发现，索引自动分片，索引副本机制，restful风格接口，多数据源，自动搜索负载等。

Logstash主要是用来做日志的