Linux经验随手记(旧)

这是10年的老文了。:)

其实谈不上什么经验,自己也是在使用Linux的过程中学习到不少东西。在使用Linux的过程中, 常常会冒出“自己好弱”的感觉,与人交流的过程中学到新东西,总会感觉很兴奋 ,而跟人讲解的时候,也总是希望可以得到一点反馈从而加深自己的理解~~(感觉)

工作会促使你不断去学习,而学习的效果会反应在你的工作上。 如果你对学习,工作的内容感兴趣的话,那肯定会让学习工作的效果更明显。应了那句话,兴趣是最好的老师~~(学习与工作)

学习linux,需要抛弃windows那套惯性思路。每个系统都有它的长处和短处,重要的是扬长避短,而不是取长补短。 相对windows来说,一开始会觉得Linux麻烦,使用不方便,很多工作要绕一个大弯才能解决问题。只有坚持学习,坚持使用linux,才能逐渐体会linux的好处。 就现在而言,linux主要的领域还是服务器方面,而windows的桌面一直都是非常棒的~~(linux与windows)

和linux打交道,基本是有两条路的,要么就是linux开发,要么是linux管理;linux开发嘛,几乎都是c的天下了。 咱们不是专门搞这个的,是其他语言+linux管理的搭配方式,主要用的也是shell和python,ruby,perl等等(我说的也是这个方向的)。 两者的区别还是比较大的,所以学习linux,最好还是好好考虑选择哪个方向把~~(关于linux学习的方向)

我第一次接触linux是在大学的时候,看到隔壁宿舍一大牛同学在玩linux,一个redhat8的发行版。 又上网去查查看,觉得蛮有趣的样子,借了光盘自己也装了双系统。不过好景不长呀,玩桌面的劲头很快就过去了,很快我就遗忘了linux, 重新回到windows。到了后来硬盘空间不够了(60g的盘),删除linux的时候,还把整个硬盘都给格式化了, 后来给网易的人取笑了一番。现在都觉得自己当时好糗呀~~(ps:我想很多人和我一样,linux的门找错了)

到后来要走上工作岗位了,才第一次听到李老大提到centos,fedora这些发行版(我真是孤陋寡闻呀,汗~~)。不过这个时候学习的方向总算不会偏离太多了, 而且这个时候空闲的时间也比较多(我是被遗忘的一族)。为什么说方向没有偏离太多,这是因为我根据网上一份优秀的教程来学习的,每天有空就在机器上捣鼓捣鼓。 虽然我不是很清楚学这些东西以后可不可以用上,但直觉告诉我,总不会没有价值的。这个时候我使用的是fedora8,教程就是鸟哥的私房菜了。 虽然说鸟哥的私房菜是很有用,但是熟能生巧,很多东西没用到,忘记也得特别快,体会也不会非常深刻。即使如此,我还是蛮有热情继续学下去,至少找到一点点门道了,在有一年春节回家前, 去书店买了本Linux技术管理手册(第二版),那个时候还没有中文版出来,咬咬牙在春节的时候把主要部分都读了一遍。 这个时候基本上是个人兴趣啦,毕竟工作上基本没什么机会使用到(ps:好的教材有必要,学习需要坚持)

后来也不知什么时候了,在工作中接触到越来越多的linux相关的东西,例如环境搭建,应用部署,安全与监控,分析与调优等。 这个时候也是个不断探索,加深印象的过程。这段时间看到自己学习的东西能够派得上用场,的确是很幸福的事情。 现在把工作环境都搬到centos,也没觉得有什么不习惯的。从我看来,熟悉linux的命令和目录结构是有效使用Linux的重要标志了。 呵,装个系统,然后开始linux之旅吧。下面的推荐书籍应该可以让你搭上linux 的“贼船”了。进阶的话,还是要不断通过充实理论和实践经验来获得的,linux博大精深,各自修炼,加强交流吧~~

推荐书籍:

  • Linux新手管理员指南
  • Linux系统管理员指南
  • Linux网络管理员指南
  • Linux操作系统之奥秘
  • Linux系统架构与目录解析(这本书我没看过,看邱老师的书另外一本感觉不错)
  • 高级shell 脚本编程指南
  • 鸟哥的Linux私房菜
  • Linux技术管理手册
  • Linux 目录结构简介(鄙人的,见笑见笑~~)

从某维护系统的架构改造谈起–分层的理解(旧)

这是刚到公司时写的~

公司的项目是一个维护有好几年的大规模电信项目,并且经过无数人的摧残,代码极其混乱。我们想改变这个层次不清代码混成一团的现状,引入业界广为使用的三层架构开发模式。如下图所示: 三层结构

最近小组一直在探讨如何从现有架构上逐渐迁移为分层清晰的状况,虽然我们主要的精力还是放在新增的功能上,但是在这个整个过程还是令我对分层有了更深的理解。这里主要说说对于通用分层的理解:

  1. 虽然大家都或多或少知道Action,Service,Dao干的是什么,不过实践起来的时候,有很多细节问题需要考虑(我们的系统有些比较蹩脚的调用接口,又不能抛弃)
  2. Action主要关注大的流程处理,其中可能会包括多个Service的处理(像我们需要与大量外围系统交互更是如此),一个Service方法代表一个具有完整事务边界的流程。
  3. Action和Service的边界主要由参数来决定,Service不需要知道调用方是一个GUI还是web请求,所以调用参数不应该出现request/response/session之类的对象, 应该限制为java基本类型,基本集合类型,简单的值对象(用于避免长参数调用),或者是具有特殊业务意义的变量(例如用户等信息)。
  4. Service和Dao的区分主要是业务相关性,Service不需要关心Dao究竟调用DB还是其他的数据源获得的(多数据源在大型系统中非常常见), 所以从调用参数和返回值上看,参数和返回值都避免具体的Dao实现有关。针对某些Dao调用返回值需要进一步处理,这部分的工作放在Dao还是Service取决于处理工作更靠近业务还是靠近具体Dao实现协议。
  5. 从关注对象上看,Action关注request、response、session等; Service关注java基本类型,java集合类型,值对象等;Dao关注Sql,ResultSet等底层数据结构。
  6. 从关注的异常处理看,Action关注特定的业务异常(BusinessException),并统一业务异常处理流程, Service只关心Dao是否发生异常(例如统一的Dao异常接口DataAccessException),记录并转化为相应的业务异常交个业务处理;Dao关注底层的异常,通常也无法恢复,只好转化成统一接口交给上层处理。

晚了,下一次就谈谈关于这个项目的异常处理的改造或者Dao的改造情况吧~~

从某维护系统的架构改造谈起–异常处理(旧)

这是刚到公司时写的~

Java 提供了两类主要的异常:runtime exception和checked exception。 所有的checked exception是从java.lang.Exception类衍生出来的, 而runtime exception则是从java.lang.RuntimeException或java.lang.Error类衍生出来的。

如果你希望强制你的类调用者来处理异常,那么就用Checked Exception; 如果你不希望强制你的类调用者来处理异常,就用UnChecked。 那么究竟强制还是不强制,权衡的依据在于从业务系统的逻辑规则来考虑, 如果业务规则定义了调用者应该处理,那么就必须Checked,如果业务规则没有定义,就应该用UnChecked。

至于类调用者catch到NoSuchUserException和PasswordNotMatchException怎么处理,也要根据他自己具体的业务逻辑了。 或者他有能力也应该处理,就自己处理掉了;或者他不关心这个异常,也不希望上面的类调用者关心,就转化为RuntimeException; 或者他希望上面的类调用者处理,而不是自己处理,就转化为本层的异常继续往上抛出来。 根据上面的一些观点在现有的系统上建立基于三层架构的异常处理模型,主要有以下做法:

  • Dao层次关注底层异常,当很多SQLException无法恢复,转换成统一的RuntimeException交给Service处理
  • Service层关心某些有业务含义的业务处理,并转化成相应的业务异常(同样也是RuntimeException)交给Action处理
  • Action层可能对某些特定的业务异常感兴趣,感兴趣就处理(或许尝试修复),不感兴趣就交给统一业务异常处理器处理
  • 统一业务异常处理器会记录exception log,并负责相应的错误展现页面

实现思路(待续):

  • exception util:提供一些异常处理的工具,例如转换异常
  • exception wrapper:作为统一的异常类,可以用来保存原始的exception信息
  • exception collector:可以保存多个exception信息的异常类,用于某些特殊场合
  • exception handler:用于处理exception的统一处理,主要是日志与错误页面

从某维护系统的架构改造谈起–公用代码库(旧)

这是刚到公司时写的~

有时候真是不看不知道,这样一个每月数亿业务量,数十亿营收的大型系统,原来也就是这样的质量。 我们可以想象这种系统一开始都是美好的,只是渐渐的变味了。就拿我们这边java的来说,原来也应该是有公用代码库的,只是那么久每人去维护,项目赶工, 自立山寨的情况多了,这些东西的反向价值就越来越明显了。典型的表现有:

  • 自立门户的现象很突出,经常可以找到n个方法是做同样事情的;
  • 神级的类很多,例如某个类可以提供字符串,时间,web,业务相关的操作;
  • 公用类代码质量良莠不齐,有很多明显写得不好的地方(曾经有个数千行的类就给我砍倒1/3代码);
  • 缺乏公用库的document和quickstart

这样造成浪费,花了很多冤枉时间去实现已有功能,缺乏统一规划。大家都有体会,维护一个杂乱无章的系统是多么的困难, 在这种系统想写出漂亮的代码是很考水平的。现在代码库又特别庞大,怪不得很多同事慢慢地就给系统同化了, 缺乏持续改进的动力。在上次retro会议的时候,针对缺乏统一的公用代码库的问题,针对质量和维护的问题,我提了一些做法:

公共代码库迁移

  1. 方向是在保留现有逻辑的基础上,针对新添加的功能和修改的功能,逐渐迁移到新的公用库。
  2. 至于公用库的选材,主要是从各大现有公用库进行提炼,对神级类进行拆分,并结合开发人员提需求的做法,形成我们的公用库。
  3. 为了避免山寨的出现,培训和文档是必须有的。
  4. 针对如何让程序员接受并找到新公用库的问题,建立新的source目录,并在文档上通过目录-包结构-类的层次做好文档(javadoc)。
  5. 除了必要的培训之外,主要的审查方式还是通过每天的code diff和定期的code review来做到大家对公用库的认同和理解。
  6. 维护是要靠大家去推动的,就像上面说的,由程序员反馈需求或提供补丁的方式,保证公用库的持续改进。

现在工作进展还算顺利,过段时间再看看效果怎样,或许咨询一下顾问看看有没有改进的地方。

avtivemq和规则引擎资料(旧)

10年时接触activemq和drools时收集的一些资料

activeMQ资料

activeMQ官方网站
JMS消息类型模型
实战activeMQ
ActiveMQ4.1 +Spring2.0的POJO JMS方案(上)整理版
ActiveMQ4.1 +Spring2.0的POJO JMS方案(下)整理版
ActiveMQ5.0实战一: 安装配置ActiveMQ5.0
ActiveMQ5.0实战二: 基本配置
ActiveMQ5.0实战三:使用Spring发送,消费topic和queue消息
ActiveMQ测试报告,这是一个很棒的报告
ActiveMQ 高级特性
Articles on ActiveMQ, Messaging and JMS 来自官网的文章集锦

客户端

关于客户端都可以在相应的官网上找到,这里要说的一个客户端是openamq-jms,简单来说,这是针对java JMS的客户端, 可用于OpenAMQ和其他AMQP服务器。还有一个是StompConnect,当然这是走stomp协议的,特色就是把JMS弄成一个Stomp Broker, 具体是怎样的,还没实践过。不过,要跨语言消息交互,更好的选择是使用已经提供的本地Stomp支持。另外,关于stomp的erlang客户端可以选择gigix推荐的stomperl

书籍

其实官方文档已经非常丰富,书籍的意义并没有那么大~~另一方面,关于ActiveMQ的书籍暂时还没有上市,只有本期书(activeMQ in action), 现在可以在网上找到这本书的手稿版~确实找不到的话,可以找我要,呵

activemq和rabbitmq

activemq和rabbitmq都是非常有名的开源消息队列。activemq是java写的,而rabbitmq是erlang写的。 activemq支持的是stomp和openwire,xmpp等协议,而rabbitmq支持的是amqp(Advanced Message Queuing Protocol)。 stomp是一个简单的容易实现的基于文本的协议,openwire是一种快速的二进制协议,activemq计划在amqp协议1.0版本完成的时候提供amqp协议的支持。 通过这些协议,activemq可以支持多种客户端,如C, C++, C#, Ruby, Python, Perl, PHP等等。而amqp同时定义了消息中间件的语意层面和协议层面, 并且是语言中立的,它可以让MQ成为一个可编程的消息中间件,可以想象这样的场景: 你使用java写的消息通过Erlang编写的中间件来和一个C编写的遗留系统进行消息交互。所以amqp前途是光明的~~

2009-01-15附加

activemq的failover功能配置很简单~例如简单修改brokerURL为”failover:(tcp://caixiaojian.hnjk.com:61616?wireFormat.maxInactivityDuration=0)”,正常情况是会出现下面的信息:

ActiveMQ Task 15/01 16:52:43,672 DEBUG [failover.FailoverTransport]-802 Waiting 5120 ms before attempting connection.
ActiveMQ Task 15/01 16:52:45,569 DEBUG [failover.FailoverTransport]-593 urlList connectionList:[tcp://caixiaojian.hnjk.com:61616?wireFormat.maxInactivityDuration=0]
ActiveMQ Task 15/01 16:52:45,569 DEBUG [failover.FailoverTransport]-712 Attempting connect to: tcp://caixiaojian.hnjk.com:61616?wireFormat.maxInactivityDuration=0
ActiveMQ Task 15/01 16:52:45,570 DEBUG [failover.FailoverTransport]-753 Connect fail to: tcp://caixiaojian.hnjk.com:61616?wireFormat.maxInactivityDuration=0, reason: java.net.ConnectException: Connection refused
ActiveMQ Task 15/01 16:52:45,570 DEBUG [ tcp.TcpTransport]-458 Stopping transport tcp://null:0

2009-01-16附加

结合spring和activemq的时候,发现启动挺慢的。因为老是会去网上寻找xsd文件,把xml里边的schemaLocation换成下面这个样子就可以了: http://activemq.apache.org/schema/core http://activemq.apache.org/schema/core/activemq-core.xsd ActiveMQ的Virtual Destinations和Mirrored Queues非常有价值,5.3新增的Message Groups也是很有用的特性来的

规则引擎资料

Java规则引擎与其API(JSR-94) 介绍jsr94标准
使用 Drools 规则引擎实现业务逻辑 一个简单的例子
在你的企业级java应用中使用Drools 提供web层和dao层的简单继承,不过rule用的xml格式~
drools和spring的集成 集成spring好像是必备功能似的
规则引擎实现探讨 一个小讨论,还看到一段Erlang代码
应用规则引擎组织业务规则的注意要点 里边提到一些建议和规范
看惯中文的,感觉这个blog还行,但是内容是基于drools3的
一个小学题目的解: 采用规则引擎Drools实现 一个喝汽水的智力题,一个比较不错的例子
springside里边用的jboss rules
另外还有drools官方文档,关于最重要的rule language和example部分是在Drools Expert上

其他想法

我对规则引擎理解不深,从drools的例子可以看到一些AI,workflow,专家系统的影子,看似用途很广很强大,可是规则引擎不是这么个用法的把
按照我的想法,规则引擎应该用在局部复杂的流程控制上(局部复杂的if else…),应该是基于业务走向的判断。
如上面yimlin提到的,我觉得规则引擎是来简化工作的,所以要避免任何具有实际意义的业务操作,很容易让人混淆。
怎么说这些规则也不大可能是客户来维护的了,因为可能涉及事实库的修改,dsl顶多也是对程序员友好的方式。
哪些业务规则适合抽象出来由规则引擎处理,规则引擎和业务系统的交互方式是主要问题。

引入规则引擎真的会带来很多好处么?对很多系统来说,这种java应用中嵌入groovy的方案还算满经济的。