一. Java 的不足
如何构建一个分布式可扩展的Java服务器？首先我们要非常了解Java构建网络应用的优点及不足之处。
Java网络架构的基础是RMI远程调用。RMI是一种成熟稳定方便的应用，它的不足主要有

1) 没有安全隔离机制，一段代码的不稳定会造成整个node failure

2) 没有接管及远程监控机制，失败不能由另外一个程序或另外一个节点接管

3) RMI是C/S结构，通常是一对一, Client无法选择多个Server，无法切换Server，无法转移Server，如下一个典型的 Java RMI Spring配置

<bean id="timDemoService" class="org.springframework.remoting.rmi.RmiProxyFactoryBean">
          <property name="serviceUrl" value="rmi://server:1199/fooService"/>
          <property name="serviceInterface" value="com.foo.TimDemoService"/>
</bean>

上面的 timDemoService在JVM系统启动时候就加载，client/server就已经固定。

4) RMI是单向的，只能 client 调用 server, Server 调用 Client需要另外配置一套(即Server变成另外一个场景的client)，不能共享同一个连接。

二. 传统的 RPC 都是错误的
因此最近有一种观点就说RPC都是错误的，下文中提到的RPC都可以理解成包含Java RMI

"but for normal languages, RPC creates more problems than it solves."
    -- Steve Vinoski

来源：(原文 中文版)
其主要论点就是说RPC最大的问题就是把远程调用做得象本地调用。但是，远程调用并不是本地调用，它的异常和错误及其他很多方面是截然不同的。传统的RPC调用忽略了local与remote的区别，因此在大型项目里面混淆了这两者调用区别的应用通常会造成性能问题。

三. Erlang的优势
跟传统的 RPC 相对比，Erlang 的主要优点包括

1) 2个process互为关联(link)，一个crash,另外一个自动接管。

2) RPC就是message send/receive(严格的讲Erlang里面没有RPC), 可以很方便增加error handling, 而且 error handling 可以放在远程，这样更适合网络架构，因为local error handling在本机发生故障时候毫无意义。

3) message receive可以增加timeout，不会阻塞在某个地方

4) 其他场景，如Node X调用Node Y, Node Y执行业务之后把结果返回给Node Z, 传统RPC无法处理

四. Java中一些替代思路
1) RMI 也可以设置 timeout，因为底层无非都是基于Socket

2) RMI也可以实现无单点故障及负载均衡，参看 Clustered Remoting For Spring Framework Cluster4Spring 支持一对多调用，动态发现服务(dynamic services discovering)及远程错误监控, The Server Side 上有更多深入的讨论

3) 分布式内存共享 Coherence Data Grid, Openfire Cluster 就用了这个模块，不过这个框架不是开源的。

4) 分布式内存共享 Terracotta，这是一个开源的，Scala会采用这个

5) JGroups 可靠的组播服务，集群通讯首选的工具库，在其他语言无类似替代产品。JGroups介绍可参看前文 JGroups 简介、适用场合、配置、程序例子Demo等完全使用指南

6) Concurrent, Erlang中有轻量级的process, Java7中会有Doug Lea主导的fork/join

不过 Erlang里面还有Java中暂时无法替代的优势, 如Immutable变量, 无共享内存，Process交换数据通过消息传递实现等，这些特性在多核CPU下具有先天优势，相关资料也很多，就不这里重复了。

Building Scalable Web Sites一书大家基本上都是冲着Flickr和Cal Henderson首席架构师的名头去的，最近看到有中文版了就订了一本。书中全部代码用PHP为例，但其实跟PHP关系不大。书中实用的章节不多，先看了远程服务一章。

1. 使用远程服务的第一原则是不能依赖远程服务，另外一方面远程服务要考虑冗余性。
在我理解，远程服务有几类：
1) 远程API，如XML-RPC, HTTP接口, Message Queue。
这个是业务相关的，Failure怎样做要程序自身考虑了。
2) DB存储类，如MySQL, NFS。
MySQL可用主从或MySQL proxy, NFS不知道，不稳定，关键业务用的场合不多。
3) Cache, 如Memcached,
Memcache默认可以分布多个，Failure怎样处理？我觉得如果cache失效对系统影响比较大的话可以写2份,否则就立即启用备用cache。

书中还提到一个TCO的概念，在某个场合，靠人力去优化还是加硬件，哪个成本更低？

2. 异步系统。
异步系统也是我感兴趣的地方，任何一大型的系统，都会有不少异步的设计。
书中提到一种Ticket模型:

图片来源：(books.google.com)

Ticket异步模型除了书中介绍的用来转换图片服务的场景之外，我举一个我理解的例子。
用在IM里面比如在群中发送图片功能。
1) 发送方发送/粘贴图片，立即显示发送完毕
2) 群中所有接收方立即显示接收到图片(只是个Ticket)
3) 系统实际上处于发送方上传图片中
4) 同时群中用户拿ticket去要图片(轮询or通知)。
5) 发送方上传完毕
6) 接收方凭Ticket获取到图片最终资源显示。
这个场景理论上就是和Ticket模型相似，但在实际操作上群图片还有更多细节考虑。

3. 使用轻量级协议
HTTP和XML被过量使用，某些高访问场合未必是最好的选择。
这就是Flickr为什么要使用自己的存储服务和协议。
但这个问题是双面的，首先作者强调，“大多数场合，自行开发协议是糟糕的主意”。Flickr也尝试过NFS和scp。(这也是为什么gtalk选用XMPP)

另外翻译版源代码排版比较差，空行缩进行距等细节未注意，跟我们开发人员写的Word文档排版有得一比。

在上个月的 Web 2.0 Expo 的keynote, Yahoo CTO Ari Balogh提出了YOS, Yahoo Open Strategy，见下图，比较关注的有以下几个特性：

• OpenSocial REST API, 查询用户profile及connection数据。
• Presence API, 提供方法在全网络更新用户在线状态
• Updates API, 一个读写用户活动的通道。
• Social Messaging, 目前未公开资料
• 有意思的是以下架构图，目前还找不到清晰版的。

原文要点：

• 采用私有IM协议
• db(用户、好友等)：采用分区的方式
• Cluster: 前面有一个负责分配节点的服务器，用户的请求可以由任何一个逻辑服务器来处理。逻辑服务器之间网状结构。
• 用户所在节点find方法, 可能是询问所有网内节点，然后在本地cache
• Cache: 自定义的Local cache: UserInfoCacheModule，未使用分布式缓存
• 容量：目前支持40万并发，作者感觉可以支持到100万
• 开发语言：C/C++?
• 逻辑图

• 
• 部署图

• 

原文地址：一个即时通信系统架构实现的讨论

Digg上看到的招聘开发人员的要求，比较有意思。

• 你开发的程序每月有20,000,000+ 个独立用户(呵呵很多0)访问
• 主要是用LAMP,(Debian GNU/Linux, Apache, MySQL and PHP 还有一点Python)
• 可以学到一些PHP的核心设计思想，我们主要用php
• 主要用Memcache, Gearman, Mogile, PEAR这些技术，海量数据环境。(呵呵，大多是Memcached作者的项目)
• 工作在具有高访问量、分布式的环境，同时可创建和贡献开源项目
• 每年有20天有薪假期，福利若干 (medical, dental, vision, etc.).(流口水)

Digg.com招聘原文

来自一个职位趋势网站Indeed.com的数据分析了spring同ejb 05~07年的需求趋势
http://www.indeed.com/jobtrends

spring java 在2007/10职位数超过了 ejb java 职位数

ejb 的职位需求从05年开始没有增长

2007年，theserverside前5名文章(包括第一名)中有2篇是spring方面的
http://www.theserverside.com/news/thread.tss?thread_id=47967

spring推出了认证 SpringSource Spring Certification program.
http://blog.springsource.com/main/2008/01/17/the-springsource-certification-program/

starling 一个可靠消息传输模块(a light-weight persistent queue server)，支撑twitter的后台服务器
使用ruby开发的异步可靠消息服务器，虽然是消息服务器，但是速度飞快
基于memcache协议，可以使用任何客户端(java, c++, .net, php, ruby...)调用
下载地址：http://rubyforge.org/projects/starling/
或使用 sudo gem install starling 安装
更多信息：
http://dev.twitter.com/2008/01/announcing-starling.html

图为Twitter 总部：

又过了一个月……摘录一篇文章

正在做Andy Hunt和David Thomas的《程序员修炼之路》英文注释版（The Pragmatic Programmer）的最后审稿工作。

这本书虽然很早就读过一些，但现在再读，仍然暗暗称奇。作者一定是在长期工作中养成了记笔记的习惯，才能写出这样旁征博引、涵盖丰富的书来。

全书是按条目方式组织的，多入口，可以随意挑出一条感兴趣的，开始阅读，感觉非常适合你在dead moment（无所事事的时候）阅读。其中一条感触较深，名字叫“Your Knowledge Portfolio（知识资产）”。

这里的Portfolio原意是指投资组合，比如你有了一些钱，存一点在银行，买一点股票，买一点基金，买一点房产，买一点保险之类。总之是不要把all your eggs放在一个篮子里，减少风险，并且保值增值。

作者将这一含义移植到软件开发上来。显然，大家从事的软件开发是一个典型的高风险变化快的行业。如何使你所拥有的知识保值增值，的确是需要精心经营的。

作者提出的经营之道是：
——Invest Regularly，不断投资，积少成多。
——Diversity，扩大知识面，多元化，减少风险，增加潜力。
——Manage Risk，控制风险，这点与上呼应，要注意结合学习短线和长线技术。
——Buy low，sell hign，低买高卖，寻找潜力股。
——Review and rebalance，多总结。

这些对于现在全民买基金、炒股票的年代，当然都不需过多解释了。

作者提出的8大目标，可能更有实践意义：
——每年学习一种新语言。
不同语言能够以不同方式解决同样的问题。而学习各种不同的方法，能够扩宽思路，打破思维局限。学习不同的语言将改变和丰富你思考问题的方式。
而且，现在学习新语言比过去要简单得多了。编译器、开发环境、文档都可以自由从网上找到。

如 果你熟悉静态语言，不妨去尝试一下动态语言，Java程序员比较好的选择有Ruby、Groovy和JavaScript；Windows上开发的程序员 可以尝试一下微软的PowerShell；从事Web开发的，可以选择PHP、Ruby；从事游戏开发的，可以选择Lua。此外，Python也是一个值 得认真考虑的选择。当然，还有编程范型（paradigm）的切换，从过程到面向对象，从面向对象到函数式（很好的选择是代表了并发时代的 Erlang）、逻辑式（以Prolog为代表）。

——每个季度读一本技术图书。
养成习惯以后，每个月读一本。
同样，阅读兴趣也应该广一些，多元化。

——还要阅读非技术图书。
不要忘了软件是人在使用，多多了解人这方面的事情。

——参加技术课程。
可以是学校的，也可以是培训班或者技术会议上的。

——加入本地的程序员组织。
不仅是带着耳朵去听，而是要积极参与。“与世隔绝对职业生涯是致命的。” 去发现公司之外的朋友。

——实验不同的环境。
如果你工作中只使用Windows，那么在家里用用Unix/Linux。如果你只用makefile和编辑器，尝试一下IDE，或者反之。

——与时俱进，订阅行业杂志。

——上网，阅读有价值的文章、网站……
最后一条现在已经越来越重要，很大程度已经取代了上一条。现在国外主流的技术杂志，不少已经完全开放在网上，包括书中推荐的Dr. Dobb's Journal。

注释者还建议加上一条：
——多做笔记，建议采用Wiki或者blog的形式。

此外，作者还建议要利用各种机会学习，多与高手交流，利用各种时间。而且最重要的是，学习中，对所读所闻要批判地分析和思考。

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1778867

在digg上面看到一个有趣的故事。

7 reasons I switched back to PHP after 2 years on Rails

http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_switched_back_to_p_1.html

Saturday September 22, 2007 5:49PM
by Derek Sivers in Opinion

SUMMARY: I spent two years trying to make Rails do something it wasn’t meant to do, then realized my old abandoned language (PHP, in my case) would do just fine if approached with my new Rails-gained wisdom.

... ...

Ok. All that being said, I’m looking forward to using Rails some day when I start a brand new project from scratch, with Rails in mind from the beginning.