"最近和几个朋友在谈到时下流行的Web 2.0，也提到了其中最重要的角色——架构师。多方各有争执，不外乎是因为背景和视角的缘故，包括架构一词，本身就从建筑学借鉴而来，至于架构师，则可以 简单地从建筑学的设计师来引申，不外乎就是设计结构，设计一个大楼的结构。回到软件本身，那就可以简单地理解为负责设计软件框架的人了。\n我们没有讨论清楚架构师、软件架构师、系统架构师及其Web 架构师这些看似相同却有所区别的角色的关键，本身智者见智，仁者见仁，也不是一时半会能够说清楚的，最后我们讨论作为一个Web 2.0 网站架构师需要的一些基本的知识和能力，既然是个人看法，难免有失偏颇：\n熟知你的业务模式和目标人群\n这是最重要的，Web 2.0 本质上是以Web 作为平台的业务应用，如果不真正了解你的业务，不了解用户的核心需求，不了解你目标客户的典型行为，是很难做好网站的。从这个角度来讲，一个Web 架构师首先必须是一个出色的产品经理。大多时候，我们只要做到业务技术领先就足够了，一味地追求技术的先进性反倒会深陷泥潭。\n在技术和业务之间找到一个平衡，也就意味着必须明白整个业务核心的竞争力在哪？目标人群基本诉求在 …"

"Evan Weaver 是 Twitter 服务团队的总工程师，他的主要工作是 优化与伸缩性。在 QCon London 2009 上，他谈到了Twitter的架构，特别是在过去一年当中为提升Web站点性能所执行的优化。\nTwitter使用的大部分工具都是开源的。其结构是用Rails作前端，C，Scala和Java组成中间的业务层，使用MySQL存储数据。所 有的东西都保存在RAM里，而数据库只是用作备份。Rails前端处理展现，缓存组织，DB查询以及同步插入。这一前端主要由几部分客户服务粘合而成，大 部分是C写的：MySQL客户端，Memcached客户端，一个JSON端，以及其它。\n中间件使用了Memcached，Varnish用于页面缓存，一个用Scala写成的MQ，Kestrel和一个Comet服务器也正在规划之 中，该服务器也是用Scala写成，当客户端想要跟踪大量的tweet时它就能派上用场。\nTwitter是作为一个“内容管理平台而非消息管理平台”开始的，因此从一开始基于聚合读取的模型改变到现在的所有用户都需要更新最新tweet 的消息模型，需要许许多多的优化。这一改动主 …"

"从20台服务器到5000台服务器，应该说，校内网的IT基础设施的变迁是与其自身的业务发展成 正比的，而每一次的业务突破实际上也是对数据中心的一个挑战。传统的IT基础建设模式，现在、将来又当如何适应SNS类网站的发展？从Csdn记者此次与 校内网技术总监黄晶的对话中，也许我们可以了解一二。 从20台到5000台服务器\n作为校内网的CTO，黄晶对过去几年校内网IT基础建设的过程历历在目。\n“如果要把这个历程分成几个阶段，那么在我看来，校内网的IT基础设施建设目前经历了三个阶段”。\n黄晶对Csdn记者谈到，第一个阶段是校内网创业的阶段，那时候，校内网的主要推广对象是国内比较好的一些高校，但数量很有限，用户数不太多，访问量也不 大，因此，当时选择了一个IDC并租赁了20台左右的服务器。\n“随着业务的发展，校内逐渐把业务覆盖到了全国，与此同时，数据量可以呈现几何式的增大，带宽与存储迎来了瓶颈，因此在那时候，公司开始寻找新的IT基础 架构解决方案，并因此而找到了世纪互联做服务器的托管，几年的时间，服务器的数量从几十台上升到了近5000台。”\n“但问题也随之出现，虽然带宽够大，但是找IDC托管的这种 …"

"要设计良好的架构，必须做到关注点分离，这样可以产生高内聚、低耦合的系统，这是美丽架构的终极原则。\n文 / 王海鹏\n什么是架构？ 每个人可能都有自己对架构的定义。我比较喜欢的定义是：“架构是系统的组成部件及其之间的相互关系。”根据观察者的视角不同，架构 又可以分为业务架构和技术架构。一般来说， 功能性需求会对业务架构产生影响， 而非功能性需求会对技术架构产生影响。\n例如：“注册用户可以向自己的相册上传图片，并与好友分享”。这是一项功能性需求。它告诉了我们在系统的业务架构中，会出现“注册用户”“相册”、 “图片”、“好友”等组成部件，它们之间存在着相互关系。而“系统可以支持10万并发用户，并在需要时可以方便地伸缩，扩展到支持100万到1000万的 并发用户”，则是一项非功能性需求。它告诉了我们系统在性能、负载、吞吐量、可伸缩性方面的特性，目标系统的架构必须对这些特性提供支持。\n架构体现的是对复杂系统的分解设计。而如何进行分解，则是软件设计领域永恒的话题。实际上，架构体现的是关注点分离的原则和方法。经典的三层架构， 由展现层、业务逻辑层和持久层构成；其中体现了我们对用户界面、业务逻辑和数据持 …"

"**Question：**假设一家 C2C 网站，数据库中某表存储买卖双方交易的数据信息，对于一条交易来说，买卖双方数据具有一定程度的耦合性，比如卖家的状态更新对应买家的状态也会更新，对于 一个中大规模的电子商务网站，架构师在设计中如何考虑数据分片的问题（假定该表随着数据的膨胀必须拆分)?\n**Answer：**对于一个中大规模的电子商务网站，随着网站的不断发展，其相应的数据规模会不断膨胀。 数据分片技术 是使网站得 于实现可扩展性的一种常用解决方案。对于 C2C 类型的网站，由于交易记录不容易进行水平的数据分割，因此对于这样的应用处理要再进行细分：\n买卖双方交易的信息，具备较高的时效性，即交易全部完成后就不会再有更新，因此这部分数据可以与正在交易中的数据区分开来，并可以单独分 表，定时归纳。具体的做法可以采用水平分割的数据分片技术，比如可以根据用户号码段范围进行切片，把不同的群体划分到不同的 DB 上，这样可以很好的进行横向水平扩展（Scale Out）。它可以很好的突破单节点数据库服务器的 I/O 能力限制，解决数据库扩展性问题。 对于正在交易中的数据，主要根据时间进行分表。如果分 …"

"与国外大型软件公司相比，在金山，架构师的发展还处于一个学习阶段，我们也正在实践中摸索适合我们的方法。借此机会，我想和大家分享一下WPS项目 中架构师的发展历程和经验教训，共同探讨适合中国软件业的架构师之路。\nWPS项目架构师发展回顾\nWPS项目架构师的发展是随着V6（内部代号，指WPS Office 2005即后续版本）开始的，在此之前，开发团队并没有明确的架构师角色，开发人员在自发的、简单的模块分工交流之后，即开始各自的编码。从2002年下 半年开始，由包括许式伟在内的一个团队开始V6的前期工作。通过半年的原型开发，确定了模块划分和接口。我觉得，这是我们第一次实施由架构师主导的软件开 发过程。\n我是在表格组成为架构师的。在此之前，我在表格组作为核心程序员，负责关键模块的开发。大约一年后，随着软件规模不断扩大，项目组成员不断增多，依 靠程序员自发协调的开发模式开始成为项目瓶颈。再加上我自己的兴趣，于是我开始向架构师方向发展。2004 年，系统架构组成立，正式确立了架构师岗位。大致上WPS的架构师与程序员的比例约为1:10，与管理人员相当。\n架构师的定位和职能\n虽然当前架构师岗位已经非常 …"

"软件架构师是个让人羡慕的职业，在市场经济成熟的国家，其薪酬已经达到医生、律师、注册会计师、建筑设计师的水平。但是薪酬高低与职业成熟度没有直 接的关系。重赏之下必有勇夫，高薪往往造成培养机制不健全的行业出现暂时的良莠不齐。目前我们还没有培养软件架构师的成熟机制，架构师大多是程序员自学成 材。程序员擅长和电脑打交道，却不善于处理工作中的人际关系。然而经验表明，除了技术特长，沟通协作的技巧、领导协调的能力、统筹取舍的经验在指挥开发项 目的过程中起着更重要的作用，而这些内容在计算机学院的课本里压根找不到。刚刚升任软件架构师的人，都有一段时间觉得茫然失措，因为有太多非技术问题困扰 着他们。\n****软件架构师是IT 行业里独一无二的职业，既要精通软件开发技术，又要掌握业务知识，还要周旋于公司不同部门之间，协调各种予盾。做到这些绝非易事， 博文视点 即将翻译出版的新书《软件 架构师应该知道的97 件事》（ 97 Things Every Software Architect Should Know ）探讨的就是这个主题。\n本书的编辑Richard Monson-Haefel 是畅销书《 …"

"本文将讲述MySQL中多种存储引擎的特点，希望可以给你在选择 MySQL存储引擎时带来帮助。\nMySQL有多种存储引擎：\nMyISAM、InnoDB、MERGE、MEMORY(HEAP)、BDB(BerkeleyDB)、EXAMPLE、FEDERATED、 ARCHIVE、CSV、BLACKHOLE。\nMySQL支持数个存储引擎作为对不同表的类型的处理器。MySQL存储引擎包括处理事务安全表的引擎和处理非事务安全表的引擎：\n◆ MyISAM管理非事务表。它提供高速存储和检索，以及全文搜索能力。MyISAM在所有MySQL配置里被支持，它是默认的存储引擎，除非你配置 MySQL默认使用另外一个引擎。\n◆ MEMORY存储引擎提供“内存中”表。MERGE存储引擎允许集合将被处理同样的MyISAM表作为一个单独的表。就像MyISAM一样，MEMORY 和MERGE存储引擎处理非事务表，这两个引擎也都被默认包含在MySQL中。\n注释：MEMORY存储引擎正式地被确定为HEAP引擎。\n◆ InnoDB和BDB存储引擎提供事务安全表。BDB被包含在为支持它的操作系统发布的MySQL-Max二进制分 …"

"MySQL Cluster是MySQL适合于分布式计算环境的高实用、高冗余版本。它采用了NDB Cluster存储引擎，允许在1个Cluster中运行多个MySQL服务器。\nMySQL Cluster是一种技术，该技术允许在无共享的系统中部署“内存中”数据库的Cluster。通过无共享体系结构，系统能够使用廉价的硬件，而且对软硬 件无特殊要求。此外，由于每个组件有自己的内存和磁盘，不存在单点故障。\n总结了些移植到MySQL Cluster要注意的常见问题。\n关于连接\nMySQL集群适合用于高速带宽的环境中，采用TCP/IP方式 连接。它的性能跟主机间的连接速率有直接关系。集群中的最小速率要求是常规的100Mb以太网或者等同的网络。我们建议可能的话就采用G级网络。\n关于内存\nMySQL集群可以运行在任何启用NDB的平台上。显然，CPU 越快，内存越大，对集群性能提升越明显，64位的CPU也可能比32位的处理器更快。每个作为数据节点的机器都必须有足够的内存来保存共享数据库。\n在MySQL 5.0中，集群只能基于内存。意思是所有表的数据(包括索引)都保存在内存中。如果你的数据有1GB那么大， …"

"去年在对 SSD 做调查的时候就关注过这个五分钟法则，今天又发现了这 篇文章的修订版(为了纪念 Jim Gray），这个话题倒是可以简单介绍一下，对架构师衡量 I/O 能力、Cache 评估和做硬件选型还是会有一些帮助的。\n在 1987 年，Jim Gray 与 Gianfranco Putzolu 发表了这个”五分钟法则”的观点，简而言之，如果一条记录频繁被访问，就应该放到内存里，否则的话就应该待在硬盘上按需要再访问。这个临界点就是五分钟。 看上去像一条经验性的法则，实际上五分钟的评估标准是根据投入成本判断的，根据当时的硬件发展水准，在内存中保持 1KB 的数据成本相当于硬盘中存储同样大小数据 400 秒的开销(接近五分钟)。这个法则在 1997 年左右的时候进行过一次回顾，证实了五分钟法则依然有效（硬盘、内存实际上没有质的飞跃)，而这次的回顾则是针对 SSD 这个”新的旧硬件”可能带来的影响。\n随着闪存时代的来临，五分钟法则一分为二：是把 SSD 当成较慢的内存（extended buffer pool ）使用还是当成较快的硬盘（extended disk）使用。小内存页在内存和闪 …"