Arganzheng's Blog

stay hungry, stay foolish

JVM类加载器与ClassNotFoundException和NoClassDefFoundError

说明本文内容基本来着参考文章。在我们日常的项目开发中，会经常碰到ClassNotFoundException和NoClassDefFoundError这两种异常，对于经验足够的工程师而言，可能很轻松的就可以解决，但是却不一定明白为何要去这么做，本博客将从java虚拟机类加载的角度让大家彻底理解ClassNotFoundException和NoClassDefFoundError这两种异常及一些重用的解决方案。程序员定义的java类要被java虚拟机运行首先要做的就是类加载过程，而类加载过程的第一步就是“加载”过程（注意加载只是类加载的其中一个阶段而已，不要混淆这两个不同的概念）。在”加载“阶段，虚拟机需要完成以下三件事： 1.通过一个类的全限定名来获取此...

Posted by arganzheng | March 3, 2014

Java虚拟机学习笔记

Java内存区域程序计数器对于一个运行中的Java程序而言，其中的每一个线程都有它自己的PC寄存器，它是该线程启动时创建的。 PC寄存器大小是一个字长，既能够持有一个本地指针，也能够持有returnAddress。当线程执行某个Java方法时，PC寄存器总是指向下一条将被执行指令的“地址”。如果一个线程正在执行一个本地方法，那么此时PC寄存器的值是“undefined”。 Java虚拟机栈：线程私有每当启动一个新线程时，Java虚拟机都会为它分配一个Java栈。 Java栈是以帧为单位保存线程的运行状态。虚拟机只会直接对...

Posted by arganzheng | March 2, 2014

海量服务之——灰度发布

为什么要灰度发布互联网服务变动频繁，发布周期短。速度与质量总是难以双全。灰度发布能降低发布风险，减少影响范围。降低对测试的依赖，减少线下自测的数据构造成本。方便集中监控日志，全量发布由于各层负载均衡的作用，很难跟踪一条完整的调用链路。可以灰度测试帐号，测试账户通过之后再灰度真实用户帐号，进一步降低发布的风险和影响。方便回滚。不能靠灰度发布解决的问题需要强调的是：上文所说的“可以容忍的影响”必须是可恢复的，比如API无法调用一段时间，但是修复之后，就可以成功调用。而永久性地丢失或者破坏用户数据（比如商品信息、订单信息等），则是不能容忍的。因此，互联网企业的架构师有责任通过设计完善的后备措施（比如用户数...

Posted by arganzheng | February 26, 2014

HTTPS原理

HTTPS通讯流程客户端发出安全会话请求（会同时将自己支持的一套加密规则发送给服务器）服务器从中选出一组加密算法与HASH算法，并将自己的身份信息以证书的形式发回给客户端。证书里面包含了服务器地址，加密公钥，以及证书的颁发机构等信息。客户端获得服务器CA证书之后浏览器要做以下工作：用已知的CA列表来验证证书的合法性（颁发证书的机构是否合法，证书中包含的网站地址是否与正在访问的地址一致等），如果证书受信任，则浏览器栏里面会显示一个小锁头，否则会给出证书不受信的提示，让用户选择自担风险。如果证书受信任，或者是用户接受了不受信的证书，浏览器会生成一串随机对称密钥，并用证书中提供的公钥加密。使用约...

Posted by arganzheng | February 25, 2014

巧用TheadLocal

应用场景需要增加参数，但是不想或者不能修改接口。放置一些线程不安全，但是反复构建会比较耗内存或者CPU的对象，同步访问又会导致锁竞争。比如SimpleDateFormat。实现原理本质上就是一个以threadId为key的Map。实战例子——Spring Transaction Manager 事务管理可能会跨越好几个Service方法，如何在这些Service调用之间保存签名service的事务定义和数据库链接信息呢(需要这些信息决定事务的行为，比如determines if there is an existing transaction; )，特别是事务id？Spring就是通过ThreadLocal来实现的（@see Tra...

Posted by arganzheng | February 20, 2014

SLA和QoS在RPC/OpenAPI容器中的作用

其实OpenAPI和RPC本质上是一样的，只是由于OpenAPI是对外开放的，而RPC一般是内部服务调用。两者的考虑点不同，所以在通信协议和序列化方式上有些不同。作为一个RPC框架或者一个OpenAPI容器，它是连接服务消费者和服务器提供者的桥梁。他其实只是一个请求的转发而已。他的服务质量取决与服务提供者的服务质量。然而因为是一个容器，为了保证消费者的权利，同时也是为了保证其他服务提供者的稳定性和服务质量，必须指定服务规范，避免短板效应和害群之马。这就是为什么要引入SLA的原因。同时，由于服务之间有轻重之分，简单的大锅饭显然不利于资源的最大化利用以及对外提供最佳服务（性能与可靠性）。所以，服务提供者也可以通过QoS协议向容器声明自己的要求和权利，这就是QoS的作...

Posted by arganzheng | February 14, 2014

通讯协议序列化思考

由于我们现在的RPC框架原来的序列化方式太弱了，导致各种序列化问题。所以最近研究了一下相关的序列化方式。主要有：二进制类的，一般采用TLV编码方式，如Protocol Buffers, Thrift。文本类的，如JSON, XML。混合型的，比如Avro，schema是JSON，data是二进制方式的。序列化一般要么作为RPC传递，或者作为自描述的数据存储，比如数据库。不过后者由于需要存储多条，而且考虑到搜索和更新问题，所以对每条记录做了一定的组织，一般是B树组织结构。事实上，实现一个简单的通讯协议序列化是非常简单的（通信协议之序列化）。关键在于一些细节问题，需要好好思考： 1. 性能与带宽二进制协议最大的特点就是节省空间和带宽...

Posted by arganzheng | February 10, 2014

分布式系统常用思想和技术总结

一、分布式系统的难点分布式系统比起单机系统存在哪些难点呢？ 1. 网络因素由于服务和数据分布在不同的机器上，每次交互都需要跨机器运行，这带来如下几个问题： 1. 网络延迟：性能、超时同机房的网络IO还是比较块的，但是跨机房，尤其是跨IDC，网络IO就成为不可忽视的性能瓶颈了。并且，延迟不是带宽，带宽可以随便增加，千兆网卡换成万兆，只是成本的问题，但延迟是物理限制，基本不可能降低。这带来的问题就是系统整体性能的降低，会带来一系列的问题，比如资源的锁住，所以系统调用一般都要设置一个超时时间进行自我保护，但是过度的延迟就会带来系统的RPC调用超时，引发一个令人头疼的问题：分布式系统调用的三态结果：成功、失败、超时。不要小看这个第三态，这几乎是所有分布式...

Posted by arganzheng | February 10, 2014

Config Server和SLA在RPC中的作用

背景在分布式系统中，经常会遇到这样的业务场景：查找远程服务的地址查找资源地址（如mc，redis等）访问远程服务时，获取超时时间、Load balance策略、灰度策略、HA策略等配置当系统规模较小时，地址信息和配置信息可以保存在本地的文件系统中，以达到简单高效的目的。但是随着系统的壮大和服务器数量的增加，配置和地址信息的变更可能需要重启大量的服务器，这将会是十分“重量级”的操作。而这就是Config Service所要解决的问题。 Config Service Config Service是集配置服务和命名服务于一身的基础服务。它将地址信息和配置信息集中管理在云端，并且提供实时的变更通知。最常见的使用方是RPC服务。原则上来说，...

Posted by arganzheng | February 2, 2014

网络RPC编码协议学习

由于我们现在的RPC框架原来的序列化方式太弱了，导致各种序列化问题。所以最近研究了一下相关的序列化方式。主要有：二进制类的，一般采用TLV编码方式，如Protocol Buffers, Thrift。文本类的，如JSON, XML。混合型的，比如Avro，schema是JSON，data是二进制方式的。二进制编码主要是TLV编码及其变体。 TLV是Tag-Length-Value的简称，其实它原来的名称为Type-Length-Value。顾名思义，就是把每个字段按照Type-Length-Value的顺序依次进行编码。有这三个信息，接收端就能够正确的将这个字段进行解码。Protobuf/thrift/ASN BER都属于这种。 ...

Posted by arganzheng | January 13, 2014