本文根据唐福林老师在“高可用架构”微信群所做的《股市风暴下的雪球架构改造经验分享》整理而成，转发请注明来自微信公众号ArchNotes。
唐福林，雪球首席架构师，负责雪球业务快速增长应对及服务性能与稳定架构优化工作。毕业于北京师范大学，硕士学位。之前曾任微博平台资深架构师，微博技术委员会成员。长期关注并从事互联网服务后端性能及稳定性架构优化工作。
在命令行中使用Eclipse MAT工具
最近应用在测试中出现Out Of Memory的问题， 通过jmap查看，发现JVM heap全用满了。
有很多工具可以查看JVM堆的信息， 收费的比如JProfiler， YourKit，免费的如Oracle JDK自带的visualvm, jhat和Eclipse MAT。
这个应用安装在一台AWS上，没有图形界面， 内存也比较小，想通过VNC远程桌面启动visualvm或者MAT不可能，通过jhat分析dump出来的snapshot(大约4.3G)也很慢，半天没有分析完毕，这种办法也放弃。
最后通过MAT的命令行工具分析了dump出来的snapshot,查找到OOM的元凶。
G1垃圾回收器中的字符串去重(Java 8 Update 20)
从平均情况来看，应用程序中String对象会消耗大量的内存。这里面有一部分可能是重复(冗余)的－同样的字符串存在多个不同的实例(a!=b，但a.equals(b))。在实践中，许多字符串由于各种原因造成重复。
起初，JDK提供String.intern()方法处理字符串重复的问题。该方法的缺点是你需要找出哪些字符串需要驻留(interned)。这通常需要一个具备重复字符串查找功能的堆分析工具，比如YourKit profiler。尽管如此，如果使用恰当，字符串驻留会是一个强大的节省内存的工具－它允许你重用整个String对象（每个对象会在底层char[]的基础上增加24字节的额外开销）。
从Java 7 update 6开始，每个String对象都有自己私有的底层char[]。这样允许JVM做自动优化－如果底层的char[]数组从没有暴露给客户端，那么JVM就能去判断两个字符串的内容是否一致，进而将一个字符串底层的char[]替换成另一个字符串的底层char[]数组。
Java 8 update 20中引入的字符串去重特性就是用来做这个的，下面是它的工作原理：
一些 REST 最佳实践
原文： Some REST best practices, 作者：Pierre-Olivier Bourgeois。
译文： 一些REST最佳实践, 译者： yongx
如今，REST APIs 已经非常普遍，几乎所有WEB应用都用到了它们。提供简单，一致，实用的API是种义务，方便其它人很容易的使用。即使下面的这些规范，在你看来很正常，我经常看到人们不遵守它。这是我写这篇文章的原因。
当你设计 RESTful API 时，下面是一些应该牢记的最佳规范。
免责声明：下面的这些规范是根据过去的经验，我认为最好的。如果你有别的想法，咱们邮件讨论。
Scala编程的蛋糕模式和依赖注入
如果你是一个Java开发者，熟悉 依赖注入 模式, 深度依赖Spring框架的话，在使用Scala做开发时，会问一个问题，在Scala世界里，如何实现类似Spring框架的依赖注入呢？
尽管函数式编程的信徒认为他们不需要DI框架，高阶(high-order)函数足够了。但是对于同时支持面向对象的编程和函数式编程的Scala来说，依赖注入是很好的实现应用的一种设计模式。
蛋糕模式(Cake pattern)是Scala实现依赖注入的方式之一。
蛋糕模式是 Scala 之父 Martin Odersky 在其论文 Scalable Component Abstractions 中首先提到。
什么是蛋糕模式呢? 一个非正式的但是很形象的解释是：
- 蛋糕有很多风味， 你可以根据你的需要增加相应的风味。依赖注入就是增加调料。
- 蛋糕有很多层 (layer)。如果你想要一个更大的蛋糕你就可以增加更多的层。
我们先以Spring常用的User数据库读取的实现为例，看看Scala 风格的依赖注入(蛋糕模式)是如何实现的。
大型网站系统架构的演化
原文： 大型网站系统架构的演化, 作者：李平
一个成熟的大型网站（如淘宝、京东等）的系统架构并不是开始设计就具备完整的高性能、高可用、安全等特性，它总是随着用户量的增加，业务功能的扩展逐渐演变完善的，在这个过程中，开发模式、技术架构、设计思想也发生了很大的变化，就连技术人员也从几个人发展到一个部门甚至一条产品线。所以成熟的系统架构是随业务扩展而完善出来的，并不是一蹴而就；不同业务特征的系统，会有各自的侧重点，例如淘宝，要解决海量的商品信息的搜索、下单、支付，例如腾讯，要解决数亿的用户实时消息传输，百度它要处理海量的搜索请求，他们都有各自的业务特性，系统架构也有所不同。尽管如此我们也可以从这些不同的网站背景下，找出其中共用的技术，这些技术和手段可以广泛运行在大型网站系统的架构中，下面就通过介绍大型网站系统的演化过程，来认识这些技术和手段。
LinkedIn架构这十年
原文： A Brief History of Scaling LinkedIn
Josh Clemm是LinkedIn的高级工程经理，自2011年加入LinkedIn。他最近(2015/07/20)写了一篇文章，介绍了LinkedIn针对用户规模急速扩大带来的架构方面的变革。
文章有点像子柳写的淘宝技术这十年
2003年是LinkedIn元年，公司成立的目标是连接你的个人人脉以获得更好的的工作机会。上线第一周才有2700个会员注册，时光飞梭，LinkedIn的产品、会员数量、服务器负载都极大的增长了。
今天，LinkedIn全球用户已经超过3.5亿。我们每秒有数十万个页面被访问，移动端流量已占到50%以上 (mobile moment)。所有这些请求都从后台获取数据，而我们的后台系统可以处理每秒上百万次查询。
问题来了： 所有这些是怎么做到的呢？
使用cgroups限制MongoDB的内存使用
cgroups，其名称源自控制组群（control groups）的简写，是Linux内核的一个功能，用来限制，控制与分离一个进程组群的资源（如CPU、内存、磁盘输入输出等）。
这个项目最早是由Google的工程师在2006年发起（主要是Paul Menage和Rohit Seth），最早的名称为进程容器（process containers）。在2007年时，因为在Linux内核中，容器（container）这个名词有许多不同的意义，为避免混乱，被重命名为cgroup，并且被合并到2.6.24版的内核中去。自那以后，又添加了很多功能。
使用 cgroup，系统管理员可更具体地控制对系统资源的分配、优先顺序、拒绝、管理和监控。可更好地根据任务和用户分配硬件资源，提高总体效率。
在实践中，系统管理员一般会利用cgroup做下面这些事：
- 隔离一个进程组（比如：nginx的所有进程），并限制他们所消费的资源，比如绑定CPU的核。
- 为这组进程 分配其足够使用的内存
- 为这组进程分配相应的网络带宽和磁盘存储限制
- 限制访问某些设备（通过设置设备的白名单）
基于dubbo框架下的RPC通讯协议性能测试
原文: 基于dubbo框架下的RPC通讯协议性能测试,作者: lengfo
Dubbo RPC服务框架支持丰富的传输协议、序列化方式等通讯相关的配置和扩展。dubbo执行一次RPC请求的过程大致如下：消费者（Consumer）向注册中心（Registry）执行RPC请求，注册中心分配服务URL并路由到具体服务提供方（Provider），消费者和服务提供方建立网络连接，服务提供方在本地创建连接池对象并提供远程服务，对于长连接类型协议（如dubbo协议）将保持连接，减少握手认证，调用过程中可以避免频繁建立和断开连接导致的性能开销，保持长连接需要有心跳包的发送，所以对于非频繁调用的服务保持连接同样会有消耗。更多关于dubbo详细介绍请参照官方文档（http://alibaba.github.io/dubbo-doc-static/Home-zh.htm）。
1、支持常见的传输协议：RMI、Dubbo、Hessain、WebService、Http等，其中Dubbo和RMI协议基于TCP实现，Hessian和WebService基于HTTP实现。
2、传输框架：Netty、Mina、以及基于servlet等方式。
3、序列化方式：Hessian2、dubbo、JSON（fastjson 实现）、JAVA、SOAP 等。
本文主要基于dubbo框架下的通讯协议进行性能测试对比。
