"微软的框架设计规范{#h.u8}是 设计的准则，它期望所有的微软类库和独立开发者都能够遵循这一准则。随着每个.NET框架版本的发布，以及在行业内的测试，它们的版本也得到了精化。通过 Cwalina与Abram所著的《框 架设计规范》第二版{#t.q.}的发布，我们可以看到微软在今后几年的发展方向。\n或许最令人惊讶的事实是日渐增长的对于测试驱动开发和依赖注入的重视。在可重用框架的场景下，通过测试驱动开发设计出的框架是真实可用的，而不是简 单地推理。他们希望这样可以反过来杜绝某种趋势，那就是过度复杂地设计一些根本不会用到的功能。\n谈到这一问题，就不得不指出的是微软当前正在推动的一个活动，即针对所有库的第1个版本进行最低限度设计。这不同于在第一次就要试图将所有事情做 对，微软推荐在最开始只需要满足需求中绝对需要的特性。Abrams和Cwalina建议在最初并不需要考虑扩展性，只有到需求变得非常清晰的时候，才在 后一个版本中考虑。从某个方面来讲，这是微软旧有传统的回归，它只会在第三个版本中提供真正完成的应用程序。\n在其它领域，微软则完全没有改变。他们仍然强调所谓的“基坑成功（Pit of …"

"统架构师角色关键的一方面就是衡量相互冲突的需求、决定解决方案，常常要牺牲一个方面来换取另一个方面。随着系统变得越来越大、越来越复杂，越来越多关于 如何构建应用的传统智慧正在受到挑战。比如说，去年3月在伦敦召开的QCon会议上，Dan Pritchard谈论了eBay的架构。他的介绍随后得到了很多的报道，其中一个主要的结论就是eBay不使用事务，用数据一致性上的损失来换取系统整 体伸缩性和性能上相当大的改进。\nInfoQ接着Dan Pritchard在QCon会议上的谈话与他继续讨论，以获得更多信息：\n为什么eBay不使用事务，或者为什么可以决定不采取应用级事务？\n我们并非一概不使用事务。我们只是不使用跨物理资源的事务，因为它会造成多个组件之间出现依赖。组件可以是应用服务器和数据库。（例如在客户端控制 的事务中，）一个客户端的失败会长久地阻塞数据库资源、超出我们的忍受程度。我们也不使用分布式事务，因为让应用依赖于多个数据库会降低客户端实际的可用 性。相反，我们选择缺少事务的设计，并加入失效模式，失效模式可以使客户端甚至在发生数据库可用性问题的时候也能继续进行。\n应用级事务总是有些问题。只 …"

"在前一期 山寨交流会 上： 桂 新 说他会将良好的构架和一套完整的监控系统作为两个非常重要的基础来抓，良好的架构一步到位这点很难做到（对于发展速度并不确定的小公司来说，架 构过大也是一个成本上的风险），但对于后者：一套完整监控系统我是非常认同的。对于目前普遍缺乏测试的Web应用开发过程来说，监控几乎就是测试很重要的 一部分；而系统监控本身，也可以帮助及时发现很多问题并量化优化的效果。而系统的扩展和调优的大部分技巧都可以从《构建可扩展的Web站点》(作者是 Flickr的开发者)一书中看到。为了减少不必要的调优（盲目的调优是危害很大的），建议从这2章开始看起： 第8章《瓶颈》发现和第10章《统计数据，检测和报警》；有了这些瓶颈检查结果和统计监测/报警系统后，再有针对性的看其他章节做系统调优。\n以下是我在 博客大巴 开 发中的一些实践小结：\n1 数据库相关\n1.1 系统应用层面出问题我一般都习惯性的先去看数据库群的连接数统计：大部分应用最后的瓶颈都在于单表数据量过大后，数据存取慢导致的并发连接数过多的问题，\n1.2 解决这个问题目前的主要策略就是分片( share nothing)，单个数 …"

"在前不久结束的 QCon 2008 上，MySpace 的首席架构师 Dan Farino 做了题为 Behind the Scenes at MySpace.com (PDF 下载)的技术演讲。\n架构概况 超过 4,500 台 Web 服务器，配置为 Windows 2003/IIS 6.0/ASP.NET ；超过 1200 台 Cache 服务器，64 位的 Windows 2003，超过 500 台的数据库服务器，配置为 64 位的 Windows 2003，数据库为 SQL Server 2005 。\n之前曾有一篇 揭 秘 MySpace 架构的文章，也有中文版本《 亿万用户网站 MySpace的成功秘密》！\n运维数据收集 其实这个演讲我感觉主要讲的是这个数据收集模块 🙂 MySpace 的方案倒是让我们看到了在超大规模的 Windows 环境下如何进行数据收集的。\n每个客户端通过一个 TCP 连接到收集上服务器。收集的信息包括：Windows 性能计数器 Performance Counters、 WMI 对象(定制后的 WMI 对象)、事件日志、 硬件数据等等。收集器服 …"

"从老高的近期工作总结中看到：\n目前的技术状况是基于自行设计的 PHP 框架，跑在 PHP 5.2 + MySQL 5.1 下，PHP 使用 Fastcgi 模式，WebServer 选择了 Nginx。搜索功能基于 Lucene 开发。缓存代理使用 Varnish。\n对老高进行了一次非正式采访，聊了不少内容，整理了一下和大家分享。(谁是高春辉? 这个不要介绍了吧，请 Google! )\n历史情况 Fenng: 原来大约是用什么? 框架用的什么？ 高春辉: 你说老系统？Apache 1.3 , DB 是 MySQL 4.0。新框架是团队自己写的，定制了一些东西吧，主要强调的是性能和方便、简单。另外把针对 YSlow 的优化也做进去了。 Fenng: 单说现在用的框架，大约投入了多少个人/天 ? 高春辉: 从全年开始考虑写，一直不断的写 — 具体时间不好说。反正是不少了 🙂 Fenng: 看了你 Blog 中的描述，有个小疑惑：没使用面向 DB 的 Cache 层? 高春辉: 我文中说的 Data accessor 就算是了。目前是拿 PHP 做的，Client+Server 集成在一起。 …"

"基于ID的分片机制实现存储的分布化会遇到一个问题：固定存储空间随着时间增加再次达到系统的空间/负载的瓶颈。观察了一下Flickr的图片存储 地址：好像是在定期启用新的集群，各个时期的域名分布如下：\nhttp://farm1.static.flickr.com 2006年中以前；\nhttp://farm2.static.flickr.com 2006年底；\nhttp://farm3.static.flickr.com 2007年底；\nhttp://farm4.static.flickr.com 2008年底；\n《构建可扩展的Web站点》 上 没有提到这个策略，猜测Flickr应该是不断在启用新的服务器集群，当地一个集群用到90%的时候，开始启用下一个集群。一个用户的所有图片地址则存储 在数据库中：记录会包含当时的存储所在的集群：\nuser_foo – farm1.static……/20060124_003.jpg\n\\ farm1.static……/20060324_005.jpg\n\\ farm1.static……/20060824_021.jpg\n\\ …"

"当Microsoft在PDC2008上携 Azure平台 驾 云而来时，天气预测注定将发生改变。将当前市场上分别来自Amazon、Google和Microsoft的三大主流产品作一比较会是一件非常有意思的事 儿。第一眼看上去的印象是它们彼此之间似乎实际上并不存在真正的相互竞争。\nZiff兄弟投资的副总裁Michael J. Miller 对云计算的三大角逐者进行了比较，这是他关于Amazon EC2的发现：\n备受关注的云平台无疑就是Amazon Web服务了，它是多种工具 的集合，大部分都位于相当底层。其中又以Amazon弹性计算云(EC2)最为出众，这一Web服务能你将应用分配给任意多的“计算单元”。简单的说，一 个标准的单一实例包括了一个“虚拟核心”，1.7GB的内存，以及160GB的存储实例（只针对该对话的存储），价格为每小时10美分。在这个服务之上， 你可能会考虑使用该公司提供的“简单存储服务”(S3)，对于前50TB的数据，其价格是每GB每月15美分，之后价格递减，同时要收取一定的交易费用。 同时你也可能考虑使用该公司的“Simple DB”数据库，或者是用于存储消息的队列服 …"

"前言：\n关于Digg的架构，之前 Fenng 已 经写过一篇 Digg 网站架构 的文章，Fenng在文章开头说“越来越发现其实都是自我重复的劳动，后续的信息都是嚼别人剩下的甘蔗。”，其实是 Fenng过谦了，我就是从 DBA notes 一点一滴开始学习的。\n原文在 Scaling Digg and Other Web Applications， Todd Hoff 总能给我们带来一些有意思的文章。这里既不直译也不全译，保持原文骨干加上肤浅的理解。\nDigg用户在3000W左右，网站每秒请求数达到13000个，规模算是很大了，Lamp（Linux+Apache+MySQL+PHP）结 构，Web2.0网站中钟情PHP的不少，国外的Facebook、Digg、Flickr…，国内的新浪博客、开心网、51.com等等，扩展的不是编程语言而是网站架构，因为编程语言从来都不会是网站瓶颈，每种语言都有自己适合做和不适合做的事情。喜欢比较语言快慢的可以看看 http://shootout.alioth.debian.org/， 看看而已不要用速度去衡量编程语言的优劣。\nDigg的扩展战略：\n扩展 …"

"本篇描述一下 Digg 的网站架构.\n国庆期间又收集了一些关于网站架构的信息。一直没有进行系统的整理。越来越发现其实都是自我重复的劳动，后续的信息都是嚼别人剩下的甘蔗。--by Fenng Digg 工程师采用 LAMP (Linux, Apache, MySQL and PHP) 模式。这个 Alexa 排名在 100 左右的、自我估价 1.5 亿美金的站点目前有超过 100 台的 PC 服务器(足够少了)，可以粗略分成三个部分：数据库服务器，Web 服务器，搜索服务器。\n数据库方面，和其他成功的 Web 2.0 站点一样，也是 MySQL，不过 Digg 稍微”激进”一点，用 MySQL 5，而且号称从 MySQL 4 升级到 5 性能没有什么影响。 OLTP 应用用 InnoDB 引擎, OLAP 用 MyISAM。后端数据库的读比例达到 98%，写只有 2%，实际的读写比例应该高于这个数字，这应该是 Digg 在前端用 Memcached 以及 APC PHP accelerator / MCache 做缓存后的效果。在 IO 上似乎压力并不大。\n数据库分割用 Sharding …"

"很多人都觉得 eBay 在 QCon (北京) 上的技术讲座不错，但对我来说，其实 冲击力没那么大了。eBay 一两年前就是这个 PPT 。不过还是比 Amazon 的 Jeff Barr 强了很多，以后要是开个什么会，你把 Jeff Barr 请来还讲那个销售文档，估计自己都不好意思。\n不过，eBay 这次的PPT 总算还是有点更新的。\n1）数据分片(Partition Everything)\n说是分区(Partition)，这里不能简单等同于 Oracle 的分区，理解成分片(Sharding)就好啦。可以参考一下我以前写的科普小文： 开源数据库 Sharding 技术 (Share Nothing)。这里要强调一下的是，分片是在数据量的确有规模的时候才适合进行，如果单节点足以应付，那么还是不要冒 进。\n从分片的模式上，eBay 主要根据功能切分(Functional Segmentation)和水平分割(负载均衡考虑)，作为推论，所有会话都是无状态性的。\n2）异步处理(Asynchrony Everywhere)\n其实对于任何网站来说，过度追求”同步”化设计还是比较糟糕的做法。以 …"