<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>ELK on 月盾的博客</title>
    <link>https://blog.hopefly.top/tags/elk/</link>
    <description>Recent content in ELK on 月盾的博客</description>
    <generator>Hugo</generator>
    <language>zh-cn</language>
    <lastBuildDate>Tue, 26 Dec 2017 15:24:12 +0000</lastBuildDate>
    <atom:link href="https://blog.hopefly.top/tags/elk/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>推荐在Nodejs使用的java常用技术和工具</title>
      <link>https://blog.hopefly.top/blogdetail/5a430ce84aa3290e95cb0e67/</link>
      <pubDate>Tue, 26 Dec 2017 15:24:12 +0000</pubDate>
      <guid>https://blog.hopefly.top/blogdetail/5a430ce84aa3290e95cb0e67/</guid>
      <description>&lt;p&gt;作为Nodejs开发者可能会对java中常用的一些技术工具不太关心，主要原因大概除了语言级别的间隙就是Nodejs相对于java来说比较轻量级，大多用来开发简单系统，用不到其他工具。根据经验来说，开发相同功能的系统，Nodejs的开发周期和代码体量上也会比Java少太多，毕竟java出生年代长，生态丰富，如果不使用几个框架都感觉不是在开发系统。而Nodejs要开发一个web系统基本使用express或koa就差不多够了。所以对于Nodejs开发者来说，分布式，消息队列，远程调用等技术接触就少些。当然，不用这些技术其实也不会有太大影响，但是对于一个有追求有理想的码农来说我们的眼界不应该局限于系统能运行就行。&#xA;下面就来介绍一些可以在nodejs中使用的JAVA常用工具和技术。&lt;/p&gt;&#xA;&lt;h3 id=&#34;elasticsearch&#34;&gt;elasticsearch&lt;/h3&gt;&#xA;&lt;p&gt;ElasticSearch（以下简称ES）是一个基于Lucene的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎，基于RESTful web接口。Elasticsearch是用Java开发的，并作为Apache许可条款下的开放源码发布，是当前流行的企业级搜索引擎。看见了吧，这就是一个使用JAVA开发的全文搜索引擎，到底有什么用呢？就是可以提供像google和百度一样的搜索功能，就算不需要这样功能，也可以用于管理后台的字段搜索，大家知道数据库的搜索效率比较差，有索引的字段还好，没有的就很慢了，这时ES就可以派上用场了，把数据同步进ES,不论查询列表还是以字段搜索都是极快的，是redis缓存的很好补充。&lt;/p&gt;&#xA;&lt;h3 id=&#34;elk&#34;&gt;ELK&lt;/h3&gt;&#xA;&lt;p&gt;ELK（ElasticSearch,LogStash,Kibana）是三个工具的组合,&#xA;Logstash是一款轻量级的日志搜集处理框架，可以方便的把分散的、多样化的日志搜集起来，并进行自定义的处理，然后传输到指定的位置，比如某个服务器或者文件。&#xA;Kibana是一个使用nodejs开发的web应用，用于查询和操作ES，就是一个ES的图形界面。&#xA;如果nodejs系统布署在多台服务器，那么查看日志是件很头疼的事，你不知道请求发送到哪一台服务器，需要挨个查看，如果服务超过5台，这绝对是噩梦。这时候ELK就是很好的解决方案，LogStash收集每一台服务器的日志统一存到ES中，利用ES的优点，查询任何关键字都很快很方便。&lt;/p&gt;&#xA;&lt;h3 id=&#34;消息中间件kafka&#34;&gt;消息中间件（kafka）&lt;/h3&gt;&#xA;&lt;p&gt;拿用户注册为例，需要发送邮件，短信，这两个服务之间本没有关联关系，但我们的一贯作风是用户注册的时候调用邮件服务，短信服务，严谨一点会放在事务中操作，假如一个服务失败可能会让事务回滚，所有操作都失败。这是一种情况，另一种情况是如果要再注册后加积分，那么就得改代码，要是有更多服务要添加就得每次改代码发布，启停服务，不送积分了又要删代码，这就是耦合度太高导致的结果。使用消息中间件不仅能保证服务完整性还可以有效解耦，有兴趣可以去了解kafka,rabbitMQ,roketMQ等消息中间件。&lt;/p&gt;&#xA;&lt;h3 id=&#34;远程调用rpc&#34;&gt;远程调用RPC&lt;/h3&gt;&#xA;&lt;p&gt;通俗的来讲就是两台服务器A和B，A服务器直接调用B服务器上的函数，如果没有一个具体事例很难理解A服务器怎么可能调用到B服务器的函数，感兴趣可下载尝试：&lt;a href=&#34;https://github.com/yuedun/nodejs-grpc&#34;&gt;https://github.com/yuedun/nodejs-grpc&lt;/a&gt;&#xA;那么为什么要用rpc呢？A服务器要调用B服务的资源直接用http提供接口不就行了吗？其实http也算是一种远程调用，而且也比较简单直观，但是其效率较低，调用成本高，三次握手耗时，甚至请求头的数据量比请求体还大。那么就需要一种更高效的调用协议了——rpc。&lt;a href=&#34;http://yuedun.wang/blogdetail/5a375f52e9a4cf008860c09b&#34;&gt;为什么需要RPC，而不是简单的HTTP接口&lt;/a&gt;&lt;/p&gt;&#xA;&lt;p&gt;总结：以上的这些工具和技术和语言并没有绑定，java可以使用，nodejs也可以使用，推荐理由：投入成本小，使用收益高。&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
