Dubbo 是阿里巴巴公司开源的一个Java高性能优秀的服务框架，使得应用可通过高性能的 RPC 实现服务的输出和输入功能，可以和 Spring框架无缝集成。不过，略有遗憾的是，据说在淘宝内部，dubbo由于跟淘宝另一个类似的框架HSF（非开源）有竞争关系，导致dubbo团队已经解散（参见http://www.oschina.net/news/55059/druid-1-0-9 中的评论），反到是当当网的扩展版本仍在持续发展，墙内开花墙外香。其它的一些知名电商如当当、京东、国美维护了自己的分支或者在dubbo的基础开发，但是官方的库缺乏维护，相关的依赖类比如Spring，Netty还是很老的版本(Spring 3.2.16.RELEASE, netty 3.2.5.Final),倒是有些网友写了升级Spring和Netty的插件。

Motan是新浪微博开源的一个Java 框架。它诞生的比较晚，起于2013年，2016年5月开源。Motan 在微博平台中已经广泛应用，每天为数百个服务完成近千亿次的调用。

rpcx是Go语言生态圈的Dubbo， 比Dubbo更轻量，实现了Dubbo的许多特性，借助于Go语言优秀的并发特性和简洁语法，可以使用较少的代码实现分布式的RPC服务。

gRPC是Google开发的高性能、通用的开源RPC框架，其由Google主要面向移动应用开发并基于HTTP/2协议标准而设计，基于ProtoBuf(Protocol Buffers)序列化协议开发，且支持众多开发语言。本身它不是分布式的，所以要实现上面的框架的功能需要进一步的开发。

thrift是Apache的一个跨语言的高性能的服务框架，也得到了广泛的应用。

后续还会增加更多的 RPC 框架的比较，敬请收藏本文网址

阅读全文

阿姆达尔定律（英语：Amdahl's law，Amdahl's argument），一个计算机科学界的经验法则，因吉恩·阿姆达尔(Gene Amdahl)而得名。它代表了处理器平行运算之后效率提升的能力。

1967年计算机体系结构专家吉恩.阿姆达尔提出过一个定律阿姆达尔定律，说：在并行计算中用多处理器的应用加速受限于程序所需的串行时间百分比。譬如说，你的程序50%是串行的，其他一半可以并行，那么，最大的加速比就是2。不管你用多少处理器并行，这个加速比不可能提高。在这种情况下，改进串行算法可能比多核处理器并行更有效。

阅读全文

以前我发布过 techempower的 第11轮的测试、第9轮的测试，现在第12轮的测试出来了，结果肯定又会出人意料。

techempower的测试有好几个case，我们以每个request包含12个数据库的插入操作为例，看看各个web框架的性能，以TPS为指标排序(每秒返回的response多的在前面，性能越好)

go fasthttp + postgresql居然排到了第一，啧啧,以前前几名都是C/C++的框架排第一,这次C++ web框架wt排在了第二。

nodejs + Mysql表现不俗，排在了第6位。

undertow edge + Postgres排在了第8位

依然没有netty的测试，我期待Netty的表现，应该比undertow要高吧。

Go原生web框架的表现不好，排名很低。

Java生态圈的框架如Spring、dropwizard等表现的不温不火。

瑞士的金融软件工程师和创业者Alexander Temerev在github上创建了一个项目skynet ,用来测试各语言(框架)的多线程并行计算的性能，并得到了一些有用的数据。本文翻译整理自这个项目的说明。

测试并行性能的代码逻辑很简单：创建一个actor(goroutine,或者其它语言中类似的并发库)，它会创建10个子actor,然后每个子actor再创建10个子actor，一直这样创建下去，直到创建了1百万个actor，每个actor包含一个唯一的数字(0到999999)。然后最底层的actor把它们的数字返回给父actor，父actor计算总和后再把结果返回给它的父actor，一直返回直到根actor，这样根actor的包含数字就是0到999999的和，结果应该为499999500000。

所以测试代码的逻辑就是并行计算0到999999的和，测试各种语言的并行库性能。

当然标题是不准确的，只是借用了这个项目的名称，1百万的线程不太可能在一台机器上创建，Alexander Temerev比较的是一些语言的并发框架的实现，聪明的读者应该明白项目性能测试的是什么东西，
它包括了Scala Actor、Scala-Future、Go、erlang、haskell、C# Core、C# TPL、RxJava、node-bluebird、python、rust等语言/框架的测试代码。所以大家不必吐槽标题中的"线程"，其实比较的是异步编程模型的性能。

阅读全文

我在以前的文章曾经转发过 Techempower第9轮的Web框架的性能测试, 11月23号Techempower发布了最新的第11轮的测试: Framework Benchmarks Round 11。
不过此文章国内无法访问，可能需要翻墙。我将测试结果以图片的方式贴在这里，让我们看看Web框架们又有了什么样的性能提升。

阅读全文

永源科技做的一个RPC框架的性能测试。
原文： RPC框架性能基本比较测试

gRPC是Google最近公布的开源软件，基于最新的HTTP2.0协议，并支持常见的编程语言。 我们知道HTTP2.0是基于二进制的HTTP协议升级版本，目前各大浏览器都在快马加鞭的加以支持。 我们可以设想一下，未来浏览器支持HTTP2.0，并通过现有开源序列化库比如protobuf等，可以直接和各种语言的服务进行高效交互，这将是多么“美好”的场景！

gPRC的Java实现底层网络库是Netty，而且是用到最新的Netty5.0.0.Alpha3的开发版本，因为最新版本针对HTTP/2做了很多改进。 为了跨语言，gPRC也和其他方案一样，采用了类似古老IDL的接口描述语言，利用自家的Protobuf项目带的protoc编译器来生成框架代码。这和目前最流行的Facebook开源的，现为Apache顶级项目的Thrift原理一致。

我比较好奇，这个新出世的框架的性能怎么样，和现有的RPC开源方案比较如何。就花了一些时间进行简单比较。 我选择了以下五种开源项目进行测试：gRPC, Thrift, Wildfly, Dubbo, JBoss EAP。 为了简化，测试范例都使用项目自带的demo或者sample等进行简单修改，使得跨进程网络调用次数一致。

阅读全文

英文原文：Qihoo 360 and Go
翻译 by 开源中国： 奇虎360 和 go

在中国，奇虎 360 是一个互联网和手机安全产品及服务的主要供应商，截止到 2014 年 6 月，奇虎拥有 5 亿的 PC 活跃用户以及超过 6.4 亿移动用户。奇虎还运营着中国最受欢迎的网络浏览器和 PC 搜索引擎(原文如此)。

我的团队，推送服务团队(Push Service Team)，为超过 50 个公司的产品提供服务（PC 和移动），包括成千上万放在我们的开放平台的应用程序。

我们对Go的青睐要从2012年第一次尝试为奇虎的一个产品提供推送功能开始。最初的nginx + lua + redis方案因为负载过大没能满足我们对实时性能的需求。在这种情况下，最新发布的1.0.3版Go引起了我们的注意，借助它提供的goroutine和channel特性，我们在几周之内开发完成了一个原型。我们的系统最初运行在20台服务器上，能够处理2000万实时连接，每天发送200万信息。现在这套系统在超过400台服务器运行，支持2亿实时连接，每天发送超过100亿条信息。

阅读全文

前一篇文章使用四种框架分别实现百万websocket常连接的服务器介绍了四种websocket框架的测试方法和基本数据。 最近我又使用几个框架实现了websocket push服务器的原型，并专门对这七种实现做了测试。 本文记录了测试结果和一些对结果的分析。
这七种框架是：

• Netty
• Undertow
• Jetty
• Vert.x
• Grizzly
• spray-websocket
• nodejs-websocket/Node.js

最近用Golang实现了第八种，Go表现还不错。

• Go

  阅读全文

事实上，最近我又增加了几个框架，现在包括 Netty, Undertow, Jetty, Spray, Vert.x, Grizzly 和 Node.js七种框架。
测试数据可以看下一篇文章: 七种WebSocket框架的性能比较

著名的 C10K 问题提出的时候, 正是 2001 年。这篇文章可以说是高性能服务器开发的一个标志性文档，它讨论的就是单机为1万个连接提供服务这个问题，当时因为硬件和软件的限制，单机1万还是一个非常值得挑战的目标。但是时光荏苒，随着硬件和软件的飞速发展，单机1万的目标已经变成了最简单不过的事情。现在用任何一种主流语言都能提供单机1万的并发处理的能力。所以现在目标早已提高了100倍，变成C1000k，也就是一台服务器为100万连接提供服务。在2010年,2011年已经看到一些实现C1000K的文章了，所以在2015年，实现C1000K应该不是一件困难的事情。

本文是我在实践过程中的记录，我的目标是使用spran-websocket，netty, undertow和node.js四种框架分别实现C1000K的服务器，看看这几个框架实现的难以程度，性能如何。开发语言为Scala和Javascript。

当然，谈起性能，我们还必须谈到每秒每个连接有多少个请求，也就是RPS数，还要考虑每条消息的大小。
一般来说，我们会选取一个百分比，比如每秒20%的连接会收发消息。我的需求是服务器只是push,客户端不会主动发送消息。 一般每一分钟会为这一百万群发一条消息。
所以实现的测试工具每个client建立60000个websocket连接，一共二十个client。实际不可能使用20台机器，我使用了两台AWS C3.2xlarge(8核16G)服务器作为客户端机。每台机器10个客户端。
服务器每1分钟群发一条消息。消息内容很简单，只是服务器的当天时间。

最近看到360用Go实现的消息推送系统，下面是他们的数据：

目前360消息推送系统服务于50+内部产品，万款开发平台App，实时长连接数亿量级，日独数十亿量级，1分钟内可以实现亿量级广播，日下发峰值百亿量级，400台物理机，3000多个实例分布在9个独立集群中，每个集群跨国内外近10个IDC。

四个服务器的代码和Client测试工具代码可以在github上下载。 (其实不止四种框架了，现在包括Netty, Undertow, Jetty, Spray-websocket, Vert.x, Grizzly 和 Node.js 七种框架的实现)

测试下来可以看到每种服务器都能轻松达到同时120万的websocket活动连接，只是资源占用和事务处理时间有差别。120万只是保守数据，在这么多连接情况下服务器依然很轻松，下一步我会进行C2000K的测试。

阅读全文

来源于QCon某高可用架构群整理，整理 by 朱玉华。
背景：有某个朋友在朋友圈咨询微信红包的架构，于是乎有了下面的文字（有误请提出，谢谢）
概况：2014年微信红包使用数据库硬抗整个流量，2015年使用cache抗流量。

阅读全文