该图片由Joaquin Aranoa在Pixabay上发布

你好，我是看山。

现在手机越来越便宜，换手机是比较常见的一件事，所以各大厂商为了降低更换手机的成本，也是各种手段费尽心思：一键换机、云账号。但是这些方式都建立在一个基础上，就是同品牌手机才能用。如果是跨品牌换机，那真是要经历九九八十一难，百转千回才能顺利使用新机。像我这种懒人，可能还要在很长一段时间继续使用旧手机。

随着微服务架构的普及，线上服务越来越多，随之而来的就是部署越来越频繁；随着互联网行业的兴旺，产品迭代的频率也是越来越快，服务上线速度逐步提升。有上线、有部署，就有风险。有风险，就对业务有影响，然后就有了一系列减少这种风险的部署方案：蓝绿部署、金丝雀发布（灰度发布），也有适应产品迭代频率的AB测试。

本文主要是简单解释下这几个概念，帮助自己理解，如果有错误，请大佬们斧正。

写在前面：Vary 是一个HTTP响应头部信息，它决定了对于未来的一个请求头，应该用一个缓存的回复(response)还是向源服务器请求一个新的回复。它被服务器用来表明在 content negotiation algorithm（内容协商算法）中选择一个资源代表的时候应该使用哪些头部信息（headers）。

Spring Cloud Config是Spring Cloud一个全新的项目，依赖版本仓库（比如Git、SVN）实现分布式系统外部配置的集中管理。
文中Spring Cloud的版本是Dalston.SR4，可能在其他之后的版本有修改。

最近这段时间在学习Spring Cloud，准备在项目中使用。Spring Cloud不能简单的算是一个框架，而应该认为是一个微服务的整体解决方案，它集成了Spring Boot、Netflix等等很多非常优秀的框架，很多组件开箱即用。也正是因为它集成了这么多框架，致使其版本不够稳定，即使是SR的版本，也存在这样那样的问题。甚至有的上一个版本没有问题，这个版本就出问题了。

该图片由Kanenori在Pixabay上发布

你好，我是看山。

前段时间对自己的项目进行代码质量扫描，曾经以为自己的代码质量算是不错的，结果发现一堆的 bug 或者 smell code，灵魂受到 1w 点伤害。

可以想到，在时间紧、任务重的情况下，代码质量绝对是不能够保证的，虽然功能算是完整，但是可能就在某个隐藏的角落，就有无数的 bug 在潜伏着，所以有时间的话都对自己的代码进行代码质量检查吧。虽然不能保证有完美的代码，但是可以把 bug 数降低，也可以根据扫描的结果养成良好的编程习惯。

身为程序员就得严谨。

闲言碎语不再讲。

本文主要是介绍通过 Jenkins Pipeline 与 SonarQube 集成，对代码进行扫描，这里使用的是 Jenkins2.19.1，SonarQube6.4。

该图片由Here and now, unfortunately, ends my journey on Pixabay在Pixabay上发布

你好，我是看山。

java.lang.OutOfMemoryError这个错误是比较经典的错误了，经过JDK不断的迭代，服务器硬件的不断升级。。。总之，社会在发展，时代在进步。很多错误已经消失在时代的浪潮中。我也是很久没有见过这个错误了，以至于都以为在Java的世界中不会再碰到这个错误。结果，就在最疏忽的时候碰到了TA，真是，心中一万只神兽奔袭而过，狠狠的践踏了我这颗上了年纪的心脏啊。

吐槽完毕，言归正传。

Java刚刚出现的年代，有一个相比于其他语言的优势就是，内存回收机制。不需要明确的调用释放内存的API，java就自动完成，这个过程就是Garbage Collection，简称GC。这对以懒著称的程序猿们来说，绝对是重大利好。但是，凡事有利必有弊，可以肯定的是，Java语言是人创造的，GC也是人编写的代码，绝对不是机器自动完成的。也就是说，GC的过程是另外一群程序猿根据可能出现的情况，预设了GC条件，把符合回收条件的内存空间释放出来。一旦被占用的内存空间不符合释放的条件，GC没办法清理，那就会适时出现java.lang.OutOfMemoryError。这个错误就是提醒我们这群程序猿，写GC程序的程序猿不知道这种情况怎么处理，为了安全也不便处理，谁使用Java就自己看着解决吧。

说起来，java.lang.OutOfMemoryError有几种分类的，这次碰到的是java.lang.OutOfMemoryError: GC overhead limit exceeded，下面就来说说这种类型的内存溢出。

你好，我是看山。

最近在写一个应用监控的项目，使用 netty 作为数据传输。因为刚开始写，没有使用 Protobuf 之类的作为编码工具，只是使用的是 netty 自带的LengthFieldBasedFrameDecoder作为报文解析工具，自定义编码解码类，实现数据传输。

本来一切正常，结果在昨天测试的过程中，传输的数据体总是少 16 个字符，甚是奇怪。

陆续的把Hadoop集群部署、HDFS的HA配置完成，把ResourceManager的HA配置好之后，Hadoop集群配置也算是完整了，可以满足小型中型生产环境Hadoop集群搭建的需要。如果真要搭建超大型的Hadoop集群，这些只能算是参考，还需要修改很多其他参数，使性能更好一些。

ResourceManager（RM）负责跟踪集群中资源使用情况，调度应用程序（比如MapReduce作业）。在Hadoop 2.4之前，ResourceManager存在单点故障，需要通过其他方式实现HA。官方给出的HA方案是Active/Standby两种状态ResourceManager的冗余方式，类似于HDFS的HA方案，也就是通过冗余消除单点故障。

对Hadoop有过了解的都知道，Hadoop经历过很长一段时间的版本号混乱和架构调整，YARN是Hadoop 2.0（或者早期的0.23.x）提出的资源管理、任务调度框架。解决了很多Hadoop 1.0（或者0.21.x、0.22.x）时代的痛点。

随着发展，YARN不仅仅是Hadoop的资源调度框架，还成为一个通用的资源调度管理器，可以将各种各样的计算框架通过YARN管理起来，比如Strom、Spark等。

YARN的基本思想是将资源管理和作业调度/监控的功能分为独立的守护进程。分别是一个全局的 ResourceManager（RM） 和每个应用程序的 ApplicationMaster（AM）。应用程序可以是一个job作业或者一组job作业的有向无环图（DAG）。

ResourceManager负责系统中的所有应用程序的资源分配。NodeManager负责每台机器中容器代理、资源监控（cpu，内存，磁盘，网络），并将这些情况报告给ResourceManager或Scheduler。

每个应用的ApplicationMaster是一个框架特定的库，从ResourceManager协商资源，并与NodeManager共同执行监听任务。

从结构上看，YARN是主/从架构，一个ResourceManager，多个NodeManager，共同构成了数据计算框架。

本文是在hadoop集群部署(yarn)基础上增加的配置内容，因为那篇缺少HDFS的HA配置，在生产环境不够完整。

hadoop官方提供了两种HDFS的HA配置方案，两种方案殊途同归，但是需要的钱、精力和技术不同。

如果对HDFS架构熟悉的话（如果不熟悉，可以通过HDFS架构了解），就应该知道，NameNode通过FsImage和EditLog两个文件管理DataNode的数据，Secondary NameNode会定期合并EditLog，以减少NameNode启动时的安全检查。EditLog文件存储的是对文件的一条条的操作，也就是说，只要保证有另外一个NameNode的EditLog文件一直与当前正在运行的NameNode的EditLog文件是一样的，那就可以随时使用新的NameNode替换老的NameNode。官方目前给出的两种HA方案也大体是这样：

• QJM：the Quorum Journal Manager，翻译是法定经济管理人，实在没法想象，所以大家都亲切的称之为QJM。这种方案是通过JournalNode共享EditLog的数据，使用的是Paxos算法（没错，zookeeper就是使用的这种算法），保证活跃的NameNode与备份的NameNode之间EditLog日志一致。
• NFS：Network File System 或 Conventional Shared Storage，传统共享存储，其实就是在服务器挂载一个网络存储（比如NAS），活跃NameNode将EditLog的变化写到NFS，备份NameNode检查到修改就读取过来，是两个NameNode数据一致。

客观的说，Secondary NameNode也算是对NameNode的备份，但是使用Secondary NameNode需要手动处理，不如QJM和NFS两种可以自动处理简单，所以没有被列入HA解决方案中。

但是，这两种方案在部署方式上差别比较大。QJM需要启动几个JournalNode即可，NFS需要挂在一个共享存储。因为条件限制，我只能通过QJM的方式实现HDFS的HA，如果想看NFS方案，可以直接看官方文档。