2011年12月14日
摘要：
1.前言本文的目的是让一个从未接触Hadoop的人，在很短的时间内快速上手，掌握编译、安装和简单的使用。2.Hadoop家族截止2009-8-19日，整个Hadoop家族由以下几个子项目组成：成员名用途Hadoop CommonHadoop体系最底层的一个模块，为Hadoop各子项目提供各种工具，如：配置文件和日志操作等。AvroAvro是doug cutting主持的RPC项目，有点类似Google的protobuf和Facebook的thrift。avro用来做以后hadoop的RPC，使hadoop的RPC模块通信速度更快、数据结构更紧凑。ChukwaChukwa是基于Hadoop的大集 阅读全文
摘要：
项目中的前端组件已达到一定规模，平时常常有开发人员来询问我组件的用法，并且已存在很多由于使用不当造成的问题，因此有必要出一份前端组件的使用文档，方便别人，也方便自己。使用什么样的格式让我费了不少脑筋，使用word不方便别人索取和自己更新；使用wiki，不方便自己编写；使用普通的html，成本很高。觉得如果能做一个类似于Ext Api Doc那样的文档就很不错，使用它很方便，不光能建立起类与类的层级关系，还有很强的搜索功能。隐约感觉Ext Api Doc不是专门用Ext开发出来，而是通过源码里的注释自动生成出来，因为Ext源码里的文档和Doc是一一对应的。所以现在需要做的就是，按照一定的格式完善 阅读全文
摘要：
在Ajax盛行以前，浏览器内存泄漏不是什么大问题，因为都是通过页面跳转和刷新来进行与服务端的交互，而现在情况不一样了，很多应用广泛应用Ajax和iframe，结果内存泄漏成了很多富客户端应用的隐患。比如我现在参与的项目长期以来一直深受内存泄漏问题的困扰，测试人员常常抱怨，因为他们是使用软件最多的人员，常常几个小时后的点击就让浏览器占用的内存达到几百M，有时甚至到G，但我们开发人员始终没有很好解决这个问题，归结其原因，主要是开发人员没有关注内存泄漏的意识，开发时只管功能实现，不管是否造成了内存泄漏，但问题积攒到一定级别时，解决问题的成本就不小了。同时，检测内存泄漏的工具和手段确实有限，仅有的两个 阅读全文
摘要：
一个完整的mysql读写分离环境包括以下几个部分：应用程序clientdatabase proxydatabase集群在本次实战中，应用程序client基于c3p0连接后端的database proxy。database proxy负责管理client实际访问database的路由策略，采用开源框架amoeba。database集群采用mysql的master-slave的replication方案。整个环境的结构图如下所示：实战步骤与详解一.搭建mysql的master-slave环境1）分别在host1（10.20.147.110）和host2（10.20.147.111）上安装mysql 阅读全文
摘要：
web服务器都提供长连接的方式，所谓长连接就是客户端一次请求完后，不关闭连接，保持一段时间的连接，下次此客户端再次请求时，不用创建新连接，复用所保持的连接即可。从理论上，长连接可以免去大量建立和关闭连接的资源消耗，但同时也有大量连接被占用的代价。因此可以初步判断长连接比短连接能带来更高的TPS，更低的CPU消耗，更少的IO，更高的内存占用，下面通过实战来验证。服务器环境和测试工具可以见工具和环境准备篇本次web服务器选用apache prefork模式，apache长短连接的选择可以配置httpd.conf里的KeepAlive选项，如：KeepAlive On：长连接KeepAlive Of 阅读全文
摘要：
一.web服务器1）apacheapache分为很多模式，大家最熟悉有prefork和worker两种，在linux上安装apache可见文档值得注意的是prefork和worker的选择是在编译期，在make之前就需要选定安装的模式，如：./configure --with-mpm=prefork./configure --with-mpm=worker二.压力工具1）abab为apache内置的压力工具，功能简单实用方便，使用实例如：/usr/alibaba/install/httpd-2.0.63-prefork/bin/ab -c 100 -n 1000000 http://local 阅读全文
摘要：
越来越发现没思考就没有进步，忙碌的工作非但不能让你沉淀起来，反而会让你因为失去思考而变得空乏。身边不乏拼死工作却没啥突破的例子，也包括自己，问题关键就是与是否学会了思考。最近一直在思考这么一个问题，如何激发思考，如何使自己在千遍一律的工作中找到突破口。找到了一些思路和方法，总结如下：1）when---何时需要思考每天早上工作之前，安排当日的工作每天晚上给自己10分钟安静地想想当日的工作项目出现事故时，不管和自己是否相关，想想其原因和解决办法项目和公司发生变化时，想想自己在新环境如何改变和适应自己在工作中犯错误时，及时总结原因和改进办法他人取得成绩和晋升的时候，想想为什么无所事事的时候，做一些额 阅读全文
摘要：
架构师特质：能够帮助团队的同事解决问题，参与项目和产品设计对于公司的产品和项目发展方向有清晰的认知常常思考企业产品和项目的方向对公司产生的价值跟业务人员有良好的沟通，善于发掘需求具备很广的知识面，不一定要很深入大局观、开放心态和善于沟通复杂问题简单化的抽象能力架构师分类：基础平台架构师业务架构师数据架构师架构师的职责：平衡平衡需求和条件、平衡性能和功能、平衡需求和成本一致确保需求的一致性；取保产品规划、产品线架构规划和本产品架构与设计的一致；确保客户需求、架构约束、设计准则在实施阶段得到一致贯彻分解将系统分解成子系统；将子系统分解成模块；将模块分解成类设计集成将功能上的分解与系统性能和质量上的 阅读全文
摘要：
牛P的经验、经历、感受分享刘加伟：1. 做为技术方面的大牛/专家，一路走来，你最大的感悟和收获是什么?只有努力, 并且相信自己, 你才能获得一点一点技术上的成绩.2. 因为做技术的平时都喜欢熬夜、加班，在家庭和工作之间时间你是如何分配的？毕业前四时候, 我几乎是全身心的投入技术的学习中, 通过不断的吸取各种计算机方面的知识, 为后来的工程实践中积累了较多的知识. 因此成家后, 我感觉还是比较轻松, 大部分的工作都不需要加班就能完成.3. 在技术方面你通常给自己设定方向和目标吗？给自己的目标很简单, 在工作上,不会因为技术问题而变得束缚手脚.4. 工作之外你每天都花多少时间在学习上？以前很疯狂, 阅读全文
摘要：
架构师是个很需要沟通技巧的角色，需要和老板沟通，使其相信在技术上的可行性；需要和PD沟通，弄清楚商业逻辑；需要和项目经理沟通，使其更科学地安排人员和进度；需要和开发人员沟通，使其理解设计思路，保障设计架构在具体实施中得以落实；需要和QA沟通，使其了解项目的风险点和关键点。因此，架构师需要在沟通上下功夫，这是保障工作顺利进行的关键环节。下面是我总结的几个很常用的沟通方式：挑衅式的沟通方式具体方法：在矛盾双方中，以其中一方比较极端的观点来合理地构想后果，然后将这样的后果与另外一方进行沟通，激发另外一方去思考这种构想的后果，提出自己意见。适用场景：争论双方陷入僵局。适应式的沟通方式具体方法：确定主题 阅读全文
摘要：
在以前做钱掌柜的时候就想着做项目发布员，因为做这项工作可以帮助你对整个项目实际运转情况摸得更清楚，但后来还是放弃了，主要是感觉自己比较毛糙，不太适合做这项风险较高的工作。可这次计费中心项目让我没有退路，只有自己可以顶上去。计费中心是个新项目，发布环境和生产环境都为0，难点就在于需要从头开始搭建基础设施。这个项目构建用的是maven而不是以前阿里自制的antx，所以项目结构和构建脚本与以前项目都不太一样。但对于我这个项目发布新手来说，又恰恰是较为有利的一面，可以让我没有任何历史包袱，可以完全遵循自己的设计，发布过程中出现了问题自己处理起来更游刃有余一些。下面总结一下整个发布过程中的沉淀。项目发布 阅读全文
摘要：
在以前的项目里为了写作方便，总是以word文档的方式提供架构和设计文档，带来的好处仅仅是自己写作起来较为方便，但带来的麻烦却有很多，比如：更新文档较为麻烦。他人浏览较为麻烦，特别当需要从docx转换到doc的时候。很难形成与其他文档的联系。难以协同合作以上的缺点导致很不好的后果：设计有了更新却懒于同步到文档里，他人也不愿看文档，干脆直接来问设计者，文档支凌破碎，写文档成了个别人的事情。因此在计费二期里我决定摈弃用word的形式，改成用wiki，并在公司wiki里好好规划起来，相比较word，wiki有以下好处：完成基本格式文档很方便。文档聚合和组织很方便，关键在于要善于用标记语言，可以参考：h 阅读全文
摘要：
在项目过程中，通过观察，感觉做好PM这个角色需要做好以下几点：对项目关键点的细节要足够了解虽然PM可以不参与具体的编码工作，但并不等于不需要了解具体的实现细节，特别是一些影响项目成败的关键点。有些PM离技术越来越远，远到一些功能是怎么实现的、用的是什么技术、有哪些地方需要特别注意都不清楚，这会非常影响他的决策力和判断力，特别是在处理突发事件时会手足无措。在现阶段，特别是项目规模不大的情况下，感觉PM兼任架构师比较好。对项目各个阶段的时间点要足够清晰PM头脑得时刻有一个清晰的项目roadmap，并对每个时间点做好准备，比如在项目立项前，预估好工作量和资源分配，与其他团队协调好时间点和容错方案；在 阅读全文
摘要：
经历过大 规模架构重构（ReArchitecture）的同学都知道：ReArchitecture是一个极其痛苦的过程，要想将原有的working的代码，彻底地用新的架构，新的技术 重新写一遍，其工作量是令人望而生畏的。最复杂的莫过于业务逻辑的梳理，如果你有精力将原有的代码从头读一遍，那是最lucky的事，但大多数情况下，别人写的代码 需要你自己重新写一遍，大多数人没有精力或不愿意去通读代码，而主要依赖于需求文档，结合旧代码，写出新的代码。但需求文档的更新永远赶不上代码的更新速 度，你得期盼原先写这个代码的同学有很好的习惯，将变更的需求反映在文档中，而且代码中有很好的注释。基本上这种情况很少见。 阅读全文