CloudNative|云原生应用架构|云原生架构|容器化架构|微服务架构|平台架构|基础架构

简介

Logstash是一个具有实时管线能力的开源数据收集引擎。在ELK Stack中，通常选择更轻量级的Filebeat收集日志，然后将日志输出到Logstash进行加工处理，再将处理后的日志输出到指定的目标（ElasticSearch，Kafka等）当中。

Logstash事件的处理管线是inputs → filters → outputs，三个阶段都可以自定义插件，本文主要介绍如何开发自定义需求最多的filter插件。

Logstash的安装就不详细介绍了，下载传送门：https://www.elastic.co/downloads/logstash。

前置准备

我们使用docker来讲解如何给logstash定制一个filter插件，首先，我们下载logstash官方最新版本的镜像。下载方式: docker pull logstash，下载好后我们就来Run这个镜像，命令：docker run -it logstash bash，这样我们就进入到logstash容器中了。接下来我们就安装下两个基本的软件包，一个vim，一个rsyslog，命令如下：apt-get update && apt-get -y install vim rsyslog && /etc/init.d/rsysylog start。到此我们的准备工作就完毕了。

简介

在为问题寻找解决方案时要先充分了解问题本身，而不是一味地盲目崇拜那些巨头公司。Ozan Onay以Amazon、LinkedIn和Google为例，为执迷不悟的人敲响警钟。以下内容已获得作者翻译授权，查看原文：You Are Not Google。

软件工程师总是着迷于荒唐古怪的事。我们看起来似乎很理性，但在面对技术选型时，总是陷入抓狂——从Hacker News到各种博客，像一只飞蛾一样，来回折腾，最后精疲力尽，无助地飞向一团亮光，跪倒在它的前面——那就是我们一直在寻找的东西。

真正理性的人不是这样做决定的。不过工程师一贯如此，比如决定是否使用MapReduce。

Joe Hellerstein在他的大学数据库教程视频中说道：

世界上只有差不多5个公司需要运行这么大规模的作业。至于其他公司……他们使用了所有的IO来实现不必要的容错。在2000年代，人们狂热地追随着Google：“我们要做Google做过的每一件事，因为我们也运行着世界上最大的互联网数据服务。”

超出实际需求的容错没有什么问题，但我们却为此付出了的惨重的代价：不仅增加了IO，还有可能让原先成熟的系统——包含了事务、索引和查询优化器——变得破碎不堪。这是一个多么严重的历史倒退！有多少个Hadoop用户是有意识地做出这种决定的？有多少人知道他们的决定到底是不是一个明智之举？

MapReduce已经成为一个众矢之的，那些盲目崇拜者也意识到事情不对劲。但这种情况却普遍存在：虽然你使用了大公司的技术，但你的情况却与他们大不一样，而且你的决定并没有经过深思熟虑，你只是习以为常地认为，模仿巨头公司就一定也能给你带来同样的财富。

是的，这又是一篇劝大家“不要盲目崇拜”的文章。不过这次我列出了一长串有用的清单，或许能够帮助你们做出更好的决定。

简介

在2016 LighLoad++大会上，“M-Tex”的开发经理Vadim Madison讲述了从一个由数百个微服务组成的系统到包含数千个微服务的高负载项目的发展历程。本文已获得翻译授权，查看英文原文：Microservices in a High-Load Project 。

我将告诉大家我们是如何开始一个高负载微服务项目的。在讲述我们的经历之前，先让我们简单地自我介绍一下。

简单地说，我们从事视频输出方面的工作——我们提供实时的视频。我们负责“NTV-Plus”和“Match TV”频道的视频平台。该平台有30万的并发用户，每小时输出300TB的内容。这是一个很有意思的任务。那么我们是如何做到的呢？

这背后都有哪些故事？这些故事都是关于项目的开发和成长，关于我们对项目的思考。总而言之，是关于如何提升项目的伸缩能力，承受更大的负载，在不宕机和不丢失关键特性的情况下为客户提供更多的功能。我们总是希望能够满足客户的需求。当然，这也涉及到我们是如何实现这一切，以及这一切是如何开始的。

前言

资深架构师Adam Drake在他的博客上分享了他对微服务的看法,他 从自己的经验出发,结合Martin Fowler对微服务的见解,帮助想要采用 微服务的公司重新审视微服务。以下内容已获得作者翻译授权,查看英文 原文 Enough with the microservices。

简介

关于微服务的优势和劣势已经有过太多的讨论,不过我仍然看到很多 成长型初创公司对它进行着盲目崇拜。冒着“重复发明轮子”的风险(Martin Fowler已经写过“Microservice Premium”的文章),我想把我的一些 想法写下来,在必要的时候可以发给客户,也希望能够帮助人们避免犯下我之前见过的那些错误。在进行架构或技术选型时,将网络上找到的一些所谓的最佳实践文章作为指南,一旦做出了错误的决定,就要付出惨重的代价。如果能够帮助哪怕一个公司避免犯下这种错误,那么写这篇文章都是值得的。

如今微服务是个热门技术,微服务架构一直以来都存在(面向服务架构也算是吧?),但对于我所见过的大部分公司来说,微服务不仅浪费了他们的时间,分散了他们的注意力,而且让事情变得更糟糕。

这听起来似乎很奇怪,因为大部分关于微服务的文章都会肯定微服务 的各种好处,比如解耦系统、更好的伸缩性、消除开发团队之间的依赖, 等等。如果你的公司有 Uber、Airbnb、Facebook 或 Twitter 那样的规模, 那么就没有什么问题。我曾经帮助一些大型组织转型到微服务架构,包括 搭建消息系统和采用一些能够提升伸缩性的技术。不过,对于成长型初创 公司来说,很少需要这些技术和服务。

Russ Miles在他的《让微服务失效的八种方式》这篇文章中表达了 他的首要观点,而在我看来,这些场景却到处可见。成长型初创公司总是 想模仿那些大公司的最佳实践,用它们来弥补自身的不足。但是,最佳实 践是要视情况而定的。有些东西对于 Facebook 来说是最佳实践,但对于 只有不到百人的初创公司来说,它们就不一定也是最佳实践。

如果你的公司比那些大公司小一些,在一定程度上你仍然能够从微服务架构中获益。但是,对于成长型初创公司来说,大规模地迁移到微服务是一种过错,而且对技术人来说是不公平的。

简介

入题之前先讲讲为什么写这篇文章，这就不得不提起MySQL与percona，阿里基于mysql开发了AliSQL，写这篇文章的时候阿里已经将其开源，percona是一家领先的MySQL咨询公司，该公司基于mysql开发了Percona Server，Percona Server是一款独立的数据库产品，为用户提供了换出其MySQL安装并换入Percona Server产品的能力。percona除了开发了多款数据库产品，还开发了数据库监控程序：pmm（Percona Monitoring and Management）服务器，我们都知道mysql自身缺乏实时的监控功能，而此时pmm-server就恰好解决了我们这一难题，好了废话不多说，先看一张pmm server的监控图。

常规的监测项目都有了，最吸引我的一点在于它的慢日志分析功能，如下图所示：