坚信科学,分享技术

>>>尝试更加利于阅读的2014版科学院,以后都在新版上写。

Category Archives: 架构研究

大负载网站架构相关的研究记录。

《移动互联网技术挑战》-ssdc

以下是上周末在苏州参加的活动使用的slide,http://softwaresuzhou.org。 看不到的同学请猛击这里 ssdc-移动互联网技术挑战

Continue reading

Posted in 架构研究 | Tagged | Leave a comment

百人共用企业maven私服nexus迁移搭建手记

三年前,小米的第一个nexus(版本1.8.0)在一台dell的办公机上安装完成。域名为http://www.a.com。 三年后,a.com时不时已经慢得不行了。特别一到周一,大家都在update snapshot的时候,完全陷入一种无尽的痛苦中。 然后弄来了一台专业server做这事情,域名为http://www.b.com。版本到官网一看,已经2.64了。日新月异! 看升级文档顿时没了兴趣考虑升级,全新从零安装。 最后的办法是,在新机器上安装新的,把老的仓库挑出来设置为proxy类型。然后启用了ldap,同时保障大家都有deploy权限的同时,最大保障大家的密码不明文出现,同时通过代理ngx来限制最大上传的包,同时规定了snapshot的使用规则,防止在线上使用snapshot。以下是详细记录: 一、下载安装nexus和配置nginx 找个磁盘分区不小的: wget http://sxrelease.n.miliao.com/nexus-2.6.4-02-bundle.zip unzip nexus-2.6.4-02-bundle.zip bin/nexus start 然后就能用了。http://www.a.com:8081已经启动了。当然了,如果还不能访问,应该是iptables在捣乱,试一下iptables -F。 [nginx安装忽略] 然后再在此机器上配置一个nginx代理到8081端口上。只举是为了:1.分担jetty的访问压力,毕竟公司人已经越来越多了。2.好做后续更多的事情。 server { listen       80; server_name

Continue reading

Posted in 架构研究 | Tagged | Leave a comment

移动互联网系统架构十大陷阱

过去的三年,54chen一直奋斗在中国移动互联网一线,历经各种坑爹的情况。以下特做记录。 Top 1.时不我待 连通性 cmwap cmnet这样的词语以后应该都会消失在人世间。三年前,经常性地有移不动联不通手机连不上服务器机房的情况。两年前,这种情况要好了一些。一年前,改善很多。现在还存在。相信未来会越来越好,时代在召唤!解法,花钱找有“背景”的机房。 Top 2.生不逢时 HTML5 在去年的网络情况下,HTML5依旧不适合用来做优秀的app。前几年的时候,网速各种烂的情况下,2G下的html5应用基本上完全不能用。现在好一点,开始有闲人把html5全部封装好native的调用,使其只做view的显示部分,但是,性能也是个大问题。当然了,同样地,相信未来会越来越好,同样是时代在召唤!解法,过几年再用。 Top 3.环境恶劣 DNS DNS解析也有失败的情况下,app做得再漂亮,请求也不可达。IP要比域名靠谱一些,却有别的问题。解法就是在客户端多留下点域名和ip,一个不能用换下一个。 Top 4.车匪路霸 http拦截 天朝运营商,可以干得出你想不到的事情。各种小广告帖你家防盗门上。所以你最好还是在header里声明好了:畜生,这个不是html,这是json,不要加广告! Top 5.五花八门 app添加按钮一定要克制 特别是android app,完全没有限制,或者统一标准,什么样的App都有,做一个大气的App,最重要的一点,看看能不能打开就是主要功能,手指点一下就能到重要功能。 Top 6.逆流而上 完全不要在传统web上有所期待 除了新浪微博、QQ空间这种从传统

Continue reading

Posted in 架构研究 | Tagged , | Leave a comment

如何写一手好文档(好代码)?

好久没见。 中秋去了一趟草原,放空了大脑,回来灵感突发,对文档、代码写法这方面的感悟多了些,特记录一下。 一、什么样的文档(代码)叫做“好”? 任何一篇文档,目标都是给别人看懂。 任何一段代码,首先也都是别人能看爽了才是目标。 以上述“世界观”为准,很容易得到文档(代码)好不好的结论。 以80后小时候读的连环画为例,它就是优秀文档的典范。 像连环画这样优秀的文档,主要具备以下几个特点: 1.长篇被分成小节。 2.小节中关键页有图。 3.描述言简意赅。 4.页数固定不多。 典型地,如果在写文档(代码)时,能够做到上述四点,都是优秀的。 比如: PHP文档造福了多少PHP程序员,让PHP这门语言流芳百世、追随者众多。在PHP文档中,每一小节都进行了特别归类; 在关键位置还有不少例子代码; 每个方法的作用也是言简意赅; 每一小节的数量都不是很多。 再来看nginx代码,完全是一个大型服务端软件构建的一个范例。只看src目录中的源码,从一开始就分成了core、event、http、mail、misc、os,这样相当清晰明了的层级结构和定义,让后续很多事情方便扩展; 每一部分的代码都能够让读者一眼看明白是做什么的; 每个细节的方法长度也不是特别长; 每个分类里的内容也相对是固定的,后续的改进都是在plugin上比较多。 二、几种实际的土办法提高文档(代码)能力 在上述建立好了对好文档(好代码)的世界观之后,下面再分享一些总结出来的套路,如果前面世界观没理解透,只把这里的土办法理解了,也能写出来容易读的文档(代码)。 办法一、写文档先写段落标题,写代码先建分类目录(java叫做pa

Continue reading

Posted in 架构研究 | Tagged | Leave a comment

arduino-各种无线方案的对比

初中物理 振荡的电场和磁场在空间中以波的形式传播就形成了电磁波,gamma射线、X光、紫外光、可见光、红外光、微波、无线电波和长波无线电,这些都是电磁波。电磁波具有波粒二象性,光子就是量子化的电磁波,是电磁波能量的最小单位。光子的能量和电磁波的波长成反比,比如说,波长最短的gamma射线光子能量高达百万甚至数亿电子伏,医疗和安检用的x光光子能量一般在数百到上万电子伏,紫外光的能量一般在数个到数十电子伏,可见光的能量在1.8(700纳米的红色光)到3.1电子伏(400纳米的蓝色光)之间,红外、微波和无线电波的光子能量就小的多。在电磁波和物质相互作用时,物质只能吸收或者放出整个的光子。 蓝牙 有效距离:10-50米。 波段:低频微波。(2.4GHz) 协议:Bluetooth4.0可达50米。 特点:需要设置master还是slave,需要配对后1V1传送。 WIFI 有效距离:10-100米。 波段:低频微波。(2.4GHz) 协议:IEEE802.11b可达100米。 特点:就是家里常见的无线路由器啦。 红外 有效距离:1米。 波段:红外线。 协议:一般的遥控器有sony的协议,IR收发是标准化组件,在IRremote中全部有实现。 特点:不能穿,要对准,离得近。 zigbee 有效距离:500米。 波段:有多波段,主要低频微波。(2.4GHz) 协议:802.15.4协议。 特点:具备了强大的设备联网功能,具有很强的网络健壮性和系统可靠性。 XBee OEM RF模块是与ZigBee/IEEE 802.15.4 兼容的解决方案,可以满足低成本低功耗无线传感网络的特殊需求。

Continue reading

Posted in 架构研究 | Tagged , | Leave a comment

从分布式存储设计到自动化运维

http://www.infoq.com/cn/articles/nosql-dynamo 三年前在infoq发表的一篇关于两种特别有代表性的分布式存储的设计思路解析,三年过去了,今天再来总结看看这几年的变化。 实际上,这三年,还是两个东西,一直没有冒出来更牛B的东西。 一、dynamo代表作riak特点 早几年以cassandra为代表此类项目,固定特点为:水平扩展、无中心节点、多备份、最终一致性、性能一般、适合海量数据。因为cassandra在业界的使用失败案例太多,让大家避而远之。这两年,以erlang开发的riak又冒出水面。 1.1 erlang 这作为riak的最大特点一点也不为过,因为语言在分布式领域的独特能力,使得riak的源代码十分简洁干净。不过一万多行的代码,在第一次读到它的代码时,我也感叹,几年前,傻希希的用java代码堆了十几万行的nuclear代码,真是太笨了。 1.2 完整的dynamo实现 在cassandra的年代,许多东西不方便实现,版本控制的向量时钟使用了timestamp代替,vnode在cassandra上是非常大的区块,在进行负载均衡时有很大可能不均匀。到了riak的时代,所有的特点,在erlang的支持下,完成了各种细节。并且增加了:1.http存取的支持。2.双向索引。3.搜索支持。4.m/r支持。 二、bigtable代表作hbase特点 与dynamo对应的解决方案bigtable的历史更加悠久一些,开源项目也进行了很多年,hbase社区也正在不断地完善。 1.1 偷懒地依赖hdfs 严格说来hbase的实现,只主要关心了r

Continue reading

Posted in 架构研究 | Tagged , | Leave a comment

resin+thrift压力测试报告

基础条件 位置 参数 server resin 4 1 rose+1 thrift java version "1.6.0_29" Ubuntu 10.04 LTS 双核cpu 8G mem client macbook pro ab server代码 1.用thrift创建了一个方法,内部只有几行代码: logger.info("in call"); try { Thread.sleep(1000); } catch (InterruptedException e) { logger.info("sleep error"); } 2.使用的paoding-rose调用这个thrift方法。 第一波,thrift 10 …

Continue reading

Posted in 架构研究 | Tagged , , | 3 Comments

五步构建持续性部署(CD)

错误被发现的时间越迟,修复的难度越高,代价也最昂贵。如果工程师在敲下代码的时候就发现了问题,那修复的成本几 乎为零。如果编译器捕获了bug,它对开放时间造成的影响就是以分钟计的。如果bug进入了产品,而且在一段时间内没有被发现,找到bug、修复bug的 代价就会让人觉得难以承受。千年虫问题就是一个典型的例子。 ----题记 from http://www.infoq.com/news/2009/03/Continuous-Deployment 持续部署的目标是通过减少批量工作的大小,并加快团队工作的节奏,帮助开发团队在其开发流程中消除浪费。这使团队能够一直处于一种可持续的平稳流状态, 让团队更容易去创新、试验,并达到可持续的生产率。 下面是来自Eric的五步构建快速部署的办法: 1.CI服务器。持续性部署的前提是持续性构建。我们需要一个地方去做单元测试、功能测试、集成测试和所有测试。这些事情会在每次commit之后进行。一定要确保所有的test在10到30分钟内全部跑完。如果不可能做到,那就将它们进行归类。 2.代码控制提交脚本。不管是svn还是git,都有各种hook的勾子程序,在每次commit前嵌入检查逻辑。这概念来自于传统意义上的“生产线”,一旦在线上的产品发现问题,将停止进入,进入暂停阶段。修好之后继续运转。如果1中的持续构建有一个test case不能过,那这个脚本要能够阻止再来的commit。简单地说,就是让代码能够检查的bug代码不能进入。 3.简洁的发布工具。不需要多复杂的工具,只需要每个人都遵守的、简单的办法,同时要遵循CI没通过就不能使用的原则。 4.

Continue reading

Posted in 架构研究 | Tagged | Leave a comment

qcon杭州2012读后感

我没有在现场,所以叫读后感,只是看pdf文件之后的总结,如和现场体验有误,以现场为主。 给力排行一:云中的资源管控 淘宝林昊大师:提到2010年时三分之一的虚拟机peak load小于0.5,LXC重度用户,各种资源隔离的坑都被他们解决了。在进一步做动态调度。 腾讯CEE系统介绍:产品细节惊人,疑似依赖LXC。 京东虚拟化:openstack用户、使用传统vm。 CloudFoundry:完整讲述了实现和演进。 盛大游戏私有云:在游戏业务中使用,未明显提及虚拟化的事情,猛一看像是做分配机器之类的事情。 给力排行二:大数据hadoop 阿里巴巴:3000 Servers,正在演进hadoop as service,原来yahoo维护hadoop的大侠们去了那里,这个方向应该是靠谱的。 百度:2500 Servers,与阿里方向侧重不一致。当然了,也有可能是集团利益让牛B的构架师发挥不到极致,如果有这种现像存在,可以考虑来小米。(mail to chenzhen at xiaomi dot com 无耻的广告。。。) 给力排行三:工具和思路 网易:puppet在运维中的各种使用 陌陌:移动运维非常赞!让关注变得更简单更快捷,更容易让团队成员关注系统运行。 支付宝:SOA治理等。

Continue reading

Posted in 架构研究 | Tagged | 7 Comments

cloud foundry - how to bootstrap a system in centos6

1)install febootstrap Febootstrap is a tool like debootstrap in ubuntu. #yum -y install febootstrap #febootstrap centos6 rootfs http://mirror.neu.edu.cn/centos/6.3/os/x86_64/ Threre is a basic centos system in rootfs dir. 2)install ruby 1.9 (optional) yum -y groupinstall "Development Tools" yum -y install openssl-devel …

Continue reading

Posted in 架构研究 | Tagged , | Leave a comment
Page 1 of 712345...Last »