开头先废话几句，有段时间没有更新博客了，除了公司项目比较忙之外，还有个原因就是开始思考如何更好地写作。远的来说，我从大一便开始在 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 框架支持多种协议，由于协议处于框架层次的较高位置，任何一种协议的替换，都可能会导致服务发现和服务注册的方式，传输的方式，以及序列化的方式，而不同的协议也给不同的业务场景带来了更多的选择，下面就来看看一些常用协议。

这周六参加了一个美团点评的技术沙龙，其中一位老师在介绍他们自研的 RPC 框架时提到一点：RPC 请求分为 sync，future，callback，oneway，并且需要遵循一个原则：能够异步的地方就不要使用同步。正好最近在优化一个业务场景：在一次页面展示中，需要调用 5 个 RPC 接口，导致页面响应很慢。正好启发了我。

为什么慢？

大多数开源的 RPC 框架实现远程调用的方式都是同步的，假设 [接口 1，…，接口 5] 的每一次调用耗时为 200ms （其中接口 2 依赖接口 1，接口 5 依赖接口 3，接口 4），那么总耗时为 1s，这整个是一个串行的过程。

多线程加速

RPC 被称为“远程过程调用”，表明了一个方法调用会跨越网络，跨越进程，所以传输层是不可或缺的。一说到网络传输，一堆名词就蹦了出来：TCP、UDP、HTTP，同步 or 异步，阻塞 or 非阻塞，长连接 or 短连接…

本文介绍两种传输层的实现：使用 Socket 和使用 Netty。前者实现的是阻塞式的通信，是一个较为简单的传输层实现方式，借此可以了解传输层的工作原理及工作内容；后者是非阻塞式的，在一般的 RPC 场景下，性能会表现的很好，所以被很多开源 RPC 框架作为传输层的实现方式。

RpcRequest 和 RpcResponse

传输层传输的主要对象其实就是这两个类，它们封装了请求 id，方法名，方法参数，返回值，异常等 RPC 调用中需要的一系列信息。

1
2
3
4
5
6
7
8
9
10

public class RpcRequest implements Serializable {
    private String interfaceName;
    private String methodName;
    private String parametersDesc;
    private Object[] arguments;
    private Map<String, String> attachments;
    private int retries = 0;
    private long requestId;
    private byte rpcProtocolVersion;
}

提到 JAVA 中的动态代理，大多数人都不会对 JDK 动态代理感到陌生，Proxy，InvocationHandler 等类都是 J2SE 中的基础概念。动态代理发生在服务调用方 / 客户端，RPC 框架需要解决的一个问题是：像调用本地接口一样调用远程的接口。于是如何组装数据报文，经过网络传输发送至服务提供方，屏蔽远程接口调用的细节，便是动态代理需要做的工作了。RPC 框架中的代理层往往是单独的一层，以方便替换代理方式（如 motan 代理层位于 com.weibo.api.motan.proxy ，dubbo 代理层位于 com.alibaba.dubbo.common.bytecode ）。

实现动态代理的方案有下列几种：

• jdk 动态代理
• cglib 动态代理
• javassist 动态代理
• ASM 字节码
• javassist 字节码

上一篇 《深入理解 RPC 之序列化篇 –Kryo》, 介绍了序列化的基础概念，并且详细介绍了 Kryo 的一系列特性，在这一篇中，简略的介绍其他常用的序列化器，并对它们进行一些比较。序列化篇仅仅由 Kryo 篇和总结篇构成可能有点突兀，等待后续有时间会补充详细的探讨。

定义抽象接口

1
2
3
4
5
6

public interface Serialization {

   byte[] serialize(Object obj) throws IOException;

   <T> T deserialize(byte[] bytes, Class<T> clz) throws IOException;
}

RPC 框架中的序列化实现自然是种类多样，但它们必须遵循统一的规范，于是我们使用 Serialization 作为序列化的统一接口，无论何种方案都需要实现该接口。

上周六，周日在南京举办了 IAS 架构师峰会，这么多人的技术分享会还是头一次参加，大佬云集，涨了不少姿势。特此一篇记录下印象深刻的几场分享。由于全凭记忆叙述，故只能以流水账的形式还原出现场的收获。

大型支付交易平台的演进过程

陈斌，《架构即未来》译者，易宝支付 CTO。

交易系统具备以下特点，交易量大，并发度高，业务敏感度高，响应速度容忍度低… 从而使得支付交易平台需要有以下的特点：

• 高可用：7X24*365 随时可用
• 高安全：需满足 PCI-DSS 要求
• 高效率：每笔交易的成本要低
• 高扩展：随业务的快速发展扩张

从以上几点话题引申出了系统扩展的三个阶段

**X 轴扩展 – 扩展机器 **

也就是通俗意义中集群方案，横向扩展，通过添加多台机器负载均衡，从而扩展计算能力，这是最简单粗暴，也是最直接易用的方案。

**Y 轴扩展 – 拆分服务 **

当水平扩展遇到瓶颈后，可以进行服务的拆分，将系统按照业务模块进行拆分，从而可以选择性定制化地扩展特定的模块。如电商系统中拆分出订单模块，商品模块，会员模块，地址模块… 由于各个模块的职责不同，如订单模块在双 11 时压力很大，可以多部署一些订单模块，而其他压力不大的模块，则进行少量地部署。

**Z 轴扩展 – 拆分数据 **

服务拆分之后仍然无法解决与日俱增的数据量问题，于是引发了第三层扩展，数据的分片，我理解的 sharding，不仅仅存在于数据库，还包含了 redis，文件等。

另外陈斌老师还聊了一个有意思的话题，系统可用性下降的原因根源是什么？最终他给出的答案是：人。系统升级后引发的事故 80% 是由于人的误操作或者触发了 bug 等人为因素导致的，是人就会手抖。借此引出了单元测试，持续集成，持续交付的重要性。健全这三者是保障系统可用性的最大利器。

在技术晚宴，陈斌老师又分享了一些管理经验：** 如何打造一支优秀的技术团队 **。

分析了构成团队的四要素：

• 人员：健全职级体系，区别考评，挖掘潜能，及时鼓励，扁平化管理
• 组织：面向产出，利于创新，敏捷小团队
• 过程：聚集问题的根源，适当地使⽤用 ITIL，不断优化过程，自动化取代人工
• 文化：鼓励分享，打破 devops 的边界，鼓励创新，树⽴立正确的技术负债观

对于技术人员来说可能有点抽象，不过对于立志于要成为 CIO 的人肯定是大有裨益的，具体的理解可以参考《架构即未来》中的具体阐释。(ps：这里的架构并不是指技术架构，别问我为什么知道，问问我看了一半后在落灰的那本书，你什么都明白了)

一年前，笔者刚刚接触 RPC 框架，从单体式应用向分布式应用的变革无疑是让人兴奋的，同时也对 RPC 背后到底做了哪些工作产生了兴趣，但其底层的设计对新手而言并不是很友好，其涉及的一些常用技术点都有一定的门槛。如传输层常常使用的 netty，之前完全没听过，想要学习它，需要掌握前置知识点 nio；协议层，包括了很多自定义的协议，而每个 RPC 框架的实现都有差异；代理层的动态代理技术，如 jdk 动态代理，虽然实战经验不多，但至少还算会用，而 cglib 则又有一个盲区；序列化层倒还算是众多层次中相对简单的一环，但 RPC 为了追求可扩展性，性能等诸多因素，通常会支持多种序列化方式以供使用者插拔使用，一些常用的序列化方案 hessian，kryo，Protobuf 又得熟知…

这个系列打算就 RPC 框架涉及到的一些知识点进行探讨，本篇先从序列化层的一种选择 –kryo 开始进行介绍。

序列化概述

大白话介绍下 RPC 中序列化的概念，可以简单理解为对象 –> 字节的过程，同理，反序列化则是相反的过程。为什么需要序列化？因为网络传输只认字节。所以互信的过程依赖于序列化。有人会问，FastJson 转换成字符串算不算序列化？对象持久化到数据库算不算序列化？没必要较真，广义上理解即可。

JDK 序列化

笔者作为一个今年刚毕业的初级 JAVA，根据群里水友的讨论，也结合自己刚毕业时的一些面经，加上近期一点点在公司面试别人的经验，总结了如下的常见面试问题，适用于初级和中级 JAVA。

JAVA

1. HashMap 相关

HashMap 一直是经典的面试题，所有面试官都喜欢问他，因为它可以牵扯出非常多的知识点，而面试者到底能了解到何种程度，则一定程度反映其综合能力。

细节聊扩容因子 LoadFactor=0.75，初始大小 InitailCapacity=16