缘起—lombok 引发的惨案

Lombok 是一种 Java™ 实用工具，可用于帮助开发人员消除 Java 的冗长，尤其是对于简单的 Java 对象（POJO）。它通过注解实现这一目的。

最近一个新项目中开始使用了 lombok，由于其真的是太简单易懂了，以至于我连文档都没看，直接就上手使用了，引发了一桩惨案。

写这篇文章的动机，是缘起于微信闲聊群的一场讨论，粗略整理下，主要涉及了以下几个具体的问题：

看过我公众号简介的朋友会发现，我公众号的定位是分享一些个人的技术博客和杂谈，这其中的杂谈不仅包括了技术杂谈，也包含了自己的一些感悟。所以借此澄清，这是一篇杂文！总结了我在魔都这一年半不同角度的感悟。

技术沙龙

我前几天刚发过一个朋友圈：魔都得天独厚的优势便是各种技术沙龙，其中不乏有很多是免费的。我在魔都这些日子，参加了大概 13-15 场技术沙龙。参加这种技术分享会的动机很单纯，大家都是去学习互联网最前沿的技术的，但隐性的好处也很多：

1. 你可以认识很多跟你同样有积极性的同行们，试想一下，这样一批放弃了周末休息时间，不睡懒觉，不打游戏，不陪妹子的人，必然是对技术充满了热情的一帮人。我有不少微信好友是在技术分享会上添加的。
2. 有些朋友身处传统行业，平时的业务接触不到高并发，JVM 这些看似高大上的名词，但是技术沙龙带来了这样的可能性，让你没吃过猪肉，至少见过猪跑。映像比较深刻的是“美团点评技术团队”定期举办的技术沙龙，参加了两次，分享的很棒，而且大多数情况下，只需要在 APP 中报名即可参加。
3. 同行间的技术方案分享。很有可能你正在负责公司某块业务的技术选型，而沙龙正好涉及了相关的内容，可以静静聆听下别人的解决方案，通过别人落地的架构，来指导自己的选型。这一点我也有例子真实的例子与之对应，大概是 17 年初，有一场 daocloud 举办的 springcloud 社区沙龙，由 DD 带来的 zuul 源码解读以及案例分享，记忆尤为深刻，当时我所在的公司也恰巧在对 zuul 进行改造，而 DD 分享的主题对于我的工作非常有帮助。

上一篇文章分析了服务的注册与发现，这一篇文章着重分析下 RPC 框架都会用到的集群的相关知识。

集群 (Cluster) 本身并不具备太多知识点，在分布式系统中，集群一般涵盖了负载均衡（LoadBalance），高可用（HA），路由（Route）等等概念，每个 RPC 框架对集群支持的程度不同，本文着重分析前两者 – 负载均衡和高可用。

记得前几个月，spring4all 社区刚搞过一次技术话题讨论：如何对 JPA 或者 MyBatis 进行技术选型？传送门：http://www.spring4all.com/article/391 由于平时工作接触较多的是 JPA，所以对其更熟悉一些，这一篇文章记录下个人在使用 JPA 时的一些小技巧。补充说明：JPA 是一个规范，本文所提到的 JPA，特指 spring-data-jpa。

tips：阅读本文之前，建议了解值对象和实体这两个概念的区别。

使用 @Embedded 关联一对一的值对象

现实世界有很多一对一的关联关系，如人和身份证，订单和购买者…而在 JPA 中表达一对一的关联，通常有三种方式。下面就以订单（Order）和购买者（CustomerVo）为例来介绍这三种方式，这里 CustomerVo 的 Vo 指的是 Value Object。

最近在研究 skywalking，发现其作为一个 APM 框架，比起作为 trace 框架的 zipkin 多了一个监控维度：对 JVM 的监控。而 skywalking 集成进系统的方式也和传统的框架不太一样，由于其需要对 JVM 进行无侵入式的监控，所以借助了 JAVA5 提供的 Instrument 机制。关于“Instrument”这个单词，没找到准确的翻译，个人理解为“增强，装配”。

统一中文文案、排版的相关用法，降低团队成员之间的沟通成本，增强网站气质。原文出处：https://github.com/mzlogin/chinese-copywriting-guidelines

• 目录

  • 空格
    • 中英文之间需要增加空格
    • 中文与数字之间需要增加空格
    • 数字与单位之间无需增加空格
    • 全角标点与其他字符之间不加空格
    • -ms-text-autospace to the rescue?
  • 标点符号
    • 不重复使用标点符号
  • 全角和半角
    • 使用全角中文标点
    • 数字使用半角字符
    • 遇到完整的英文整句、特殊名词，其內容使用半角标点
  • 名词
    • 专有名词使用正确的大小写
    • 不要使用不地道的缩写
  • 争议
    • 链接之间增加空格
    • 简体中文使用直角引号
  • 工具
  • 谁在这样做？
  • 参考文献

开头先废话几句，有段时间没有更新博客了，除了公司项目比较忙之外，还有个原因就是开始思考如何更好地写作。远的来说，我从大一便开始在 CSDN 上写博客，回头看那时的文笔还很稚嫩，一心想着反正只有自己看，所以更多的是随性发挥，随意吐槽，内容也很简陋：刷完一道算法题记录下解题思路，用 JAVA 写完一个 demo 之后，记录下配置步骤。近的来看，工作之后开始维护自己的博客站点: www.cnkirito.moe 也会同步更新自己公众号。相比圈子里其他前辈来说，读者会少很多，但毕竟有人看，每次动笔之前便会开始思考一些事。除了给自己的学习经历做一个归档，还多了一些顾虑：会不会把知识点写错？会不会误人子弟？自己的理解会不会比较片面，不够深刻？等等等等。但自己的心路历程真的发生了一些改变。在我还是个小白的时候，学习技术：第一个想法是百度，搜别人的博客，一步步跟着别人后面配置，把 demo run 起来。而现在，遇到问题的第一思路变成了：源码 debug，官方文档。我便开始思考官方文档和博客的区别，官方文档的优势除了更加全面之外，还有就是：“它只教你怎么做”，对于一个有经验有阅历的程序员来说，这反而是好事，这可以让你有自己的思考。而博客则不一样，如果这个博主特别爱 BB，便会产生很多废话（就像本文的第一段），它会有很多作者自己思考的产物，一方面它比官方文档更容易出错，更容易片面，一方面它比官方文档更容易启发人，特别是读到触动到我的好文时，会抑制不住内心的喜悦想要加到作者的好友，这便是共情。我之后的文章也会朝着这些点去努力：不避重就轻，多思考不想当然，求精。

最近瞥了一眼项目的重启脚本，发现运维一直在使用 kill -9 <pid> 的方式重启 springboot embedded tomcat，其实大家几乎一致认为：kill -9 <pid> 的方式比较暴力，但究竟会带来什么问题却很少有人能分析出个头绪。这篇文章主要记录下自己的思考过程。

kill -9 和 kill -15 有什么区别？

在以前，我们发布 WEB 应用通常的步骤是将代码打成 war 包，然后丢到一个配置好了应用容器（如 Tomcat，Weblogic）的 Linux 机器上，这时候我们想要启动 / 关闭应用，方式很简单，运行其中的启动 / 关闭脚本即可。而 springboot 提供了另一种方式，将整个应用连同内置的 tomcat 服务器一起打包，这无疑给发布应用带来了很大的便捷性，与之而来也产生了一个问题：如何关闭 springboot 应用呢？一个显而易见的做法便是，根据应用名找到进程 id，杀死进程 id 即可达到关闭应用的效果。

上述的场景描述引出了我的疑问：怎么优雅地杀死一个 springboot 应用进程呢？这里仅仅以最常用的 Linux 操作系统为例，在 Linux 中 kill 指令负责杀死进程，其后可以紧跟一个数字，代表 ** 信号编号 **(Signal)，执行 kill -l 指令，可以一览所有的信号编号。

在我们之前 RPC 原理的分析中，主要将笔墨集中在 Client 和 Server 端。而成熟的服务治理框架中不止存在这两个角色，一般还会有一个 Registry（注册中心）的角色。一张图就可以解释注册中心的主要职责。

• 注册中心，用于服务端注册远程服务以及客户端发现服务
• 服务端，对外提供后台服务，将自己的服务信息注册到注册中心
• 客户端，从注册中心获取远程服务的注册信息，然后进行远程过程调用

目前主要的注册中心可以借由 zookeeper，eureka，consul，etcd 等开源框架实现。互联网公司也会因为自身业务的特性自研，如美团点评自研的 MNS，新浪微博自研的 vintage。

本文定位是对注册中心有一定了解的读者，所以不过多阐述注册中心的基础概念。

协议（Protocol）是个很广的概念，RPC 被称为远程过程调用协议，HTTP 和 TCP 也是大家熟悉的协议，也有人经常拿 RPC 和 RESTFUL 做对比，后者也可以被理解为一种协议… 我个人偏向于把“协议”理解为不同厂家不同用户之间的“约定”，而在 RPC 中，协议的含义也有多层。

Protocol 在 RPC 中的层次关系

翻看 dubbo 和 motan 两个国内知名度数一数二的 RPC 框架（或者叫服务治理框架可能更合适）的文档，他们都有专门的一章介绍自身对多种协议的支持。RPC 框架是一个分层结构，从我的这个《深入理解 RPC》系列就可以看出，是按照分层来介绍 RPC 的原理的，前面已经介绍过了传输层，序列化层，动态代理层，他们各自负责 RPC 调用生命周期中的一环，而协议层则是凌驾于它们所有层之上的一层。简单描述下各个层之间的关系：

protocol 层主要用于配置 refer（发现服务） 和 exporter（暴露服务） 的实现方式，transport 层定义了传输的方式，codec 层诠释了具体传输过程中报文解析的方式，serialize 层负责将对象转换成字节，以用于传输，proxy 层负责将这些细节屏蔽。

它们的包含关系如下：protocol > transport > codec > serialize

motan 的 Protocol 接口可以佐证这一点：

1
2
3
4
5

public interface Protocol {
    <T> Exporter<T> export(Provider<T> provider, URL url);
    <T> Referer<T> refer(Class<T> clz, URL url, URL serviceUrl);
    void destroy();
}

我们都知道 RPC 框架支持多种协议，由于协议处于框架层次的较高位置，任何一种协议的替换，都可能会导致服务发现和服务注册的方式，传输的方式，以及序列化的方式，而不同的协议也给不同的业务场景带来了更多的选择，下面就来看看一些常用协议。