Tag/
共84个网摘 [
1 2 3 ]
下一页 |
zdg收录，使用标签：Architecture, nginx，时间：2008-9-22 18:45:40 | 相关网摘，我也收藏
《使用Nginx轻松实现开源负载均衡》是我的演讲PPT（PowerPiont），现提供下载。
PPT分为四个部分：
1、介绍Nginx的基本特征，以及使用Nginx做负载均衡器的理由。
2、用实例，来介绍Nginx负载均衡在大型网站的典型应用。
3、以实现网站动静分离为原型，对NetScaler硬件七层负载均衡和Nginx软件负载均衡做一个对比。
4、介绍如何亲自动手，按照步骤，在“五分钟内搞定 Nginx 负载均衡”。
http://blog.s135.com/read.php?369
zdg收录，使用标签：Sina, Blog, Architecture，时间：2008-4-15 13:19:46 | 相关网摘，我也收藏
sina新版博客已经上线(http://blog.sina.com.cn/lm/html/2008-04-14/1340.html)
1:功能进行规整和简化
2:架构调整,可以提供更强壮和更快的体验.
(1)nginx大行其道,不但作为proxy,还有部分的逻辑应用,比如区分博客新老用户
(2)cache处理更为理性,博主访问直接穿透squid,用户访问则直接调用squid,squid cache更新走消息队列机制,不会影响用户操作
(3)数据存储层包含mysql和memcached,但是也带来一个问题,数据操作需要有一致性
3:前端的渲染也归于理性,快速显示永远是第一.
http://hi.baidu.com/ywdblog/blog/item/fc3b6cc6a7bcde1e9c163d48.html
zdg收录，使用标签：sina, CMS, Architecture，时间：2008-4-15 11:07:38 | 相关网摘，我也收藏
在代码层次上看，SinaCMS是使用C 编码的，模板取数据的时候则使用了perl脚本。SinaCMS里面频道、项目和模板是结合在一起的，他们三者的关系是：
1.一个频道就是一个项目，在数据库里面体现就是一个数据库，比如说新闻中心，对应一个名为news的数据库；
2.一个频道会有若干个模板，例如首页，新闻页，这些在数据库中体现为相关的表；
3.模板需要定义模板域，模板域有表单类型模板域(Form)和应用类型模板域(Application)两种类型，前者面向编辑的提供数据界面接口功能，后者面向技术支持人员提供高级的二次开发功能。模板域在数据库中就是模板表中相对应的数据扩展字段，例如Form::TextField对应的就是text字段，数据由编辑录入，Application::SQLResult
也是text字段，存储的则是执行Perl脚本执行后的结果。模板的内容存储在另外的字段中。
不难看出，SinaCMS具有极其强大的灵活性。因为它的数据库结构是项目建立以后构建模板的时候才确定的。各个频道，例如资讯频道、财经频道和汽车频道，可以拥有完全不同的数据库结构，不同频道的特殊需求也可以完全定制。另外可以看出SinaCMS里面的模板是最主要的模型，承担了确定数据表结构、文章发布和管理以及配置频道参数等等功能。
http://panweizeng.com/archives/133
zdg收录，使用标签：facebook, Architecture, PHP, memcached，时间：2008-4-14 18:00:28 | 相关网摘，我也收藏
Facebook 平均每个用户每天要访问超过 50 个页面，PHP的页面载入时间的优化就比较重要了。在 PHP Cache 层，Facebook 采用了 APC。
Facebook 部署了超过 400 台 Memcached 服务器，超过 5TB 的数据在 Memcached 中。这是当前世界上最大的 Memcached 集群了。也给 Memcached 贡献了不少代码，包括 UDP 的支持和性能上的提升(性能提升超过 20%)。
Facebook 开发人员大量采用 Callgrind 、APD、 xdebug 、KCachegrind 等工具进行基准性能测试。任何一个 Web 项目，这也是不可或缺，也是比较容易忽略的一环。所有开发人员都应该具备熟练使用这些工具的能力才好。
http://www.dbanotes.net/arch/facebook_php.html
zdg收录，使用标签：Architecture, 存储, Web2.0，时间：2008-1-28 17:35:59 | 相关网摘，我也收藏
我首先是对 Squid 有点疑问，对此阿华的解释是"目前暂时还没找到效率比 Squid 高的缓存系统，原来命中率的确很差，后来在 Squid 前又装了层 Lighttpd, 基于 url 做 hash, 同一个图片始终会到同一台 squid 去，所以命中率彻底提高了"
Image Process Server 负责处理用户上传的图片。使用的软件包也是 ImageMagick，在上次存储升级的同时，对于锐化的比率也调整过了(我个人感觉，效果的确好了很多)。”Magickd“ 是图像处理的一个远程接口服务，可以安装在任何有空闲 CPU资源的机器上，类似 Memcached的服务方式。
Yupoo! 一方面采用不少相对比较成熟的开源软件，一方面也在自行开发定制适合自己的架构组件。这也是一个 Web 2.0 公司所必需要走的一个途径。
http://www.dbanotes.net/arch/yupoo_arch.html
zdg收录，使用标签：管理, Architecture，时间：2007-12-26 17:03:58 | 相关网摘，我也收藏
大家都希望自己参与的项目能够成功交付，然而影响每个项目是否成功的因素却千差万别。在此，根据自己的经验，说说一些在适当时候有用的方法，可以从一定程度上提高项目成功率的方法。就像设计模式一样，这些方法的使用过程必然是一个仁者见仁、智者见智的过程。
1. 尽量不要考虑项目外的重用
许多人认为能提高软件的重用度是最好的，然而每个项目实际情况都会有所不同，在设计项目中的某个模块、方法时，过多的考虑项目外的重用，必然会参加项目的复杂度，增加时间的开销。也许有人会说，这会减少下一项目的开销，试问，下一项目是什么项目？有什么需求？各方面有什么影响因素？有谁会在当前知道这一切。 如果真要重用，应该是在项目结束后再将可重用的部分提取出来，经过修改、优化后做为企业的可重用资产，而不是当前项目中的一厢情愿。
2.经常检查项目架构
项目架构通常是在项目实现开始前就已确定的东西，是一个总体的设计。然而，在这时，对项目需求的理解、复杂度的估计对还停留在一个初始阶段。如果在项目开发过程中不随着对项目的理解改进架构，必然让项目中的成员都按错误的方法开发项目。所以，必须经常检查项目的架构，进行必要的重构。
3.重构
有人说，都写了这么多了，再修改不是浪费时间嘛。他可能没有想过，一个下午的重构可以加快以后几个月的开发速度，这节省下来的时间是无法想象的。再者，通过重构，通常能想到更多简单的方法来代替现有的实现，这样的经验，同样可以简化其他模块的开发。
4.避免过度集成，让每个模块只做自己的事
一个常见的例子是，在业务系统中通常会有许多的审批，很多人一下子肯定会想到把审批做成一个通用的模块。这是没有问题的，然而通常的问题是，太多的人将审批结束后的业务处理也放到了审批模块的业务逻辑中，其实，那些是各业务模块自己的事，审批应该只完成审批即可，至于审批结束后怎么办，让该干这事的模块自己去处理。
5.避免过度灵活
设计和代码并不是越灵活越好的。一个常见的例子是，使用泛型时可以使类或者方法操作不同的对象，然而，在 .NET 常用的 N 层架构中，如果一系列的类本来就是针对某个特定实体的操作，就没有必要还指定为泛型，再在使用时指定为使用特定的实体类。这颇有画蛇添足的感觉。
6.减少锦上添花的功能
页面无刷新，更酷的显示效果等等，对于业务系统来说都是些锦上添花的事，如果因为这些而使业务界面非常复杂，给业务处理带来一系列的问题，极端情况是业务处理无法继续时，再漂亮的界面也是无用的。一个忠告时，仅在确保业务处理正确进行的前提下再考虑其他的。这一点有一个前提是与用户进行必要的沟通。
7.适当拆分
这一点与 4 类似。尽量降低每个模块的复杂度，让脑力劳动转化成体力劳动。一个常见的例子是，通常对某个表单都会有增加、修改、删除和查看的功能。但是，前三种操作通常仅在某个功能点上、特定状态和特定权限的人进行操作(也许仅在在系统中的唯一一个界面中)。而查看操作却会分布在项目的各个角落，如果将这四种操作都放在同一界面中，虽然可以减少界面数，但增加的却是这一界面的复杂度，要对各种状态、条件进行必须的判断来进行界面元素的只读设置，这个复杂度的增加是指数级的，而如果将查看拆分开，工作量将是线性的，就算要做10个查看界面，总比复杂度变成 10*10 要容易处理得多，况且还可以组件化。
http://www.cnblogs.com/doriandeng/archive/2007/12/25/1014814.html
共84个网摘 [
1 2 3 ]
下一页