您现在的位置：首页
--> 系统架构
声明：这篇文章绝不是一篇讨论 NodeJS 和 Ruby on Rails 孰优孰略的檄文。它描述的只是我们做决策过程中的一些思考、决策背后的原因。两种框架都非常优秀，都出色的完成了它们的设计初衷，这也是为什么我们部分的模块仍然运行在NodeJS上的原因。 我是NodeJs的大粉丝，认为这是一项让人非常兴奋的技术，相信它会变的越来越流行。我对这项技术非常的欣赏——尽管我们最近把Targeter App从NodeJS迁移到了Ruby on Rails。 我们当时使用NodeJS开发它的原因很简单。我有一个程序包，能很快的将我们的应用弄上线(我们花了54小时做这个事情)，相比起Ruby，我更常使用的是JavaScript。因为我们的技术架构牵涉到NongoDB，我的这些特长只有在NodeJS环境里才会有意义。然而，随着应用规模的增长，我认识到，选择NodeJS来实现这个应用是个错误的选择。
HBase的优点：分布式，易扩展，高性价比，运维成本低都是它的优点。HBase可以支持海量数据，单张表的数据量不上T，都不好意思出来打招呼。甚至可以拿很烂的SATA盘来作为存储，由于依赖底层的HDFS。新装的机器甚至可以不用做硬RAID。
传统的 MapReduce 如 Hadoop, 是以任务的形式进行的 — 获取一批数据, 提交给系统, 然后获取结果. 但是, 有一些统计的需求是即时的, 统计任务需要持续的运行, 一旦数据生成, 便立即发给统计任务处理, 生成的结果”推”给接收者. 以一个网站用户在线时长统计的需求为例子, 那么系统就有这几个部分: 数据接收接收 Web Server(如 Apache/Nginx) 的 log, 例如使用 syslog. Mapper(格式转换) 依次输入以行为单位的原始的 Apache log, 输出一条或者多条结构化的数据. 这个输出将出 Reducer 进行下一步处理. Reducer(统计器) 不同的精度用不同的统计器, 因为统计结果必须在要求的精度时间内进行输出. 例如当精度要求是小时, 用户连续在线1个小时, 并且横跨在2个自然小时上,......
当用户在一个网站浏览或者搜索商品时，在大多数时间他所面对的都是商品标题+商品图片的商品信息形式。只有当这种简要的信息抓住了用户的眼球时或者达到用户的心理预期时才能引导用户进入更详细的商品详情页。这就对其中唯一的文本信息载体：商品标题包含的信息内容质量提出了要求。
目前，中国的旅游企业面临着一个竞争非常激烈的经营环境。在现有的需求中获得足够的市场份额是每个企业非常关心的问题。酒店的亏损经营、旅行社的微利经营实际上预示着通过低价竞争获取市场份额的营销策略在中国已经走到了尽头。在这种状况下，迫切要求我们采取 一种切实有效的非价格竞争策略。价格战的根本原因是不能提供差异化的产品和差异化的营销。新经济建立在信息技术的基础之上，追求差异化、个性化、网络化和速度化。在这种时代背景下，将数据挖掘技术应用于旅游营销无疑是一种有益的尝试。
• Solr调优参考
共整理三部分，第一部分Solr常规处理，第二部分针对性性处理，前者比较通用，后者有局限性。务必根据具体应用特性，具体调节参数，对比性能。第三部分 solr查询相关的 具体应用需要全面去把控，各个因素一起起作用。
实时计算引擎在处理实时数据时，要保证新到来的数据被及时得到处理。例如，对于网站的访问日志数据，假设每一分钟有一个日志文件，那么实时计算引擎必须满足能够在一分钟之内处理完这一分钟的日志数据文件，否则会导致日志文件堆积而不能被及时处理。前几天，量子后端团队排查了一次实时计算引擎出现的处理延迟故障，其中使用到了ltrace和strace工具，在这里和大家分享一下。 1. 故障描述 当天由于大量突发异常数据的到来，导致实时计算引擎在处理每分钟日志文件时的速度大幅下降，出现明显的延迟现象，表现为平均每处理1分钟文件需要2分钟甚至更长的时间，最长可以到5分钟，进而导致了日志文件堆积而不能被处理。 2. 故障分析 实时计算引擎在处理日志文件时，采用顺次读取各分钟文件中的日志记录到内存中进行计算的方式（compute过程），因此引擎在每处理完1分钟文件时，需要进行日志的轮转切换（rotate过程）。
• 微信架构的启示
腾讯大讲堂中最近分享了周颢演讲的微信技术总监解读微信架构的秘密，看完视频的一些心得。 技术微创新微信的技术设计上有很多微创新，看起来都很小，但是对于系统的稳定性、用户体验及开发敏捷都具有重要作用。前轻后重由于客户端升级不便，从技术设计上尽量利用后端的设计来减少依赖客户端升级的方法。如某个版本新增了群聊功能，按常规思路，需要所有客户端升级才能全部打通。微信采用服务器兼容的方法，在老客户端不升级情况下让其增加群聊的功能，通过在服务端将群聊协议转换成之前旧版兼容的协议返回给老的客户端。客户端辅助设计微信客户端做了很多非常规的功能，比如常规的客户端测速方法是登录阶段轮询测试多个IP来选择服务器，这样会带来流量及登录速度双方面的开销，因此微信选择的方法是服务端返回最佳的IP（可能是通过历史数据分析）。客户端另外实现了一些容灾能力的配合，当一个IDC访问出现异常自动选择另外一个IDC。
这几天我的工作是设计未来游戏服务器的热更新系统。 这部分的工作，我曾经在过去的一个项目中尝试过 。这些工作，在当时一段时间与广州网易其他项目交流时，也对网易其他项目的设计产生过一些影响，之后，也在实战中，各个项目组逐步发展出许多热更新的系统来。 我最近对之前所用到的一些方案，如修改 lua module 的加载策略，增加一些间接层，来达到热更新代码的系统设计做了一些思考。感觉在处理热更新这个问题时，还不够严谨。经过两天的思考，我按我的构思实现了新系统的雏形。 在函数式编程语言中，热更新通常比较容易实现。erlang , lisp 都把热升级做为核心特性之一。函数副作用越小的语言，越容易做热升级：你只需要简单的把新写的函数替换回去就好了。
有时候，会有程序员跑到我这里说他们不喜欢某个东西的设计，“我们需要给它来个全面的重构”，来纠正里面的错误。哦，哦。这听起来可不是个好主意。而且这听起来也不是重构… 重构(Refactoring)这个词最初由Martin Fowler 和 Kent Beck给下的定义，它是 一种修改，使软件的内部结构更容易理解，在不改变软件的可见行为方式前提下使软件更容易变更…它是一种有节制的整理代码、使bug产生几率最小化的方法。 重构的结果是引用了快捷方法、去除了重复代码和死代码，使设计和逻辑更加清晰。是在更好的、更聪明的使用编程语言。是在优势利用你现在知道、但当时的开发程序员并不知道——或并没有加以利用的信息。不断的简化代码，让它们更容易理解。不断的使它们在将来的变更变得更容易、更安全。
摘要: 每个系统，都有自己的最大处理能力，后台技术人员对此必须很清楚，且要注意自我保护，不然就会被雪球压垮，出现雪崩。 雪球： 对于时延敏感的服务，当外部请求超过系统处理能力，如果系统没有做相应保护，可能导致历史累计的超时请求达到一定规模，像雪球一样形成恶性循环。由于系统处理的每个请求都因为超时而无效，系统对外呈现的服务能力为0，且这种情况下不能自动恢复。
《启示录：打造用户喜爱的产品》这边说第一张就讲到了“许多成熟的互联网公司都在使用火车模型发布模式”，对于火车模型发布模式具体是什么意思不太清楚，于是上网找资料，发现网上很好又介绍火车模型发布模式的，可能是翻译不一致导致的结果。对于火车模型发布模式其实也是很好理解的，下面就是我找的一个关于火车发布模式的案例，来自于FireFox开发团队。 Firefox目前正在采用的开苏发布过程其实就是火车模型发布模式，使用心得模式后一个新特性从实现并且进入mozilla-central分支到发布到用户手里只需要12-18周，并不向IE浏览器的更新以用一样要几年的时间。如此的快速发布过程给整个项目带来了更好的敏捷性和更强的稳定性。在每个发布周期的测试和稳定阶段可以覆盖更多的用户来帮助FireFox的开发人员更早的发现和解决问题，保持在每次发布质量上的信心。 下面就要介绍下Firefox的发布流程。
微软在今年2月份的GoingNative大会上正式对外发布了C++ AMP（Accelerated Massive Parallelism）开放规范。C++ AMP是微软于11年6月推出的一个异构并行编程框架，从Visual Studio 11开发者预览版起，微软正式提供了C++AMP的支持。C++ AMP的目标是降低在由CPU和GPU共同组成的异构硬件平台上进行数据并行编程（data parallel）的门槛。通过C++ AMP，开发者将获得一个类似C++ STL的库，这个库将作为微软concurrency namespace的一部分，开发者既不需要学习新的C++语法，也不需要更换编译器就能够方便地进行异构并行编程。
在增量DUMP过程中，我们的job比较小，但是启动非常频繁，每个job的执行时间短，通过执行的日志发现，有时会出现一个job的启动时间很长，需要几十秒。由于我们很看重增量的速度，所以几十秒的等待是不可接受的。分析：我们当时使用的Hadoop CDH3 Beta4 的版本。通过ganglia图表分析，出问题的tasktracker会出现一些流量的凸起。但是离带宽限制还很远。通过仔细分析TaskTracker的日志发现，Child子进程启动过程中，存在等待的问题。经过分析源码，Child子进程在启动过程是在一个线程中串行完成，启动过程包括了distributedcache文件的获取。
预计2012年5月7日，阿里巴巴集团将正式公布技术团队合并的事情，涉及的部门：阿里巴巴运维团队、阿里巴巴DBA团队、阿里巴巴平台技术部、大淘宝运维团队、大淘宝DBA团队、大淘宝核心系统部、阿里云计算运维团队、阿里云计算DBA团队和阿里巴巴集团安全团队，上述技术团队合并之后，从一些可以猜测到的信息分析，大淘宝的员工成为相关技术团队的掌舵者，以及去IOE政治运动是阿里巴巴集团首席架构师王坚主导的，阿里巴巴和淘宝的技术团队内部非常有影响力的行颠负责执行，那么阿里巴巴集团内部所有子公司去IOE运动将继续深化，就淘宝、阿里巴巴和支付宝去IOE事件，以局外人的角度进行利弊分析，希望能达到给明白真相和不明白真相的群众一个合情合理中立的分析。
最近多次看到系统设计与实现的文章与讨论，再加上以前读过的其他资料以及自己的一些实践教训，让我觉得应该把这些资料汇总整理一下。如果要从讨论不同系统的众多资料中总结一条黄金法则的话，那只有一个词——“简单”；如果用一个英语单词来表达的话，那就是——KISS (Keep It Simple, Stupid!)。
这一篇文档也是前阵子做实验的.puppet pro pdf 文档里已经说得够明白了,看到这里,大家应该可以明白,实现puppeptmaster的高可用性,不仅包括puppetmaster的压力进行负载均衡,还要考虑到puppet 认证puppetca的负载均衡.实现方案比较简单,但有很强的参考意义,也给我们实现puppetmaster cluster的思路.
近3天十大热文
-
[13] 手机客户端交互适配设计之我见 -
[11] 一句话crontab实现防ssh暴力破解
-
[11] 韩国实名制的破产
-
[11] 谈谈Facebook的聊天系统架构
-
[10] Oracle bbed工具的编译
-
[10] Python连接 MySQL 数据库的超时问
-
[10] 长假，回忆小时候的家庭教育点滴
-
[10] PDC 2010：C#与Visual Bas
-
[10] 四年前的今天，我开始找工作
-
[9] 强者生存论
赞助商广告
