淘宝交易系统用什么语言和架构去设计，又有多少行程式

淘宝架构框架一、个人网站2003年4月7日，马云，在杭州，成立了一个神秘的组织。他叫来十位员工，要他们签了一份协议，这份协议要求他们立刻离开阿里巴巴，去做一个神秘的项目。这个项目要求绝对保密，老马戏称“连说梦话被老婆听到都不行，谁要是透漏出去，我将追杀到天涯海角”。这份协议是英文版的，匆忙之间，大多数人根本来不及看懂，但出于对老马的信任，都卷起铺盖离开了阿里巴巴。他们去了一个神秘的据点——湖畔花园小区的一套未装修的房子里，房子的主人是马云。这伙人刚进去的时候，马云给他们布置了一个任务，就是在最短的时间内做出一个个人对个人（C2C）的商品交易的网站。现在出一个问题考考读者，看你适不适合做淘宝的创业团队。亲，要是让你来做，你怎么做？在说出这个答案之前，容我先卖个关子，介绍一下这个创业团队的成员：三个开发工程师（虚竹、三丰、多隆）、一个UED（二当家）、三个运营（小宝、阿珂、破天）、一个经理（财神）、还有就是马云和他的秘书。当时对整个项目组来说压力最大的就是时间，怎么在最短的时间内把一个从来就没有的网站从零开始建立起来？了解淘宝历史的人知道淘宝是在2003年5月10日上线的，这之间只有一个月。要是你在这个团队里，你怎么做？我们的答案就是：买一个来。买一个网站显然比做一个网站要省事一些，但是他们的梦想可不是做一个小网站而已，要做大，就不是随便买个就行的，要有比较低的维护成本，要能够方便的扩展和二次开发。那接下来就是第二个问题：买一个什么样的网站？答案是：轻量一点的，简单一点的，于是买了这样一个架构的网站：LAMP(Linux+Apache+MySQL+PHP)。这个直到现在还是一个很常用的网站架构模型。这种架构的优点是：无需编译，发布快速，PHP功能强大，能做从页面渲染到数据访问所有的事情，而且用到的技术都是开源的，免费。当时我们是从一个美国人那里买来的一个网站系统，这个系统的名字叫做PHPAuction（他们的官方网站），这个框架易于扩展，方便组件化开发，它的页面模板支持JSP和Velocity等、持久层支持iBATIS和Hibernate等、控制层可以用EJB和Spring（Spring是后来才有的）。项目组选择了这个强大的框架，这个框架如果当时开源了，也许就没有WebWork和Struts2什么事了。另外，当时Sun在全世界大力推广他们的EJB，虽然淘宝的架构师认为这个东东用不到，但他们还是极力坚持。在经历了很多次的技术讨论、争论和争吵之后，这个系统的架构就变成了下图的样子：淘宝架构框架Java应用服务器是Weblogic，MVC框架是WebX、控制层用了EJB、持久层是iBATIS，另外为了缓解数据库的压力，商品查询和店铺查询放在搜索引擎上面。这个架构图是不是好看了一点了，亲？这帮Sun的工程师开发完淘宝的网站之后，又做了一个很牛的网站，叫“支付宝”。其实在任何时候，开发语言本身都不是系统的瓶颈，业务带来的压力的是压到了数据和存储上。上面一篇也说到，MySQL撑不住了之后换Oracle，Oracle的存储一开始在本机上，后来在NAS上，NAS撑不住了用EMC的SAN存储，再然后Oracle的RAC撑不住了，数据的存储方面就不得不考虑使用小型机了。在2004年的夏天，DBA七公、测试工程师郭芙和架构师行癫，踏上了去北京测试小型机的道路。他们带着小型机回来的时候，我们像欢迎领袖一样的欢迎他们，因为那个是我们最值钱的设备了，价格表上的数字吓死人。小型机买回来之后我们争相合影，然后Oracle就跑在了小型机上，存储方面从EMC低端cx存储到Sunoemhds高端存储，再到EMCdmx高端存储，一级一级的往上跳。到现在为止，我们已经用上了IBM的小型机、Oracle的数据库、EMC的存储，这些东西都是很贵的，那些年可以说是花钱如流水啊。有人说过“钱能解决的问题，就不是问题”，但随着淘宝网的发展，在不久以后，钱已经解决不了我们的问题了。花钱买豪华的配置，也许能支持1亿PV的网站，但淘宝网的发展实在是太快了，到了10亿怎么？到了百亿怎么？在N年以后，我们不得不创造技术，解决这些只有世界顶尖的网站才会遇到的问题。后来我们在开源软件的基础上进行自主研发，一步一步的把IOE（IBM小型机、Oracle、EMC存储）这几个“神器”都去掉了。这就如同在《西游记》里面，妖怪们拿到神仙的兵器会非常厉害，连猴子都能够打败，但最牛的神仙是不用这些神器的，他们挥一挥衣袖、翻一下手掌就威力无比。去IOE这一部分会在最后一个章节里面讲，这里先埋个千里伏笔。欲知后事如何，且听下回分解。

可以学习软件测试工程师。
一、市场需求大，人才供不应求
国外企业软件测试与开发人员的配比远高于国内，因此国企要想与外企抗衡，就必须重视软件测试，提高测试与开发的配比，因此未来几年内，国内对于测试人才的需求十分巨大。
二、入门快，薪资高
软件测试行业门槛较低，不限学历和专业背景，只要经过专业的培训，就能够胜任软件测试工作。软件测试人员的起薪是6000~8000元/月，随着经验和年限的积累，薪资还会不断增长。
三、职业寿命长，发展空间广阔
软件测试没有年龄的限制，细心耐心就能胜任，软件测试看重的是经验的积累，反而"越老越值钱"。
四、无性别歧视，就业竞争小
软件测试岗位对性别没有偏好，只要具备经验、认真、耐心、细致、有责任心、沟通能力强就可以胜任。感兴趣的话点击此处，免费学习一下
想了解更多有关软件测试工程师的相关信息，推荐咨询达内教育。该机构已从事多年IT技术培训，累计培养100万学员，并且独创TTS80教学系统，1v1督学，跟踪式学习，有疑问随时沟通。该机构26大课程体系紧跟企业需求，企业级项目，课程穿插大厂真实项目讲解，对标企业人才标准，制定专业学习计划，囊括主流热点技术。

快速原型模型需要迅速建造一个可以运行的软件原型 ，以便理解和澄清问题，使开发人员与用户达成共识，最终在确定的客户需求基础上开发客户满意的软件产品。 快速原型模型允许在需求分析阶段对软件的需求进行初步而非完全的分析和定义，快速设计开发出软件系统的原型，该原型向用户展示待开发软件的全部或部分功能和性能；用户对该原型进行测试评定，给出具体改进意见以丰富细化软件需求；开发人员据此对软件进行修改完善，直至用户满意认可之后，进行软件的完整实现及测试、维护。
模型简述

原型是指模拟某种产品的原始模型，在其他产业中经常使用。软件开发中的原型是软件的一个早期可运行的版本，它反映了最终系统的重要特性。

快速原型模型又称原型模型，它是增量模型的另一种形式；它是在开发真实系统之前，构造一个原型，在该原型的基础上，逐渐完成整个系统的开发工作。快速原型模型的第一步是建造一个快速原型，实现客户或未来的用户与系统的交互，用户或客户对原型进行评价，进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求，开发人员可以确定客户的真正需求是什么；第二步则在第一步的基础上开发客户满意的软件产品。
优缺点

优点：克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险。

这种模型适合预先不能确切定义需求的软件系统的开发。

缺点：所选用的开发技术和工具不一定符合主流的发展；快速建立起来的系统结构加上连续的修改可能会导致产品质量低下。

使用这个模型的前提是要有一个展示性的产品原型，因此在一定程度上可能会限制开发人员的创新。

产生原理

思想的产生

由于种种原因，在需求分析阶段得到完全、一致、准确、合理的需求说明是很困难的，在获得一组基本需求说明后，就快速地使其“实现”，通过原型反馈，加深对系统的理解，并满足用户基本要求，使用户在试用过程中受到启发，对需求说明进行补充和精确化，消除不协调的系统需求，逐步确定各种需求，从而获得合理、协调一致、无歧义的、完整的、现实可行的需求说明。又把快速原型思想用到软件开发的其他阶段，向软件开发的全过程扩展。即先用相对少的成本，较短的周期开发一个简单的、但可以运行的系统原型向用户演示或让用户试用，以便及早澄清并检验一些主要设计策略，在此基础上再开发实际的软件系统。

原理

快速原型是利用原型辅助软件开发的一种新思想。经过简单快速分析，快速实现一个原型，用户与开发者在试用原型过程中加强通信与反馈，通过反复评价和改进原型，减少误解，弥补漏洞，适应变化，最终提高软件质量。
模型类型

探索型原型

这种类型的原型是把原型用于开发的需求分析阶段，目的是要弄清用户的需求，确定所期望的特性，并探索各种方案的可行性。它主要针对开发目标模糊，用户与开发都对项目都缺乏经验的情况，通过对原型的开发来明确用户的需求。

实验型原型

这种原型主要用于设计阶段，考核实现方案是否合适，能否实现。对于一个大型系统，若对设计方案心中没有把握时，可通过这种原型来证实设计方案的正确性。

演化型原型

这种原型主要用于及早向用户提交一个原型系统，该原型系统或者包含系统的框架，或者包含系统的主要功能，在得到用户的认可后，将原型系统不断扩充演变为最终的软件系统。它将原型的思想扩展到软件开发的全过程。

运用方式

由于运用原型的目的和方式不同，在使用原型时也采取不同的策略，有抛弃策略和附加策略。

1、抛弃策略是将原型用于开发过程的某个阶段，促使该阶段的开发结果更加完整、准确、一致、可靠，该阶段结束后，原型随之作废。探索型和实验型就是采用此策略的。

2、附加策略是将原型用于开发的全过程，原型由最基本的核心开始，逐步增加新的功能和新的需求，反复修改反复扩充，最后发展为用户满意的最终系统，演化型快速原型就是采用此策略。

采用何种形式、何种策略运用快速原型主要取决于软件项目的特点、人员素质、可供支持的原型开发工具和技术等，这要根据实际情况的特点来决定。

开发步骤

快速分析

在分析人员与用户密切配合下，迅速确定系统的基本需求，根据原型所要体现的特征描述基本需求以满足开发原型的需要。

构造原型

在快速分析的基础上，根据基本需求说明尽快实现一个可行的系统。这里要求具有强有力的软件工具的支持，并忽略最终系统在某些细节上的要求，如安全性、坚固性、例外处理等等，主要考虑原型系统能够充分反映所要评价的特性，而暂时删除一切次要内容。

运行原型

这是发现问题、消除误解、开发者与用户充分协调的一个步骤。

评价原型

在运行的基础上，考核评价原型的特性，分析运行效果是否满足用户的愿望，纠正过去交互中的误解与分析中的错误，增添新的要求，并满足因环境变化或用户的新想法引起的系统要求变动，提出全面的修改意见。

修改

根据评价原型的活动结果进行修改。若原型未满足需求说明的要求，说明对需求说明存在不一致的理解或实现方案不够合理，则根据明确的要求迅速修改原型。

模型对比

传统的瀑布模型本质上是一种线性顺序模型，存在着比较明显的缺点，各阶段之间存在着严格的顺序性和依赖性，特别是强调预先定义需求的重要性，在着手进行具体的开发工作之前，必须通过需求分析预先定义并“冻结”软件需求，然后再一步一步的实现这些需求。但是实际项目很少是遵循着这种线性顺序进行的。在系统建立之前很难只依靠分析就确定出一套完整、准确、一致和有效的用户需求，这种预先定义需求的方法更不能适应用户需求不断变化的情况。

用户的不断变化的需求具体表现在:

(1)需求是可变的。某些应用软件的需求与外部环境、经营内容等密切相关，因此需求是随时变化的，按照这样预先指定的需求开发软件，当软件开发出来的时候就往往已经过时，不符合用户的需要。

(2)需求是模糊的。对于大多数的应用系统，例如管理信息系统，其需求往往很难预先准确的定义，也就是说，预先定义需求的策略所做出的假设，只对某些软件成立，对多数软件并不成立。许多用户对他们的需求最初只有模糊的概念，想要求一个对需求只有初步设想的人准确无误的说出全部需求，显然是不切实际的。

(3)用户和开发者沟通困难。大多数用户和专业领域的专家不热悉计算机和软件开发技术，软件开发人员也往往不熟悉用户的专业领域，因此，开发人员和用户之间很难做到完全沟通和相互理解，在需求分析阶段做出的用户需求常常是不完整、不准确的。

传统的瀑布模型很难适应需求可变、模糊不定的软件系统的开发，而且在开发过程中，用户很难参与进去，只有到开发结束才能看到整个软件系统。这种理想的、线性的开发过程，缺乏灵活性，不适合实际的开发过程。

而快速原型模型的提出，可以较好的解决瀑布模型的局限性，通过建立原型，可以更好的和客户进行沟通，解决对一些模糊需求的澄清，并且对需求的变化有较强的适应能力。原型模型可以减少技术、应用的风险，缩短开发时间，减少费用，提高生产率，通过实际运行原型，提供了用户直接评价系统的方法，促使用户主动参与开发活动，加强了信息的反馈，促进了各类人员的协调交流，减少误解，能够适应需求的变化，最终有效提高软件系统的质量。

程序员是指从事程序开发、程序维护的专业人员，其又细分为分为程序设计人员和程序编码人员。不知道从何时起，程序员成为“苦逼”的代名词，一些不好的、吐槽性的词汇都能与程序员发生联系。但随着国家大力发展人工智能产业，程序员又在一次被大家重视甚至崇拜起来，毕竟他们可是最有可能成功转型成为人工智能工程师的人。
想要成为一名合格的甚至优秀的程序员可不是件简单的事，需要在大学时期就要努力学习各种计算机、网络、编程等专业知识，当然学校的实力和教学水平也会直接影响毕业生能否在今后的程序员生涯中搏得一席之地。那么中国最盛产程序员的高校有哪些呢？今天笔者就为大家盘点下国内培养程序员最多的十所高校，这也侧面说明了高校在相关领域的实力。

---