2010年12月17日星期五

JavaOne 2010 北京 Session的评价

在基于Java技术的Web服务中处理异步 
    这个session,概括的说,讲了三个方面的东西
  1. 可以方便的在客户端进行一个异步调用的模拟,实际上是有一个后台线程,仍然进行阻塞的访问。
  2. 采用WS-Addressing来进行异步调用,实质是A调用了B,这个时候,B处理完了,结果给谁,是要配置的。可能是返回给A,但是是一个新的调用,也可以给到其他地方去。这个其实是对Request和Response的分解。而这里有一个问题是,如果B处理完了以后,结果主动给A,有防火墙的问题。so,第三种
  3. 叫做是WS-makeConnection,其实是对2的一种修改,A调用了B以后,会进行轮询。解决防火墙的问题。
    另外,提到了JavaEE 6的一些新的特点,完全基于Annotation等。
    总体来说,是长见识了,但是还用不上。

我的应用程序怎么了:Java虚拟机监控工具 
    这个就是工具介绍,介绍了Palantir的功能,并且提到这个是基于Dtrace做的。并且,目前不确定什么时候Palantir能够Ready给公众。
    也没有别的更多的东西了。
    不过,这个session可能给我的一个感受是,工具是非常非常的关键和重要的,不管是集群的管理,还是单机的监控等。下面的Action是跟进我们自己的工具的开发。

实现从云端到终端的均衡发展 
   这个主要是是讲Intel的产品的。CPU的高性能、低功耗、虚拟化技术等。

分步说明:HotSpot Java虚拟机中的GC调优 
    这个Session,跟美国JavaOne的貌似一样的,PPT我看起来就非常的眼熟。
    主要是之前看过这个PPT了,内容大概都知道。而Speaker好像也没有很大的激情,整体比较平铺直叙
    主要就是讲了Throughput、Latencies和FootPrint以及一些调优的基本做法。内容还是很不错的。

数据库复制 
    这个Session是我抱着很大希望去的,结果真的是希望越大失望越大。
    基本是将用Oracle的产品怎么做到容灾的。我承认,我睡着了。
    最后是讲到GoldenGate,这个我在iDataForum上第一次听说,据说很强大,然后很贵。     

技术概述:Sun Fire x86集群系统 
    这个Session,我天真的以为会将技术,其实就是完全介绍产品,不过这产品看的让人流口水。
    8路8核超线程,128条8G内存。。。。。。
    然后是介绍了Oracle的一套系统的Stack。App,DB,Virtualization,OS,Server,Storage啥都有。。。强的

JavaOne技术主题演讲 
    这个应该是和JavaOne美国的那个差不多的,从JavaSE的发展到JavaEE的发展到JavaME的 发展。
   这里面也明确提到,Java7会在2011年7月28日Ready,好吧,在等上7个多月看吧。
   另外,JavaEE7里面,JMS的API会升级到2.0,不知道有什么新东西,到时候看。
   JavaSE8,要到2012年底,希望玛雅的语言不准的,否则也许用不上Java8了。
   JavaME里面提到,ME会朝着水平和垂直的方向发展,水平是提供给开发者统一一致的API,垂直是指针对不同的设备,比如智能电视、或者别的智能设备,有不同的API

如何在Java虚拟机上调优和编写低延迟应用程序 
    这个Session,包含的东西还是比较多的,也比较碎,还是看PPT比较好。是很好的主题

面向轻量级服务器的Java方法 
    这个Session,应该说讲了4件事情
  1.  BIO是阻塞的通信方式,连接数跟线程数是1:1,这种方式有他应用的场景。
  2.  NIO是非阻塞的方式,采用reactor模式,不需要一个线程处理一个连接。
  3.  NIO2是通知的方式(貌似Winsocket是早就有这种方式了),比NIO会更高效,跟容易使用。
  4.  SSLEngine
   我对这个Session,总体评价不高

在JDK中使用文件系统API 
   这个主要介绍了新的File API。比如对目录的遍历、比如文件变化通知等。
   并且给了一个性能比较,新的API提升了很多。那我想,这个提升也不是基于OS的变化的提升,那么。。。。。。,就是说,之前的实现很不好了。

多种语言,一个虚拟机 
    这个Session,比较好玩儿,演示了使用jrunscript(1.6中默认就带的)。
    在jrunscript的交互的shell里面,来创建Swing窗口,控制Swing窗口等。
    讲到了JavaSE7的invokeDynamic。讲到了如何在Java中使用脚本的引擎等。
    长见识了。

开发和使用面向互联网服务的企业服务总线的经验 
    这个Session,觉得内容比较少,主要是在讲一件事情,就是ESB在互联网环境下,作为Caller和Callee中的ServiceGate,完成的工作。 但是没有讲到具体的一些细节、经验教训等。 最后的图,是在传统的方式上,加入了Cloud Connector。
    
JDK 7和Java SE 7 
    讲了四个方面
  1. Modularity(Project Jigsaw)
  2. Small Language Changes(Project coin)
  3. Closures(Project Lambda)
  4. Dynamic Method Calls(invokeDynamic)
使用Java Servlet 3.0和Java EE 6的安全、异步的Web应用程序 
    这个Session主要是讲Servlet 3.0中,应该怎么使用异步。 以及在Server端,Servlet的安全性控制。

Java移动支付中间件支持支付宝安全支付服务 
    这个很强,好像和其他的Session都不冲突,爆满。
    支付宝也很强,要和Oracle一起去搞JSR 229,这个是很早之前西门子提出的支付API。如果支付宝能够把JSR 229真的继续搞下去,那真牛啊。
Oracle的ME的VM,就内置支付宝的支付中间件了,支付宝也在跟其他的VM厂商谈。太牛了。
    纯技术的内容,好像没什么

Sun SPOT项目:支持Java的普适计算平台 
     这个本来以为是跟云计算有关系的东西,去了才知道是介绍SPOT的,SPOT就是Small Programmable Object Technology 是一个有温度、光线、3D位置感应的可编程的一个设备。 这个东东比较好玩儿,并且貌似不好买到。 Sun的技术上的想法和动作,其实都还是很强的,可惜。。。

    总体来说,特别好的Session很少很少,介绍性质的居多,也有很水的。相对于之前12号的iDataForum,虽然方向不同,但是还是iDataForum更加实战些。
    明年应该不会参加国内的Javaone了。我想如果是Sun自己办,应该会好很多。不过。。。,明年如果有机会,还是希望参加些比较实战的,能够有技术上交流的会议,比如QCon等。
     最后额外的收获,作为Speaker,参加了Oracle的答谢活动,吃了顿不错的自助餐,然后Oracle送了一块儿手表,看起来好像还不错的样子,据一个在Oracle中国待了十多年的朋友说,他从来没见过Oracle送这么好的礼物。呵呵。

JavaOne 2010 北京 我的Session选择


北京参加 iDataForum总结

      感谢淘宝DBA的邀请,参加了12月12号在北京的iDataForum的技术论坛,并且也分享了一个主题《淘宝网的前世今生》。
      虽然这个论坛,只有一天的时间,但是应该说还是效果很好的。相关的PPT都可以从http://www.idata-forum.org/下载。
      这次,主要听了三个主题。
      一个是赵林(新浪微博 @丹臣)的《淘宝数据库架构演进历程》,一个是邵宗文的《数据库托管平台介绍》,一个是孙立的《NOSQL研发之路》。
      赵林分享的内容相当丰富,用时间顺序串起来了淘宝数据库的变化。内容相当的丰富。没有去现场的同学,一定要去看一下这个PPT。
      邵宗文的分享,我是一直站着听完的。他介绍的数据库托管平台,给了我不少启发:
       一个是对托管平台的数据库的管理、信息统计、监控这个部分,我们这边的管理工具还不够强;
       另外一个是单机多实例,这个对应的是单物理机多虚拟机的做法,这块儿,跟我们的DBA讨论了,貌似还是倾向于多虚拟机的方式,不过这块儿,也要跟进下,在Java应用上,也有类似的选择;
       然后是对于复制延时的探测和下掉延时大的slave。这个部分,我之前不知道Mysql是可以方便的知道复制延时有多大的,这个我土了。另外,腾讯的方案是通过DNS来管理slave的,通过从DNS上摘除地址,下掉慢的读库的。
      下面的Action就是,管理工具这个部分的加强,下周约DBA碰一下。希望能够在明面Q1结束的时候,我们能够搞好一个好用强大的数据库管理平台。
      孙立(新浪微博 @sunli1223_孙立)的NoSQL开发之路,我没有完全听下来,当时刚好有同学找我交流,总体来说,他是遇到了TTServer的问题后,有点不得不去开发一个NoSQL的,貌似是数据量在五六十G的时候TT出问题的。然后他这边基于BDB的自己的存储,性能测试曲线相当的平稳和稳定。具体大家可以看看他的PPT。存储这块儿,我这边现在不涉及,没有Action。只是丰富见识了。
      最后,我自己的分享,我感觉应该还是把目前我们做的数据层,跟大家讲清楚了。如果有问题,欢迎大家一起交流。感谢iDataForum,希望今后越办越好。
    
    
    

2010年10月25日星期一

Mysql作为Key/Value Storage的优化

今天早上看到了一篇文章《Using MySQL as a NoSQL - A story for exceeding 750,000 qps on a commodity server》。主要讲述的是把Mysql作为一个KVS和Memcache的一个对比。看到了一个新的思路。
     开始的结果大概是Mysql的性能是Memcache的1/4,QPS是10w:42的样子。使用Mysql主要的消耗在解析SQL以及一些内部的同步处理。
    然后提到了NDBAPI,这个能够大幅提高性能,但是需要用在NDB上--不过很多公司是不用NDB的。
    最后提到了一个解决方案,是在Mysql Server上部署一个插件一样的东东,监听另外一个端口,走另外的协议。而这个插件内部,是直接不走MysqlServer的SQL解析等等过程的,直接走Storage Engine的API,也就是innodb的API。性能得到非常大的提升。
    通过这个改造,QPS从10w达到了70w,已经超过memcache将近3/4。
    文章具体地址是http://yoshinorimatsunobu.blogspot.com/2010/10/using-mysql-as-nosql-story-for.html,已经实现的代码,在文章中有下载链接。

2010年9月28日星期二

Tunnelier貌似比较好用

使用同事的VPS去自由世界,之前用的是MyEnTunnel,用了几个月都还不错,最近发现总是连不上,我开始以为是VPS的问题。但是同事说他自己用是好的。后来使用Tunnelier,发现问题就解决了,之前用MyEnTunnel的时候,plink总是报告连接超时,现在Happy了,又可以到墙外了。

2010年8月2日星期一

新的挑战

开始在公司,带领一个做Java基础产品或者说中间件的团队,另外也有一个团队也是做Java基础方面的东西。现在两个Team合并了,我来带整个团队,那边的Leader专心做技术架构师了,这个也是他一直很喜欢的。
     下面是开始一个新的阶段了。不过技术还是不会丢的,只是自己没很多时间去钻研了,就是跟进型的策略吧。跟每个产品线的同学多沟通,学习学习新的东西,也多跟架构师以及团队内的一些技术专家多学习学习。总之,技术还是需要持续提高。
     希望整合后,两个Team都能互相取长补短,也要把质量、创新、进度方面给抓好。不过还有很重要的任务是,要帮助团队成长。

     P.S. 团队一直在招人,需要的就是对技术痴迷的,工作地点在杭州。

2010年7月26日星期一

Nginx的Module中使用X-Accel-Redirect的问题

再前面的一篇blog中,提到了在做一个持久配置中心。当时为了提升效率,在同事用tomcat实现的同时,我在尝试直接用nginx来完成。想通过完成一个nginx的模块,进行逻辑处理,然后把需要的数据返回回去。
    在tomcat中,是重定向请求到一个具体的文件。而我在nginx中,也是这么干的。
    在nginx的module中,我想通过 X-Accel-Redirect 这么一个header来完成,但是死活都不行,而给出的例子,都是在nginx后端所连接的系统中设置这个header,就可以起作用。比如后面挂一个tomcat,或者搞一个fastcgi去连php,都行的。按照我的理解,我觉得在nginx的模块中,直接设置这个header也应该工作的,不过事实告诉我,确实不行,这个得去问问公司这方面的专家,看看为啥是不能工作的。找个解释。

      晚上邮件咨询了下同事,同事告诉我:“这个feature是给后端服务器用的(在Nginx里面,后端服务器称为upstream,比如FastCGI、Proxy、memcached等)。在Nginx模块里是不能用这个的,可以使用internal redirect机制,就是调用ngx_http_internal_redirect”。我这下知道怎么回事儿了,不过暂时这个模块的尝试hold了,今后如果继续,就能够用这个方式了。

框架对性能的影响

  首先声明,这里提到框架对性能的影响,只是针对非常特定的场景。
    这篇博客还是源于之前的一个项目--持久配置中心。当时在压测的时候,我对并发去读配置的性能不是很满意。 
    看了代码,发现在Get的时候,还是处理了一些逻辑,之前一直以为是一个synchronized引起的,这个同步块中,是对一个计数的变量做操作,这个计数是用于判断,是否告诉当前请求的客户端,换一个服务器(为了降低本机压力)。把这个地方改为用Atomic的操作后,发现性能没有太多的提升,索性注释掉了所有的逻辑,直接返回数据。发现,好像还是不够快。我们是采用Spring MVC来完成的服务,后来直接用写了一个Servlet来提供服务,就快多了,开始用SpringMVC的响应时间平均在20ms左右,换成了Servlet后,就变为5-6ms了。
    这里不是说框架不好,其实框架对开发是带来了很多的帮助,加快了速度,降低了开发成本,这里只是想提醒大家一下,对于特别关键性能相关的地方,还是要考虑下框架是否会可能带来性能的影响。对于特别关注性能的地方,是可以用看起来不那么优雅,设置可能有些ugly的方法来实现。

一个内部简单系统-持久配置中心的经验

公司内部有一个配置中心,采用推送的方式来推送配置到客户端,对于Runtime的数据和持久的数据,都采用同样的方式处理。整个系统是一个集群。持久的数据也都是存在每个节点上,节点之间的数据会复制。
    我总觉得,持久的数据的特性和非持久(Runtime)的会有所不同,一般Runtime的数据的特点是需要非常快的更新到客户端,让客户端感知到数据的变化。而持久的数据,需要的是客户端启动时的可靠获取,以及配置数据持久保存的安全性等。
    后来主导,起了一个新的产品,专门用于管理持久配置数据的,提供了Get的高可用性,采用数据库并且主备的方式,保证数据本身的安全。
    产品出来后,发现了几个问题,
        第一个,内部有了两个配置中心,一个是管理持久数据的,一个是Runtime数据的,但是,对于内部的开发人员来说,复杂了
第二个,原来都是使用一个客户端,现在迁移的时候,有一定的迁移成本,而不是完全透明的
第三个,对于运维的同事和线下的配置管理员来说,多了一套系统
第四个,其实之前没有仔细分析清楚,就是对于持久的配置数据,一般是不会改动的,但是真的改动的时候,也是需要能够立即通知到客户端的。而这个地方,确实新的持久配置中心没有解决好的。
    在开始这个产品之前,觉得是尽量把持久的配置中心做到很简单,做到可以应对意外情况(比如意外的时候,可以读取本地配置;配置是文本的,可以方便的人工介入),可以,还是有不少的地方没有想清楚。这个真是教训啊。
    对于一个看似简单的产品,
         1 还是需要想清楚真实的使用场景
 2 考虑对现有的影响,包括但不限于使用这个产品的人;运维人员;配管人员;测试人员等等。
 3 类似概念的产品,最好只有一个。对于Runtime的配置,持久的配置,其实都是配置,虽然特性上可能会有很大的差别,但是对于使用者,还是隐藏一些使用上的细节比较好。

2010年5月4日星期二

QCon北京归来小结

   参加QCon北京站回来已经有两个礼拜,一直想写一点自己的感想。今天终于是可以抽点时间来记录一下了。

    这里就谈谈自己的几点感受。具体TOPIC的内容,我想很多朋友也有些分享,包括也有PPT可以去参考。

  1.  英语的听说能力真的很重要。国内的教育(起码我读书的年代)培养出来的学生,英语的读写能力还行,但是听和说就会比较薄弱。自己在QCon中,直接听英文的,能听懂部分,有些是小部分,有些是大部分,总之是有些障碍的,听同声翻译,有些时候可能还不如直接听英语。这里就首先想说下英语的重要。
  2. 在解决问题的前提下,简单就好。不是越复杂越炫就好,而是用最简单的方式、设计、架构来解决所面临的问题,才是最好的。
  3. 分区(Partition)  分区的概念提了很久,但是关键还是如何分、分了以后是否有数据复制,如果有数据复制如何来解决。这些是需要根据自身的业务、目标来决定如何做。比较常见的,根据时间来分、根据用户来分、根据存储对象的owner来分(比如交易,owner可以认为有两个,卖家、买家,这个时候就会有双份,有数据复制的问题产生)。另外,一个基本的原则是分区之间尽量不要有强依赖,这样的分区是比较能够部署在物理上的多个地方。
  4. 制定特定问题域中的解决方案,在工作中,我们不要去追求一些貌似能够通用的方案,而是能够分析清楚问题域,并且针对这个问题域,制定高效、稳定的方案,来解决问题。