王鸿飞的专栏

在上一篇文章中，我们解决了子系统之间的通讯问题，并跑起来了一个模型项目。这里我们要详细实现服务端程序。我们在服务端运行Spring，利用Spring的IoC容器来管理所有的Service组件，然后根据接收到的JMS消息通过反射动态调用Service方法。首先要先设计一下协议：public class MessageProtocol implements Serializable { /**

使用Filebeat + ES + Kibina的组合进行日志收集的一个优点就是轻量级，因为去掉了笨重的logstash, 占用资源更少。但这也引入了一个问题，即filebeat并没有logstash那样强大的日志解析能力，往往只能把整条日志当成一个整体扔到ES中。好消息是，ES从5.x版本开始引入了Ingest Node，即允许你在对文档进行索引之前进行预处理，且支持logstash的Grok语...

我们的日志收集系统使用Filebeat来收集日志文件，部署时并没有多想，只配置了一下监控的日志文件名。上线几个月，日志监控从没出过问题。后来想想其实这里面有很多点需要考虑的，没出问题真是感谢Filebeat默认配置下想的就很周全。业务系统使用logback作为日志框架。通过查看源码，发现logback日志切割用的是JDK里File#renameTo()方法。如果该方法失败，就再尝试使用复制数据的方式

技术架构在向Spring Cloud转型时，一定会有一些年代较久远的项目，代码已变成天书，这时就希望能在不大规模重构的前提下将这些传统应用接入到Spring Cloud架构体系中作为一个服务以供其它项目调用。这时我们就需要使用原生的Eureka/Ribbon手动完成注册中心、查询服务列表功能。如果是非Java项目，可以使用 Spring Sidecar 项目接入Spring Cloud形成异构系统,

问题场景服务器上分别配置了eth0, eth1和eth2三块网卡，只有eth1的地址是可供其它机器访问，eth0和eth2的 IP 无效。在这种情况下，服务注册时Eureka Client会自动选择eth0作为服务ip, 导致其它服务无法调用。问题原因由于官方并没有写明Eureka Client探测本机IP的逻辑，所以只能翻阅源代码。Eureka Client的源码在eureka-client模块下

前言系统一旦走向分布式，其复杂程度成倍增长，传统单体应用只考虑业务逻辑的开发方式已经不再适用。正因其复杂性，目前只有业务需求大的大型互联网公司才会（被迫）采用，而且需要投入大量的技术力量来开发基础设施，也造成了小公司“用不起”分布式架构的情况。现在这一局面正在逐渐被打破，因为Netflix开源了其经过实战考验的一系列基础设施构件，加上Spring Cloud的大力支持，开发分布式系统已经不再像以前那

Eureka不会进行二次同步注册信息Eureka会将本实例中的注册信息同步到它的peer节点上，这是我们都知道的特性。然而，当peer节点收到同步数据后，并不会将这些信息再同步到它自己的peer节点上。如果有A, B, C三个实例，A配B, B配C, C配A, 那么当向A注册一个新服务时，只有A, B两个Eureka实例会有新服务的注册信息，C是没有的。这一点在官方wiki上并没有明确说明。下面通过

在Spring Cloud Netflix栈中，各个微服务都是以HTTP接口的形式暴露自身服务的，因此在调用远程服务时就必须使用HTTP客户端。我们可以使用JDK原生的URLConnection、Apache的Http Client、Netty的异步HTTP Client, Spring的RestTemplate。但是，用起来最方便、最优雅的还是要属Feign了。Feign简介Feign是一种声明式

本文不是讲解如何使用Spring Cloud的教程，而是探讨Spring Cloud是什么，以及它诞生的背景和意义。背景2008年以后，国内互联网行业飞速发展，我们对软件系统的需求已经不再是过去”能用就行”这种很low的档次了，像抢红包、双十一这样的活动不断逼迫我们去突破软件系统的性能上限，传统的IT企业”能用就行”的开发思想已经不能满足互联网高并发、大流量的性能要求。系统架构走向分布式已经是服务器

在分布式消息系统中，消息的传输担保有两个层面的含义，一是对消息发送与接收的担保，二是对消息成功处理的担保。我们常说的at most once, at least once与exactly once在这两层中意义是不同的。at most once 如果只论消息的收发，那么消息只会被投递一次而不管能否被consumer收到。如果考虑消息的处理，那么这条消息可能会因为没有收到而未处理，也可能因为收到以

微服务(MicroServices)架构是当前互联网业界的一个技术热点，圈里有不少同行朋友当前有计划在各自公司开展微服务化体系建设，他们都有相同的疑问：一个微服务架构有哪些技术关注点(technical concerns)？需要哪些基础框架或组件来支持微服务架构？这些框架或组件该如何选型？笔者之前在两家大型互联网公司参与和主导过大型服务化体系和框架建设，同时在这块也投入了很多时间去学习和研究，有一

Kafka是linkedin用于日志处理的分布式消息队列，linkedin的日志数据容量大，但对可靠性要求不高，其日志数据主要包括用户行为（登录、浏览、点击、分享、喜欢）以及系统运行日志（CPU、内存、磁盘、网络、系统及进程状态）。 当前很多的消息队列服务提供可靠交付保证，并默认是即时消费（不适合离线）。高可靠交付对linkedin的日志不是必须的，故可通过降低可靠性来提高性能，同时通过构

一只单核的处理器可以形象得比喻成一条单车道。设想下，你现在需要收取这条道路的过桥 费 - 忙于处理那些将要过桥的车辆。你首先当然需要了解些信息，例如车辆的载重、以及还有多少车辆正在等待过桥。如果前面没有车辆在等待，那么你可以告诉后面的司机通过。 如果车辆众多，那么需要告知他们可能需要稍等一会。　　因此，需要些特定的代号表示目前的车流情况，例如：　　0.00 表示目前桥面上没有任何的车流。 实际上这种

tbschedule项目其实可以分为两部分：schedule管理控制台。负责控制、监控任务执行状态实际执行job的客户端机器。在实际使用时，首先要启动zookeeper, 然后部署tbschedule web界面的管理控制台，最后启动实际执行job的客户机器。这里zookeeper并不实际控制任务调度，它只是负责与N台执行job的客户端通讯，协调、管理、监控这些机器的运行信息。实际分配任务的是

在一个大型网站中，如果要把整个业务拆分成N个子业务，每个业务单独部署到一台服务器上，那么需要解决的问题有：自身的部署。是部署到JavaEE容器中随容器启动，还是做为一个standalone程序单独启动？子系统如何暴露服务接口(如何与其它系统进行通讯)。服务请求者直接通过Socket直连，还是通过Web Service, RMI等技术？这里我们尝试通过standalone方式部署，通过JMS中间

在使用filebeat监控日志文件时，如果不会做任何配置的话你可能会发现一些奇怪的问题，即有时新的日志行会马上发送到目标输出地，有时候却要延迟近10s才会被发送。要解决这个问题，首先要明确filebeat中几个组件的作用和几个重要的参数的含意，如下：Input组件input组件负责监控日志文件(目录)自身的变化情况，如某文件被移动、删除了或创建了新文件，然后将这些信息提供给Harvester...