关键词位置、密度、处理

当前的软件实现是指定一个Map（映射）函数，用来把一组键值对映射成一组新的键值对，指定并发的Reduce（化简）函数，用来保证所有映射的键值对中的每一个共享相同的键组。

映射和化简

简单说来，一个映射函数就是对一些独立元素组成的概念上的列表（例如，一个测试成绩的列表）的每一个元素进行指定的操作（比如前面的例子里，有人发现所有学生的成绩都被高估了一分，他可以定义一个“减一”的映射函数，用来修正这个错误。）。事实上，每个元素都是被独立操作的，而原始列表没有被更改，因为这里创建了一个新的列表来保存新的答案。这就是说，Map操作是可以高度并行的，这对高性能要求的应用以及并行计算领域的需求非常有用。

而化简操作指的是对一个列表的元素进行适当的合并（继续看前面的例子，如果有人想知道班级的平均分该怎么做？他可以定义一个化简函数，通过让列表中的元素跟自己的相邻的元素相加的方式把列表减半，如此递归运算直到列表只剩下一个元素，然后用这个元素除以人数，就得到了平均分）。虽然他不如映射函数那么并行，但是因为化简总是有一个简单的答案，大规模的运算相对独立，所以化简函数在高度并行环境下也很有用。

分布和可靠性

MapReduce通过把对数据集的大规模操作分发给网络上的每个节点实现可靠性；每个节点会周期性的把完成的工作和状态的更新报告回来。如果一个节点保持沉默超过一个预设的时间间隔，主节点（类同Google档案系统中的主服务器）记录下这个节点状态为死亡，并把分配给这个节点的数据发到别的节点。每个操作使用命名文件的原子操作以确保不会发生并行线程间的冲突；当文件被改名的时候，系统可能会把他们复制到任务名以外的另一个名字上去。（避免副作用）。

化简操作工作方式很类似，但是由于化简操作在并行能力较差，主节点会尽量把化简操作调度在一个节点上，或者离需要操作的数据尽可能近的节点上了；这个特性可以满足Google的需求，因为他们有足够的带宽，他们的内部网络没有那么多的机器。

用途

在Google，MapReduce用在非常广泛的应用程序中，包括“分布grep，分布排序，web连接图反转，每台机器的词矢量，web访问日志分析，反向索引构建，文档聚类，机器学习，基于统计的机器翻译……”值得注意的是，MapReduce实现以后，它被用来重新生成Google的整个索引，并取代老的ad hoc程序去更新索引。

MapReduce会生成大量的临时文件，为了提高效率，它利用Google档案系统来管理和访问这些文件。

其他实现

• Hadoop － Apache软件基金会的开放源码项目，提供与MapReduce档案系统类似的功能。

PDCA循环实际上是有效进行任何一项工作的合乎逻辑的工作程序。在质量管理中，PDCA循环得到了广泛的应用，并取得了很好的效果，因此有人称PDCA循环是质量管理的基本方法。之所以将其称之为PDCA循环，是因为这四个过程不是运行一次就完结，而是要周而复始地进行。一个循环完了，解决了一部分的问题，可能还有其它问题尚未解决，或者又出现了新的问题，再进行下一次循环，其基本模型如下图1所示。

PDCA循环有如下三个特点：

1、大环带小环。如果把整个企业的工作作为一个大的PDCA循环，那么各个部门、小组还有各自小的PDCA循环，就像一个行星轮系一样，大环带动小环，一级带一级，有机地构成一个运转的体系。
  
  

2、阶梯式上升。PDCA循环不是在同一水平上循环，每循环一次，就解决一部分问题，取得一部分成果，工作就前进一步，水平就提高一步。到了下一次循环，又有了新的目标和内容，更上一层楼。下面图2表示了这个阶梯式上升的过程。

3、科学管理方法的综合应用。PDCA循环应用以QC七种工具为主的统计处理方法以及工业工程（IE）中工作研究的方法，作为进行工作和发现、解决问题的工具。PDCA循环的四个阶段又可细分为八个步骤，每个步骤的具体内容和所用的方法如下表3所述。
   表3 PDCA循环的步骤和方法

我——作为一名测试人员——有一个与众不同的习惯：每当要加入一个新项目的时候，我总会找到项目中的同伴，真诚而亲切地说：“为了更好地合作，我有5个约定，希望大家能尽量遵守”。

约定1. 业务分析师们，我们其实是同一个角色的两种面孔，请叫上我们参加客户需求会议

我们的团队需要让客户频繁的得到可用的软件，客户的不断反馈会给软件的未来做出最正确的方向指引。

如果我们交付的软件有很多质量的问题，存在大量的缺陷，客户会被这些缺陷的奇怪行为干扰，没有办法把注意力放在软件本身的价值是否符合他们的真正需求上， 不能给出最有价值的反馈。所以，我们只有频繁的做测试，在每次交付之前都把质量问题找出来告诉我们的团队，问题才能及时的得到改正。

而我坚信“prevention is better than cure”（预防胜于治疗），我会要把工作的重点放在预防缺陷上，这样可以节省Dev们很多修复缺陷的时间与精力。

为了达到这个目的，我需要跟你一起参加客户需求会议，尽早的了解客户需求与使用软件的惯常行为。那么在你完成需求的验收条件的定义的时候，我也基本完成了测试用例的准备。

我们可以赶在开发人员们写代码之前就告诉他们我要测什么，让他们减少因为过于乐观而漏掉的一些重要的有破坏性的情况，减少缺陷的发生。这是我测试的一项重要任务。

如果你们在大部分需求都整理好了再交给我们，我会浪费掉等待的时间。更重要的是，开发好的软件里面已经有很多本来可以不存在的缺陷在里面了，开发人员们可能需要加班加点来保证在项目最终交付时间之前把它们改好。这样很容易产生新的缺陷的。

所以，请让我尽早了解需求，请不要让我到项目后期才能开始测试。

约定2. 开发人员们，虽然你们是编写自动化测试的专家，但请听听我们意见

我知道，对于你们，自动化测试不过是利用junit, rspec, selenium，watir，uiautomation等等写出的“另一段程序”而已。而对于80%的QA来说，编写自动化测试并不是一件简单的事情。

不过我仍然相信，有测试人员介入的自动化测试更有价值。

你们用单元测试，集成测试来保证代码的质量。然而你们的这些日常测试离代码更近，离最终用户还点远。很多测试都不是在测软件功能。

你们可以把功能测试写的又快又多，而我们可以指出什么功能测试最有必要加到自动化测试中。

你们平时大部分精力都在编码上，没有太多时间去查都有什么缺陷。而我们可以指出什么地方缺陷可能会出现的比较频繁，建议在这些脆弱的地方加自动化测试。

所以请听听我们的意见，我们可以给你们提供这些信息。

约定3. 项目经理们，请不要要求我们测试软件的所有路径

软件测试是一个永无止尽的任务。基本上没有什么软件简单到我们能够尝试完它的每一个可能的路径的。就连一个看似简单的微软计算器都有无穷尽的路径，无止尽的输入，更何况比这个更复杂的商用软件。

如果你们担心没有尝试过全部的路径不可靠，疑惑我们怎么敢说这个软件质量是好的还是坏，都有什么风险。请你们先注意，我们是跟业务分析师一样，都了解软件的价值的。价值可以帮我们做出判断，什么时候可以停止测试并对客户说我们的软件已经满足您的要求了，请放心使用。

因为我们了解价值，我们可以肯定的说哪些软件的使用方式是至关重要的，哪些是不太可能出现的。我们会在全面测试了软件以后，把主要精力放在价值高的功能点上。合理的利用项目有限的时间。

因为我们了解价值，我们可以正确的把发现的问题分类。我们可以帮助dev们把精力放在重要的缺陷上，避免把时间放在对于客户微不足道却不得不花费大量精力才能修正的问题上。

所以，请不要要求我们无止尽的测试一个软件。我们了解价值，请相信我们的判断。

约定4. 迭代经理们，如果对于交付风险有任何疑问，请来询问我

BA和Dev们都是关注一个软件在什么情况是可以良好的工作。而我们除了验证这些情况以外，大量的时候都用在寻找什么样的情况软件不能正常的运行。所以除 了针对定义好的软件行为进行测试，我们还会做很多探索性测试。我们通常可以通过这样的测试发现一些没有定义的、不曾预期的行为。这些行为往往将会构成软件 交付的风险。

我们会告诉你们现在都发生了什么问题，分别分布在哪里。

我们会告诉你们，在什么情况下软件可能会有异常行为，是不是会牵连到其他的部分，是否可以绕过去。

我们会告诉你们，哪些部分功能比较不稳定，需要更多的留意。

约定5. 测试人员们，那些敏捷实践对于我们也是有用的。

结对不是dev们的专利。我不希望总见到你们独自坐在自己的位置上冥思苦想。走出去，跟其他队友多多交流！

多跟测试队友交流，pair看看设计的测试用例是不是够全面，独自一个人想到的未必足够好。他们会给你诚恳的意见的。对他们，也请一样认真对待。

如果你发现开发人员们做出的架构决定使测试工作变得更困难。那么请大声地告诉他们，design for testability（提高你们设计的可测性）。

如果你发现业务分析师写的需求无法验证，定义的客户行为不够具体，一个用户故事中包含太多了功能点，等等，那么也请大声地告诉他，INVEST（独立，可协商，价值，可估算，短小，可测）。

也请你们多跟开发人员结对写自动化测试，既可以帮助你们学习怎样更好的编写自动化测试，也能帮助开发人员们结对更多的了解用户行为。

这就是我的五个约定，它们是我在团队中顺利展开工作的基础。

        那么，到底什么是架构师呢？所谓的架构师，应该是一个技术企业的最高技术决策者。他主要负责公司软件产品或软件项目的技术路线与技术框架的制订。好的架构师都是善良的独裁者，具有很强的技术、良好的写作能力、良好的口头表达能力，能够在各个层次进行沟通。从开发人员到架构师的成长应该是阶梯式的，一般来讲开发人员在刚刚开始工作时只能开发简单的独立软件模块，慢慢的随着经验的增长，他开始接触一些相互之间有信息传递的模块，而后来，他会发现自己接到的开发任务已经不是一个独立的单体，这些任务由一些专门的软件部分组成，可能包含数据库，工作流引擎，消息服务等等各种功能模块，可能分布在不同的服务器上，所有的部分协同起来，完成软件功能。而这时候，体系结构的好坏将直接决定了系统的性能和可扩展性，而就在这时候，这名优秀的开发人员也开始思考架构师应该思考的问题了，或者说，他向成长为架构师的道路迈出了一大步。

        什么是架构师最具价值的技能呢？就是要了解不同的知识，做一个“杂家”或者说“博学家”。当然，如果你的数据库技术非常棒，或者你在工作流引擎方面具有不可超越的专家知识，那也是很不错的。好的架构师有好多都是从专家成长过来的。但是，这不是架构师应该做的事情，架构师应该做的是了解所有的东西，既了解技术的宏观面，又了解技术的细节。真正的架构师不仅仅要了解软件，也要了解硬件，在关键的部位使用合适的硬件来取代软件，可以成倍甚至成百倍的提高整个系统的效率。下面我将会以互联网行业对的架构师的要求为例，向大家讲解作为架构师应该具备的知识。

        互联网行业是当前最激动人心的行业之一，很多的创新都来自于这个行业，而每一个大型的网站如Google，Yahoo，Myspace等都需要解决一个非常复杂的问题，就是网站的分布式向外扩展(Scale Out)的问题。解决这个问题，需要最优秀的架构师对业务进行剖析，利用软硬件将网站进行重构，甚至根据业务研发相应的分布式技术，解决网站复杂的分布式计算的问题。

        如果你想在这个行业中成为一名架构师的话，需要至少掌握网络知识，硬件，软件，网站优化等方方面面的知识：
网络知识
        当前的软件已经绝对不是那种仅仅跑在一台单机上的孤立应用了。不仅仅是在互联网行业，任何一个行业的软件，都要求其具有网络功能。因此，网络知识是架构师必备的知识。我们所说的网络知识，不仅仅包括TCP/IP，http等互联网行业常用的软件协议，也包括网络规划，甚至更具体的说，根据网站应用所处的地理环境进行网络规划。比如人们常说：“这世界上最远的距离不是生与死的距离，而是电信到网通的距离”（笑）如果应用是建立在中国的，就要考虑电信用户和网通用户访问网站的速度应该都比较快才可以。这时候的解决方案可能有多种，比如采用CDN（Content Delivery Network内容分发网络）使得网站的内容发布到离用户最近的服务器，又可以采用把服务器放在一些所谓的双线机房中，甚至将几种方案结合起来使用。这些都统统归到网络知识中。做为公司的架构师，要对这些知识都有所了解，才有助于在遇到问题时找到最佳答案。
硬件知识
        了解硬件的极限，是架构师的基本功。我见过一些人，他们的眼中软件硬件都是没有极限的，需要资源就申请，系统性能下降了就买更高级的设备。然而，硬件的性能有很大一部分取决于I/O设备。而这些I/O设备依靠的都是机械物理运动，这种运动是有极限的。因此当资源访问量增大到一定的程度时，这种物理运动将成为瓶颈。比如说，在开发网站的过程中，记录访客的状态是一件很重要的事情，一般来说可以使用HttpSession来记录。而HttpSession的存储问题将是一个很大的挑战，尤其是多机共享Session时，将HttpSession存成文件并通过多机共享或网络备份的方式来解决分布式的问题是常用的方案，然而，架构师必须考虑到这种方案是有I/O极限限制的，很难扩展到超过一定规模的大型网络。同时，架构师应该了解目前最近的硬件发展是否对软件系统会造成一定的影响，比如在多核的条件下是否对软件编程有新的要求，是否会对运行在虚拟机和非虚拟机上的程序有影响等等。
软件知识
        软件知识所包含的范围就更加广泛了。对于互联网行业来讲，架构师要了解操作系统，数据库，应用服务器等各方面的知识。比如说，如果网站使用的操作系统是Linux，就要了解这个Linux版本的性能与局限性，比如说最多可以存放的单个文件为多大。有的数据库的数据是以单个文件来存放的，虽然我们很少见到数据库中的数据多到不能再放入一条记录的情况，但是作为架构师，请时刻注意，这种可能性是有的。而且如果你有幸在一家高速成长的互联网企业中，而你所负责的应用又没有经过优化的话，可能你会很快见到这种现象。这种现象的发生可能是由于操作系统不支持大文件的原因，也可能是数据库不支持大文件。不论如何，架构师应该在这种现象发生之前就把一切都准备好。对数据库中表的拆分是架构师应该遇到的另外一个困难。一般来说增加应用服务器比较简单而增加数据库服务器则是比较复杂的问题，如果一个站点由多个数据库支持，架构师需要考虑如何在保证数据一致的情况下，让多个数据库分担压力。有些解决方案是将数据库的读写分开，使得大多数的查询sql不经过核心数据库，而只是访问数据库的副本，但事实上，这种方式也只能维护规模不大的网站。对于大型的网站来说，把业务分散到不同的数据库中，只共享必要的数据，才是合理的提高网站扩展性的解决方案。
其他知识
        作为系统架构师，可能还需要对分布式系统，负载均衡，网络安全，数据监控等等各方面都有所了解。不仅仅是了解理论知识，也要对相关的产品和业界进展有一定的认识。比如说做负载均衡最好的产品是那种。目前最常用的备份策略是什么，有什么缺点。如何使用缓存，如何做好日志分析等等。
        刚刚谈到的是架构师需要掌握的知识，然而，冰冻三尺非一日之寒。这个过程需要我们慢慢的积累。如果你已经进入到公司进行软件开发，请时刻关注你所开发软件的性能与可扩展性，而不仅仅局限在功能上，时刻想着任何一个简单的问题：我开发的模块如果放在多人并发的环境下会怎样，慢慢的就会有所心得。如果你还是一个在校学生，不要想着自己离架构师这个职位还很遥远。要知道，成为架构师的修炼之路是很长的，甚至可以说是终身的，因此早点进入学习状态，不断修炼自己。在学校期间学好离散数学，数据结构，操作系统，编译原理，体系结构，数据库原理等关键课程，并积极寻找机会到外面实习，增长自己的工作经验。如果有机会去到一些技术主导的公司中工作，就一定不要放弃这种机会，慢慢就会成长起来。最重要的，你会养成关注技术，勤于思考的好习惯。当有一天你发现自己对任何技术难题都可以一眼看到其本质，并能够将其分解为一个个可轻松解决的模块，你会由衷的感觉到知识给你带来的快乐，或许那一天，你已经是一个架构师了。