原文链接  作者：Pankaj Kumar 译者：f0tlo <1357654289@qq.com>

（最近我会写一些我对架构的理解和思考，本篇是第一篇，欢迎交流）

什么是系统架构？

从字面上理解，系统架构是系统的框架结构，是系统进行抽象之后的一个草图。它包含了系统中各个抽象组件的协作方式。

阅读全文

原文链接 作者：Pankaj Kumar 译者：f0tlo <1357654289@qq.com>

原文链接   译者:mailto:ahahage@163.com

• 目录
• 线程体系结构
• 反应堆模式
• 组件架构
• 接收器
• 分配器
• 分配器级别事件处理器
• 应用程序级别事件处理器
• 总结
• 参考资料

阅读全文

感谢同事【向西】投递本稿

云OS 3.0已发布，总算向外界表达了我们想做个啥，很多人也开始质疑，Cloud Card到底是个啥？云OS 3.0算不算自主研发的OS？等等，今天想就Cloud Card能否干掉App这个主题聊聊这些事情。

阅读全文

原文链接 译者：秦建平

装饰者模式可以给已经存在的对象动态的添加能力。下面，我将会用一个简单的例子来演示一下如何在程序当中使用装饰者模式。

1.装饰者模式
让我们来假设一下，你正在寻找一个女朋友。有很多来自不同国家的女孩，比如：美国，中国，日本，法国等等，他们每个人都有不一样的个性和兴趣爱好，如果需要在程序当中模拟这么一种情况的话，假设每一个女孩就是一个Java类的话，那么就会有成千上万的类，这样子就会造成类的膨胀，而且这样的设计的可扩展性会比较差。因为如果我们需要一个新的女孩，就需要创建一个新的Java类，这实际上也违背了在程序开发当中需要遵循的OCP（对扩展开放，对修改关闭）原则。
让我们来重新做另外一种设计，让每一种个性或者兴趣爱好成为一种装饰从而可以动态地添加到每一个女孩的身上。

阅读全文

tomcat在处理每个连接时，Acceptor角色负责将socket上下文封装为一个任务SocketProcessor然后提交给线程池处理。在BIO和APR模式下，每次有新请求时，会创建一个新的SocketProcessor实例(在之前的tomcat对keep-alive的实现逻辑里也介绍过可以简单的通过SocketProcessor与SocketWrapper实例数对比socket的复用情况)；而在NIO里，为了追求性能，对SocketProcessor也做了cache，用完后将对象状态清空然后放入cache，下次有新的请求过来先从cache里获取对象，获取不到再创建一个新的。

这个cache是一个ConcurrentLinkedQueue，默认最多可缓存500个对象(见SocketProperties)。可以通过socket.processorCache来设置这个缓存的大小，注意这个参数是NIO特有的。

接下来在SocketProcessor执行过程中，真正的业务逻辑是通过一个org.apache.coyote.Processor的接口来封装的，默认这个Processor的实现是org.apache.coyote.http11.Http11Processor。我们看一下SocketProcessor.process(...)方法的大致逻辑：

阅读全文

1) 最大连接数

tomcat的最大连接数参数是maxConnections，这个值表示最多可以有多少个socket连接到tomcat上。BIO模式下默认最大连接数是它的最大线程数(缺省是200)，NIO模式下默认是10000，APR模式则是8192(windows上则是低于或等于maxConnections的1024的倍数)。如果设置为-1则表示不限制。

在tomcat里通过一个计数器来控制最大连接，比如在Endpoint的Acceptor里大致逻辑如下：

阅读全文

对于acceptCount这个参数，含义跟字面意思并不是特别一致（个人感觉），容易跟maxConnections,maxThreads等参数混淆；实际上这个参数在tomcat里会被映射成backlog:

static {
    replacements.put("acceptCount", "backlog");
    replacements.put("connectionLinger", "soLinger");
    replacements.put("connectionTimeout", "soTimeout");
    replacements.put("rootFile", "rootfile");
}

backlog表示积压待处理的事物，是socket的参数，在bind的时候传入的，比如在Endpoint里的bind方法里：

阅读全文

作者：罗立树

最近在负责公司内部私有云的建设，一直在思考怎么搞云计算，怎么才能够把云架构设计得好一些。

本文章主要内容：

1. 行业生态

2. 从需求角度看云

3. 云计算概述

4. 云建设的关键问题

5. 私有云架构规划
阅读全文

原文链接  译者：张军 校对：方腾飞

本文将并发和内存管理做了个类比。最近有一个说法是因为现代工程师几乎总是面对计算机集群编程，所以我们需要用于构建分布式系统的工具。这就意味着我们需要在语言层面支持分布式系统开发。像GO和Erlang这样的语言其优势正好符合这个观点。

GO和Erlang可能最终会流行，但我不认为是这个原因。分布式系统开发并不会成为每个应用开发者日常工作的一部分，因为那将会是件非常痛苦的事情。在某种程度上，我想今天发生的事情是因为缺乏良好的分布式计算框架，而迫使应用去重新实现一些分布式系统原语。但这种情况不会一直存在，而必将有一些框架提供不同的编程模型，在弹性机器池上处理分布和并发问题。

MapReduce已经解决了这个问题。MapReduce编程几乎都是单线程的，并发是由框架来管理，另外有助于你写好MapReduce程序的原因是，有很多用户级别(user-level)的并发原语，并且MapReduce是高度并行的。 阅读全文

感谢同事【沐剑】的投稿

在大规模互联网应用中，负载均衡设备是必不可少的一个节点，源于互联网应用的高并发和大流量的冲击压力，我们通常会在服务端部署多个无状态的应用服务器和若干有状态的存储服务器（数据库、缓存等等）。

一、负载均衡的作用

负载均衡设备的任务就是作为应用服务器流量的入口，首先挑选最合适的一台服务器，然后将客户端的请求转发给这台服务器处理，实现客户端到真实服务端的透明转发。最近几年很火的「云计算」以及分布式架构，本质上也是将后端服务器作为计算资源、存储资源，由某台管理服务器封装成一个服务对外提供，客户端不需要关心真正提供服务的是哪台机器，在它看来，就好像它面对的是一台拥有近乎无限能力的服务器，而本质上，真正提供服务的，是后端的集群。

一个典型的互联网应用的拓扑结构是这样的：

阅读全文