从Hadoop到自主研发，技术解读阿里去IOE后的系统架构
浏览次数：437次 CSDN 2014年11月02日字号: 大中小
分享到：QQ空间新浪微博腾讯微博人人网豆瓣网开心网更多0
【导读】互联网的普及，智能终端的增加，大数据时代悄然而至。在这个数据为王的时代，数十倍、数百倍的数据给各个机构带来了无尽的机遇；然而，无可否认的是，数据体积的暴增同样前所未有的挑战着企业的基础设施。
在这个大背景下，各个机构不得不在控制好成本支出的同时，不停摸索着时刻激增用户数据的解决之道，其中阿里的成绩无疑令人艳羡——单集群规模5000+的飞天，以及多集群跨机房计算的支持。本次我们将以飞天为例，为大家分享大规模分布式系统打造过程中的艰难坎坷及应对之道。
本次分享共分为视点、技术专题、应用实践三大板块：“视点”从人物着手细分阿里当时所面临的形势及各个据测制定的依据；“技术专题”主要从实践出发剖析飞天5000节点扩展时所遭遇的艰难险阻及应对之道，涉及架构调整、性能优化、系统运维等多个领域；“应用实践”则更注重于云实践经验及用例分享。
目录
视点
1. 阿里云观察2014
2. 阿里技术保障部：阿里云的幕后英雄
3. 不期而遇的飞天之路
技术专题
探索5K巅峰，云梯架设的飞天之梦。在3个月deadline的情况下，阿里却选择投入更多人力物力及时间的云梯1（以Hadoop为底层的集群）和云梯2（以飞天为底层的集群）并行扩容，阿里人选择背水一战的原因究竟是什么？在这个过程中，他们又会遭遇哪些挑战？目标实现后的惊喜又是什么？
优化无极限：盘古Master优化实践。盘古，飞天的分布式文件系统，在内部架构上盘古采用Master/ChunkServer 结构，Master管理元数据，ChunkServer负责实际数据读写，通过Client对外提供类POSIX的专有API。在集群扩展到5K规模后，相关问题纷至沓来，主要可分为两个部分：首先，盘古MasterIOPS问题；其次，盘古Master冷启动速度。那么究竟是什么造成了这些问题？阿里工程师又该如何应对？
走近伏羲，谈5000节点集群调度与性能优化。伏羲，飞天平台的分布式调度系统。在5K攻坚中，从设计到实现每一步都可能存在性能“陷阱”，原因主要在三个方面：规模放大效应；木桶效应；长路径模块依赖。5000节点后这些方面究竟存在什么样的问题？阿里人又通过了什么方法保证了服务的性能与稳定性？
走近华佗，解析自动化故障处理系统背后的秘密。5K后的运维模式究竟会产生什么样的变化？阿里人究竟为什么会开发华佗？上通飞天系统，下达运维各种系统，华佗健壮、简单和开放的架构究竟表现在什么方面？系统又是如何实现了自动化的运维？
ODPS技术架构及应用实践。ODPS采用抽象的作业处理框架将不同场景的各种计算任务统一在同一个平台之上，共享安全、存储、数据管理和资源调度，为来自不同用户需求的各种数据处理任务提供统一的编程接口和界面。那么，在DT时代，不断扩大的数据规模又会给ODPS带来什么样的挑战？网站日志分析又该如何进行？
ODPS跨集群迁移与数据同步经验分享。阿里各业务部门如淘宝、天猫、一淘、B2B等每天都会产生大量的数据，日均增量数百TB。2013年初，阿里内部的生产集群PA所在机房的存储量最多可扩容到数十PB，而当时已使用75%
的存储量。存储容量告急，迫切需要将生产集群PA上的大量数据迁移到其他集群。那么阿里人该如何安全地跨集群迁移几十PB的数据和其上相关业务？数据迁移之后，两个集群间存在大量的数据依赖，需要互相访问最新的数据，如何安全快速地实现跨集群数据同步？
飞天5K实战经验：大规模分布式系统运维实践。但短时间大规模快速膨胀的现状，给运维带来了巨大挑战，其中云梯2单集群规模更是从1500台升级到5000台。为此，运维需要做多个方向的调整，比如：提升全局掌控能力、实现系统的自我保护和自动化修复、大规模与精细化的平衡。那么，阿里又是通过什么途径完成这些工作的？
应用实践
1. 数据生意背后的云计算
2. 登月1号：支付宝演绎空中升级绝技
3. 御膳房：构建大数据的美食厨房
节选
《不期而遇的飞天之路》——去IOE，飞天势在必行
翻开历史，淘宝曾启用全亚洲最大的OracleRAC集群，阿里更是购买过3年无限制的许可，阿里在IBM小型机以及EMC SAN存储上的投入也曾成为媒体争相报道的事件。但随着互联网爆发式发展，淘宝、支付宝和阿里巴巴B2B 的注册用户数激增，阿里只能不停地通过水平和垂直扩展架构来应对新增用户生成的海量数据。而这种集中式数据库的架构，使得数据库成为了整个系统的瓶颈，越来越不适应海量数据对计算能力的巨大需求，更不用说越来越难以承受的高昂投入。阿里的“去IOE”已经势在必行：通过自主研发的分布式系统取代集中式数据库架构，使用
MySQL+HBase取代Oracle，商用机取代小型机+SAN。
选择自主研发，这也是阿里云在步入云计算之路上做出的最重要的抉择：坚持追求拥有自有的最有竞争力的核心技术。在唐洪看来，云计算是一门高技术门槛的生意，具备核心技术竞争力等于具备了在战场上可以正面抗衡竞争对手的实力，尽管这个技术攻关的历程非常之艰难。选择自主研发而非采用开源Hadoop优化，也是基于一定的考虑，尽管Hadoop在离线大数据处理上具备优势，但无法完全提供阿里云要求的大规模分布式计算与处理的能力，而目前基于飞天上线的云服务，已远远超出Hadoop的能力。开源可以说是一条先易后难的路，尽管一开始可以走一些捷径，但事后在版本升级、研发上都会受颇多限制；从核心知识产权角度来看，今天无论是微软、Amazon或者Google的云计算平台，都没有采用Hadoop且不开放代码开源，本质上都是在追求自有的核心竞争力。开源软件无法彻底成为一个云计算底层平台的基础，采用开源软件并非解决做分布式系统这个问题的一剂良方。发展自有技术，坚持底层自主研发，如今能够构建超级计算机的飞天已成为阿里拥抱云计算，以及对外提供云计算服务的坚实基础。
结语
已经实现5000节点单集群的飞天5K拥有惊人的规模：10万核的计算能力；100PB存储空间；可处理15万并发任务数；可承载亿级别文件数目；100TB排序30分钟完成，远超今年7月1日Yahoo!在Sort Benchmark排序测试Daytona Gray Sort所创造的世界纪录——100TB排序完成时间约71分钟。
优秀的产品背后，必定有优秀的基础设施支撑。在此，我们期望越来越多的团队打造出更加稳定、更具性能的底层平台，不管是自主研发，亦或是基于开源。
阿里云观察2014
发表于2014-10-10 13:28| 11899次阅读| 来源《程序员》| 38 条评论| 作者刘江
《程序员》杂志2014年10月刊阿里云《凌云》云计算
摘要：Amazon云计算对整个新兴产业的发展无疑举足轻重，而国内，阿里云的成败也有类似的分量。2013~2014年，阿里云几乎一直主导着云计算方面的业界话题。
2011年和2012年，我先后两次对话阿里云的负责人王坚博士，并在《凌云》杂志发表了《追寻凌云梦》和《阿里云观察》两篇文章，记录了阿里云和王坚本人不同发展阶段的酸甜苦辣。在后一篇文章的结尾，我这样写道：“全球范围内，Amazon云计算对整个新兴产业的发展无疑举足轻重。对于中国来说，阿里云的成败也有类似的分量。”
我没有想到的是，此后一年多，国内外云计算的形势很快就发生了较大变化。
最引人瞩目的故事，是Amazon在2013年3月获得美国中情局6亿美元的大单，强力攻入企业级市场的核心地带——政府。更有戏剧性的是，IBM为此不惜把中情局告上法庭，仍然未能挽回局面。
而在总体格局上，微软和Google先后放弃只做PaaS的战略，开始在IaaS市场发力，引发一系列连锁反应。2012年6月6日，微软首次公开自己的IaaS服务的时候，还用混合云的名义来遮掩。而同月Google在I/O大会上发布IaaS平台GCE（Google Compute Engine）则高调多了，剑锋毫不客气地直指AWS。等两家IaaS正式上线开放服务，已经到了差不多一年后2013年的4月和5月。总体上，它们比Amazon要晚了5年以上。以至于去年8月Gartner 的数据估计，AWS的计算容量是后面14家竞争对手总和的5倍。
但是，两大巨头毕竟实力雄厚（技术实力毋庸置疑，又握有数以百亿计美元的现金），只要公司顶层下了决心（解决了我所说的“一把手工程”问题），无论产品还是市场上都追得很猛。2014年1月，Google负责基础设施的高级副总裁Urs H?lzle给全公司发出一份令人震惊的备忘录，表示自己的团队将对公司内部包括搜索和Gmail这样的“客户”
减少关注，将大部分精力转向公司以外的新客户，大力打造公共云计算。2014年2月，微软原来负责云业务的Satya Nadella成为新的CEO，他很自然地将云定为公司的两大核心战略之一，Azure无论在产品还是市场力度上陡然加大。
巨头竞争最大的利器，是大把在固定资产上投钱（每年投入在数十亿美元），然后展开血肉横飞的价格战。2014年3月，Google首先发起一轮大规模的降价，各项服务降幅达32%～85%，Amazon第二天就马上跟进，微软的降价通知也不过再等了几天，但后两家的降幅比Google都要小一些。价格战的直接结果是“神仙打架，百姓遭殃”，RackSpace这样的独立云厂商首先撑不下去了：他们拒绝跟进降价，继而在一片收购和私有化传闻中，几个月内的股价跌去一半，不得不在今年5月宣布退出纯IaaS市场，主推绑定服务的托管云。即使是Amazon也开始感到吃力，第二季度的财报发布时，他们的CFO公开承认价格战影响了公司的财务表现，股价也应声而落。
到7月份，一些国外的分析机构和媒体已经在讨论：如果把SaaS加进来，到年底微软的云业务收入会不会超过Amazon？
形势现在很清楚了，在美国，公共云计算市场已经成为巨头的角斗场所。只有既有资源、又有技术实力的公司才能继续生存。Amazon虽然一开始战略对头，选对了从IaaS开始，成为长期的领跑者，至今仍然有较大优势，但Google 和微软一旦发力，这场长途征战，鹿死谁手，还很难预料。三巨头之外，还有哪些公司能拿到所剩无几的船票？Apple、IBM、Facebook、Oracle、Intel、Cisco、EMC/VMware……候选人的名单很长，但胜出的概率却很小了。
国内的情况呢？从某些方面看，与前几年的美国Amazon一马当先，微软和Google还在犹豫，但AWS之上的云生态已经方兴未艾的确非常类似。中国市场上，阿里云的行业领导地位已经基本确立，腾讯云虽然也有比较完整的产品线，但对外似乎并不急于发力，百度云更是一直战略方向都没有定下来，电信运营商和其他较大的IT公司也同样心不在焉。
而各类创业公司则一派欣欣向荣的景象。某种程度上，正是在阿里云不断地通过双十一、余额宝和去IOE等大动作震撼业界、教育市场的东风下，中国云计算生态的确有了很大起色。越来越多的移动游戏、互联网、电商、金融、在线教育、企业软件服务规模性转向云计算。与之相对应的，从2013年1月开始，国内连续出现多起云计算领域投资案例，一扫之前的阴郁，包括IaaS层面的七牛、又拍、QingCloud、UCloud、UnitedStack、道里云、群核、监控宝、云杉网络、多备份、VisualOps、华云数据、刻通云、巨杉等，SaaS层面的Tower、Worktile、明道、纷享、Teambition……以至于常参与讨论的云计算行业微信群里，在我的持续观察之下，除我之外的其他人在一年多的时间里几乎都拿到投资，成了土豪。有些IaaS公司融资高达数千万美元，意味着他们的收入很可能可以达到数千万乃至过亿人民币的水平。
在《阿里云观察》一文中，我曾经说过：“阿里云在国内目前没有真正的对手，2013年将继续享受较长时间的机遇窗口。”事实上，阿里云的确很好地抓住了这个机遇，打了好几个漂亮仗，几乎一直主导着云计算方面的业界话题。
?2013年5月17日，阿里集团最后一台IBM小机在支付宝下线，7月10日，淘宝最后一个Oracle数据库在广告系统中下线，“去IOE”取得关键性成功。与此同时，“去IOE”也引起IT界热议和思考，技术重新选型蔚然成风。
?2013年6月13日，余额宝在阿里云的支撑下推出，一年后用户过亿，规模达到近6千亿，使背后原本默默无闻的天弘基金成为业界领导者，震撼了中国基金业乃至整个金融业，互联网金融成为社会热点。
?2013年11月11日，双十一再创纪录，单日成交额达到362亿，而建构在阿里云之上的聚石塔处理了75%的订单量，无一故障。而双十一巨大的成交量，让零售业感受到了前所未有的变革压力。
?2013年11月27日，代号“聚宝盆”的金融云服务推出，阿里云成为金融行业IT架构的一个新选择。次年5月媒体报道，使用阿里云服务的金融机构超过100家。
?2014年2月27日，阿里与海南签订规划总投资50亿元的“未来城市”计划。此后，阿里云在政务与民生领域的新闻不断地见诸报端：中国气象局、广西、贵州、宁夏、河南、河北……
?2014年3月4日从CDN正式商用起，新的产品和服务也在密集推出，仅在6、7月就连续开放大数据处理服务ODPS、日志服务SLS、搜索OpenSearch、BI服务DPC（采云间）和可用区。
?2014年3月31日，联合高德等推出代号“聚无线”的移动云平台。
?2014年4月29日，北京数据中心开放。5月和9月香港和深圳数据中心又陆续开放，节点总数达到5个。?2014年7月15日，开始免费试用四款入门产品的活动。
?2014年8月19日，发布“云合计划”，要以2:8分成的政策招募1万家云服务商，与之前成立的云栖小镇联盟，组成完整的生态系统。……
2014年5月，阿里巴巴集团的上市招股书中，Cloud一词出现达80多次，显示云计算成为集团非常重要的组成部分。另外，业界也从中得知，阿里云计算等互联网基础设施收入2013年超过1亿美元。虽然量级与美国仍有差距，但也打破了云计算的泡沫之论。近百万用户数量，更是令人鼓舞。
而对阿里而言，这一年多最重要的突破和转折点，却是不太为外界注意的飞天5K项目的成功。
飞天是阿里云的核心系统，它本来的设计目的就是将成千上万台服务器组成一台超级计算机，对外提供通用计算服务。早在2012年初，王坚就表示，“从战略上来说，他们（阿里云）想做的事情实际上可以解读为Amazon+Google并有所超越”。将单一集群做到数千乃至更高，技术上是国家和企业竞争力的标志。阿里云必须攻克这道难关。只不过，2009年才起步的飞天，一直没有机会冲击这一目标。
2013年，这个机会来了。一季度做预算的时候，大家发现，阿里集团内部数据处理的两套系统——基于Hadoop的云梯1和基于飞天的ODPS（云梯2）随着单集群规模不断扩大，都到了几千，面临5000集群规模和跨机房的门槛。如果分别继续投入、重复建设，开发和维护成本很高，浪费巨大，必须舍弃一个。怎么办？
当时技术团队内部的争论非常厉害，甚至当着马云的面也不掩饰。Hadoop作为大数据的标志性开源项目，本身更加成熟，在技术人员心目中地位很高，感情很深，而且Hadoop集群的规模本身更大。但是可控性、安全性的问题可能更会在长期成为过不去的坎儿。阿里技术保障部负责人刘振飞的一句话透出了这场争论背后的本质：“Hadoop的定位就是陪太子读书，而太子就是ODPS。”飞天5K项目因此启动，一方面ODPS往5K规模升级，另一方面Hadoop 不再发展，处理负荷向ODPS迁移。
以唐洪为首的飞天核心研发团队历经4个月艰苦努力，对盘古、伏羲等组件进行了深入优化，并全新开发了自动故障处理模块华佗（细节可以参考本期凌云的相应的文章）。到2013年8月15日，这个任务胜利完成，新的基于飞天5K的ODPS生产集群规模达到5000，而且实现了跨机房，并经受了整机房断电的严苛考验。平台计算100TB排序只需30分钟，远超Yahoo! 在7月刚刚创造的71分钟世界纪录。阿里成为世界上屈指可数的具备这一能力的公司之一，也是第一个对外提供这种能力的公司。多年来，中国在前沿性的关键技术上少有地站到了世界领奖台上。
从各方面看，飞天5K都是阿里云乃至阿里巴巴历史上重要的里程碑。到今天，支付宝的所有数据处理、淘宝的数据仓库、阿里小贷的贷款业务等越来越多的集团关键应用，都已经由ODPS和飞天5K支撑。据刘振飞透露，阿里云终于借此在集团内部证明了自己。在此之后，阿里内部关于做不做云计算、到底用Hadoop还是用ODPS，甚至王坚和阿里云靠谱不靠谱的争论都结束了。飞天5K项目为此画上了一个休止符。此后，阿里云作为集团的统一技术平台，已经成为上上下下的共识。最近，几千台的HBase集群也在往OTS上迁移。淘宝、天猫、支付宝的负责人，现在已经主动提出，要将核心系统迁移到阿里云提上日程。
在这背后，集团副总裁王文彬（花名菲青）在2014年初接任阿里云总裁，他原在淘宝天猫负责开放平台与商家业务，技术和生态建设背景均很资深，而且他领军的聚石塔是之前淘宝系基于阿里云所做的最重要的项目之一，对阿里云也有比较深的了解。同时，以集团副总裁章文嵩、传奇技术专家蔡景现（花名多隆的他刚刚成为阿里集团的合伙人）等为代表的许多原淘宝系技术精英也进入阿里云，负责主要产品的研发，大大增强了阿里云的技术实力。2014年9月原Oracle全球副总裁喻思成加盟，以集团副总裁出任阿里云技术业务总经理。再加上以刘振飞为首的猛将如云的阿里技术保障部在基础设施和运维的全力支持（参见本期文章《阿里技术保障部：阿里云的幕后英雄》）。至此，阿里云的阵容空前强大。
2013年9月，在王坚卸任阿里云总裁的消息发布之后，媒体有各种不明内情的解读。10月阿里云开发者大会，在会场附近的绿地上，我和其他云栖小镇联盟的成员一起见证了飞天5K纪念碑的揭幕仪式，王坚非常动情地张罗着众多还在阿里云或者已经离开的同事一起与刻着大家名字的纪念碑合影。我知道，这个纪念碑其实主要是王坚自己与小伙伴们几年在云计算核心技术自主研发上筚路蓝缕的阶段性总结，他的云计算之路远没有结束。此后，由于有了更多强有力的帮手，他得以从具体业务抽身，更多地将精力转到云计算和大数据战略思考、客户沟通与布道上，在更大的范围内发挥自己的影响。
事实上，王坚自己一直认为，阿里自己的业务用不用阿里云，对阿里云而言并不是最重要的事情。阿里云要成为全社会的通用计算平台，这个难度无论从技术还是服务上，比支撑阿里内部要大得多。只不过阿里云如果做得好，阿里内部也会用，这是一个附带的成果。这一年来，他与各种类型的客户交流，感触很深。他说，无论是政府、金融还是中小企业，一旦转到云计算，所能释放出来的创新能力，远远超出了他的想象，经常令他心潮澎湃。而客户对云计算的态度很大程度上已经转变，越来越多人对云计算是乐于接受的。反过来，云平台的挑战也越来越大。这么多客户要用，
你的能力够不够，你接不接得住？就拿铁道部网站的问题来说，这其实不完全是政府相关部门的问题，更多的是围绕铁道部的那些企业的问题。很多事情解决不好，中国的企业不能老是赖政府，企业也有自己的责任。云计算企业要尽快提升自己的能力，否则很多客户会不得不去做一些不正确的事情，比如大规模地自行建设数据中心，用非常传统的技术架构。“最怕的事情是，五年后专家们不断呼吁要扶持国产云计算。” 王坚说自己经常有时不我待的紧迫感。
与此呼应，王文彬在介绍阿里云工作重点时说，今年的主要目标是在提升既有产品稳定性和体验、推出更为丰富的新产品的基础上，扩大阿里云的影响和市场份额，提升阿里云的口碑。产品和服务都是重中之重。他希望与更多合作伙伴一起提升用户体验。
云计算本身似乎存在一个悖论，就是为了竞争和扩大规模，必须不断降价，而这又会最后使平台自身无利可图。Amazon最近的财务表现似乎证明了这一点。微软的云负责人在阐明自己优势时，说的是除了云平台本身的收入之外，微软还有其他软件授权收入，言下之意也是云计算本身不太挣钱。这也是许多其他巨头尤其是主营业务利润率比较高对此看不清楚，而迟迟没有真正投入的重要原因之一。
对此王坚表示，现在关于云计算还是有很多似是而非的认识。一方面，阿里、淘宝平台还有公共电力行业的发展历史，都证明了平台本身最后能够成为大生意，而且并不困难。由于杰文斯效应（Jevons effect），技术的进步会增加对技术的消费量，只要到了一定的规模，盈利是迟早的事情。另一方面，我们实际上已经从IT（信息技术）进入到DT（数据技术）时代，互联网+数据取代了计算机+软件，云计算是将更多行业乃至全社会数据化的平台和前提，它的价值不只是平台本身的盈利，而更在于作为基础设施，将数据的价值释放出来。这个意义要大得多。最近的几次谈话中，他举了非常多让自己感动和惊讶的云计算用户案例。“用户用阿里云在做的事情，才是阿里云的价值所在。”他举例说，美国电力科学研究院（EPRI）的数据表明，一部iPad如果每天完全充电一次，一年所耗费的电费只有1.5美元，而用户拿它去干的事情则不知道会多么伟大。王文彬也非常强调阿里云上推出ODPS这种大数据服务的意义，这也是阿里云目前的重要特色之一。
从很多方面来看，中国的云计算发展有可能超越美国。由于阿里等互联网公司积极向各行业渗透，具有比美国同行更大的影响力，加上国内许多公司的IT系统并不成熟，全社会又具有改革惯性，完全有可能直接跨越一个阶段，基于云计算平台构建新的核心IT系统。这既是阿里云及其同行的机遇，也是重重的责任。
阿里技术保障部：阿里云的幕后英雄
发表于2014-09-27 10:48| 8365次阅读| 来源未知| 0 条评论| 作者刘江
阿里云
摘要：阿里集团上市前夕公布的最新27名合伙人名单中，出现了公司副总裁、技术保障部负责人刘振飞的名字。这当然既是对他个人的认可，也是对阿里技术保障部这一幕后英雄团队贡献的肯定。阿里集团包括阿里云、天猫、淘宝、支付宝、小贷在内的各项业务，以及近几年双十一、飞天5K等诸多奇迹的背后，这...
阿里集团上市前夕公布的最新27名合伙人名单中，出现了公司副总裁、技术保障部负责人刘振飞的名字。这当然既是对他个人的认可，也是对阿里技术保障部这一幕后英雄团队贡献的肯定。阿里集团包括阿里云、天猫、淘宝、支付宝、小贷在内的各项业务，以及近几年双十一、飞天5K等诸多奇迹的背后，这个团队都发挥了关键性的基础支撑作用。
然而，不仅外界听说过阿里技术保障部的人不多，就连我虽然与刘振飞已经相识多年，对他们团队的具体情况以及与阿里云的渊源也只是一知半解。近日我终于找到一个机会，在杭州和他好好聊了一上午。
阿里技术保障部的故事，要从2009年8月说起。今天的用户可能难以想象，当时淘宝网非常不稳定，动不动就访问不了，或者要停机维护，搞得领导们很生气很无奈。以至于当时淘宝的总裁陆兆禧感慨，淘宝2008年全年成交额是999.6亿，要是少宕几次机，就过千亿了啊。刘振飞说：“你想，当一个公司的CEO天天在琢磨这种事，就说明技术平台上真是出大问题了。”9月25日，为了解决淘宝系统的问题，成立淘宝技术保障部，将阿里妈妈和淘宝的运维、数据库等工作和团队合并，当时正在北京负责淘宝广告（阿里妈妈）技术团队的刘振飞被领导点将，负责组建这支团队。
阿里集团副总裁、技术保障部负责人刘振飞
刘振飞搬到杭州真正进入角色，已经到了2009年的11月2日，此后很长时间内，他和团队都处于救火队的状态，几乎每天大概都要处理几十起紧急情况。但更大的挑战却是阿里妈妈和淘宝两个运维团队的合并并不那么顺利。“你要知道是两套体系，两套人合起来，人的观念不一样，大家经历不一样，习惯不一样，工具不一样，什么都不一样。合起来真是非常痛苦的过程。”刘振飞甚至夸张地说这一经历给自己留下了不小的心理阴影。
而每年的双十一对刘振飞团队的成长帮助巨大。2009年第一个双十一销售额只有5000万，对系统影响不大，连刘振飞也是在活动要结束前半小时收到淘宝商城负责人逍遥子（张勇）的邮件才知道的。一年后的第二个双十一却是淘宝技术保障部经历的一次大挑战。由于业务部门事先估算的成交量2.5亿偏低（实际达到了9.36亿），系统准备不足，整个活动期间都如履薄冰，走在崩溃的边缘，曾经一度就要实施降级方案，限制部分宝贝图片的显示了。所幸，
最后系统经受住了考验。2011年刘振飞决定不再盲从业务部门的预估，而是从技术角度做足准备。这一年还创立了由各部门技术骨干组成技术保障总指挥部、预先大规模压力测试、大量演习和详细的应急预案等流程和机制，很好地保证了总销售额从不到10亿到52亿、191亿和362亿的逐年飞跃。
2011年还有两件事儿至关重要。一是6月淘宝一分为四，除淘宝网、淘宝商城（后改名天猫）、一淘三个业务部门外，还有一个不太为外界注意到的阿里技术与公共服务共享平台。对此，刘振飞分析，当时的拆分可能是马云和王坚等集团高层想将公司技术底层统一起来，贯彻One Company战略的开始。后来，这个共享平台的技术部分改名为阿里集团技术保障部。
另一件事是刘振飞团队与阿里云运维的合并。由于上次合并的痛苦回忆，加上当时公司内外对阿里云有很多争议，刘振飞对这事起初并不积极，拖过了双十一之后，又有双十二，眼见着就往春节后拖了。可是阿里云的运维负责人道夫很主动，而且提出了很具体的方案，他的那句“这方案你听完以后，你爱怎么合怎么合”感动了刘振飞。双方很快达成了一致，合并总体也非常顺利。技术保障部发展到今天，涵盖业务运营（包括合作创新、标准化和知识产权），性能与容量（架构、性能、容量、优化），系统研发（网络平台、网络产品、SDN、服务器研发、无线技术、数据引擎、算法平台等），供应链管理（ODM管理），数据库（MySQL、OceanBase、SQLServer和RDS），平台与工具（工具、流程、监控、自动化、配置、研发协同平台、硬件管理平台），平安生产，系统运营和云PE等多个方面，猛将如云，而且同时具有运维的经验和自主研发的实力。
刘振飞还透露了一个鲜为人知的细节，因为对阿里云心里没底，在接手前他私下直接问过马云本人对阿里云到底是什么态度，我是全力去干，还是说应付应付就完了。当时马云是这么回答的：在王坚加入阿里之前，我跟教授（指曾鸣）讨论公司的未来，觉得云计算和大数据代表未来，对国家、民族、社会的发展有长远的意义，所以我们要干，这是第一点。但是怎么做云计算大数据？我们谁也不知道。现在来了个人叫王坚，他说我知道怎么做，为什么不支持呢？这是第二点。第三点，即使万一做失败了，那也没关系，咱们的人倒下70%，还有30%活着，咱们活下来的人继续打扫战场，换个方向继续干，总要把它做出来。
有了老大的这种明确表态，刘振飞心里清楚该怎么做了。“云计算是公司战略，什么叫战略？战略就是公司一定要干，理解了执行，不理解你也要执行。”
接下来2012年的头几个月，他连续得罪了两个人。一个是负责阿里金融的孙权（胡晓明）。他们是阿里云的第一个重要内部客户。但是由于阿里云的产品当时仍不太成熟，问题很多，孙权找到刘振飞，表示不想用阿里云了，要改用淘宝的体系，让技术保障部来支持。刘振飞本着云计算是公司战略的精神，拒绝了这一要求。同时，阿里云和技术保障部专门抽调技术骨干组成团队，驻扎到滨江办公区为阿里金融提供贴身服务。最终获得了他们的认可。
下一个被得罪的，是时任淘宝副总裁的菲青（王文彬）。他为了上聚石塔项目（电商开放平台），来找刘振飞谈技术保障方面的事情，也是不愿意用阿里云，要用淘宝技术体系，同样吃了闭门羹。“我当时说如果用淘宝体系的话你自己找人去玩儿，要用云计算，我全力顶你。我就是这样非常粗暴地利用手中职权强迫大家往战略方向上去走。”刘振飞笑着说。
2012年的双十一，阿里云支撑聚石塔完成全部订单20%的处理，成为云计算的一大亮点。集团外部也有CCTV5的网上直播、浙江台风预警系统等出色的案例。
但阿里云最终真正证明自己，还是2013年的事情。除了依靠阿里云迅速成长为基金业土豪的余额宝之外，飞天5K 项目具有决定性的意义。
事后总结，飞天5K这个项目并非人为规划而是逐步发展出来的，其中有几个历史节点很关键。第一个关键点就是去IOE，虽然去IOE最开始是王坚提出来的，但与云计算没有直接关系，可是做着做着就发现殊途同归了。去IOE内部的争议也非常大，但做到最后，大家发现这是一个有利于国计民生的大事。第二个关键点是2010年我们自己研发的海量关系数据库OceanBase立项，现在已经成为整个公司的基础数据库，包括支付宝交易和账务系统所用的Oracle，很多应用所用的MySQL，最终都会转到OceanBase上。第三个关键点是2010年的双十一，技术保障部的组织和双十一的保障流程建立起来了。然后的关键节点就是飞天5K项目，之后内部通过登月计划，正在争先恐后地将原有的数据处理平台全部迁移到基于飞天5K的ODPS上。最先动手的登月一号是支付宝，已经完成了。接下来的关键点还有今年ODPS的对外发布，外部客户现在所用的基础设施和内部支付宝、淘宝所用的，已经是完全一样的了。
刘振飞说，更长远地来看，5K这个项目将在阿里巴巴历史上留下很重的一笔。在此之后，阿里技术团队内部停止了争论，原来做两摊事儿不时竞争的人，兵合一处，并肩作战。与之对应的，是阿里云的口碑越来越好，网上能见到的吐槽也越来越少。马云后来说过一句话，他说飞天、ODPS和云OS这三个东西，是我们阿里巴巴要重心打造的重武器或者核武器，这是我们的技术的核心，一定要搞好。
刘振飞透露，最近淘宝系的负责人也向他表示，已经在认真考虑核心系统上云的问题了。内部对云计算达成共识之后，刘振飞和阿里技术保障部基于几年的实战经验，对云计算本身和自己要承担的责任与面临的挑战，做了全面思考。关于他们的思考结果和计划，我们留给下一期。
刘振飞其人
刘振飞这个名字，可能外界并不太熟悉。其实，对于技术圈，尤其是《程序员》杂志的老读者和CSDN网站的资深网友来说，刘振飞并不陌生。他是河南鲁山人，却有点山东大汉的意思，个子很高，性格直率。1996年获得北京大学硕士学位，C++程序员出身，曾在微软Office组任程序经理。早在2004年，他就因BugFree这款开源软件受到广泛关注。2005年《程序员》杂志从第1期开始连续三期刊出了对他的访谈《Bug管理的经验与实践》，第8、9期又连载了他撰写的《网站项目成功管理实践》。这一系列细论软件和互联网研发管理经验的文章广为流传，产生了很大影响。2007年和2008年两届SD 2.0大会，刘振飞又成为演讲嘉宾，这时他已经成为淘宝广告团队的技术总监。2009年，他受命组建淘宝技术保障部，后发展为整个阿里集团的基础技术支撑部门。2014年成为阿里27名合伙人之一。
不期而遇的飞天之路
发表于2014-09-27 11:07| 2731次阅读| 来源未知| 1 条评论| 作者郭雪梅，童阳
飞天5K阿里云
摘要：2006年Amazon推出S3服务，揭开了以分布式存储和大规模计算为标志的云计算的面纱。阿里一直关注并在思考着如何来做云计算。2008年，王坚博士加入阿里，阿里正式成立云计算公司，并决定自主研发大规模分布式计算系统——“飞天（Apsara）”。
2006年Amazon推出S3服务，揭开了以分布式存储和大规模计算为标志的云计算的面纱。阿里一直关注并在思考着如何来做云计算。2008年，王坚博士加入阿里，阿里正式成立云计算公司，并决定自主研发大规模分布式计算系统——“飞天（Apsara）”。
2009年春节后上班第一天，阿里云团队在北京上地一间简陋的连空调都没有的办公室写下第一行代码。
而彼时，在大洋彼岸，唐洪刚从北美第四大搜索公司https://www.doczj.com/doc/9211544905.html,跳到美国雅虎，正在埋头于大规模分布式计算系统Hadoop。当王坚博士在美国硅谷偶遇唐洪并初次介绍“飞天”时，唐洪对王坚博士说了一句大实话：“开发飞天这件事，完全不靠谱。”就连王坚博士后来也坦承：“我觉得他是对的，世界上没有人会觉得这个事情靠谱，因为它很难。”
时光总爱开玩笑。一年以后，唐洪遭遇了事业发展中的巨大挑战——“2010年的时候雅虎在Hadoop上的投入也在逐渐减少，而当时雅虎已经确定了把所有与数据相关的业务和处理都搬到Hadoop上。越来越繁重的业务压力，让程序员们为支持线上系统疲于奔命。所以我们有很多好的想法，都无法实现。”需要重构职业路线：是放弃自己执着多年的东西去一些新领域尝试新的技术挑战，比如当时在硅谷火热的社交网络Startup；还是加入一家真正有决心和坚持的公司去共同攀登大规模分布式计算系统的技术巅峰？
而此时，尽管相对Google、微软、Amazon这些分布式底层已经比较成熟的企业而言，阿里才刚刚起步，但阿里云的决心却已让“飞天”有了更大的成长空间。
一通漫长的越洋电话之后，2010年，唐洪离开硅谷，正式加盟阿里云，并带领美国、杭州、北京多个团队，肩负起阿里云计算整个技术底层的研发，成为刚刚两周岁还处于雏形阶段的飞天
技术负责人。对于这一选择，唐洪曾如此解释：“世界上除了Google、微软和Amazon，就只有阿里了，我找不到第五家公司能有决心长期投入在自主研发大规模分布式系统上。”
去IOE，飞天势在必行
阿里的IT基因中，开始植入云计算，伴随着一场“去IOE”运动的进行。
翻开历史，淘宝曾启用全亚洲最大的OracleRAC集群，阿里更是购买过3年无限制的许可，阿里在IBM小型机以及EMC SAN存储上的投入也曾成为媒体争相报道的事件。但随着互联网爆发式发展，淘宝、支付宝和阿里巴巴B2B 的注册用户数激增，阿里只能不停地通过水平和垂直扩展架构来应对新增用户生成的海量数据。而这种集中式数据库的架构，使得数据库成为
了整个系统的瓶颈，越来越不适应海量数据对计算能力的巨大需求，更不用说越来越难以承受的高昂投入。阿里的“去IOE”已经势在必行：通过自主研发的分布式系统取代集中式数据库架构，使用MySQL+HBase取代MySQL，商用机取代小型机+SAN。
选择自主研发，这也是阿里云在步入云计算之路上做出的最重要的抉择：坚持追求拥有自有的最有竞争力的核心技术。在唐洪看来，云计算是一门高技术门槛的生意，具备核心技术竞争力等于具备了在战场上可以正面抗衡竞争对手的实力，尽管这个技术攻关的历程非常之艰难。选择自主研发而非采用开源Hadoop优化，也是基于一定的考虑，尽管Hadoop在离线大数据处理上具备优势，但无法完全提供阿里云要求的大规模分布式计算与处理的能力，而目前基于飞天上线的云服务，已远远
超出Hadoop的能力。开源可以说是一条先易后难的路，尽管一开始可以走一些捷径，但事后在版本升级、研发上都会受颇多限制；从核心知识产权角度来看，今天无论是微软、Amazon或
者Google的云计算平台，都没有采用Hadoop且不开放代码开源，本质上都是在追求自有的核心竞争力。开源软件无法彻底成为一个云计算底层平台的基础，采用开源软件并非解决做分布式系统这个问题的一剂良方。发展自有技术，坚持底层自主研发，如今能够构建超级计算机的飞天已成为阿里拥抱云计算，以及对外提供云计算服务的坚实基础。
目标5K，突破再突破
理想有多么美好，挑战就有多么巨大。在技术上，唐洪把自主研发大规模分布式系统飞天的挑战概括为三点。
第一，小概率事情变成常态，主要包括故障率放大、故障类型不可预知及线上诊断修复不可避免；第二，昂贵的全局同步代价，Jim Gray在1996 SIGMOD的论文里指出，竞争代价是规模
增长的三次方，因此，10节点集群扩展到1000节点，同步代价有可能放大百万倍，这就意味着两点——性能关键路径上需要避免全局同步，并与不精准的全局状态达成妥协；第三，动态的运行环境，这个问题主要是基于线上业务，由互联网应用的爆发式增长、服务器负载的周期性变化，及系统热点的无时不在和瞬时转移特性导致。
迎难而上，是突破再突破。2008年10月24日，组建飞天团队开始做设计；2009年12月18日，飞天有了第一个应用——为阿里金融做的大规模离线处理；2010年8月24日，飞天成功地支持搜
索、邮箱、大规模数据处理、弹性计算存储等服务；2011年7月28日，阿里云自主研发的飞天云计算平台开始以公共服务的方式对外提供云计算商业服务；同年，首届阿里云开发者大会上，
基于飞天的阿里云开放服务产品体系全面亮相；2013年3月，飞天单集群规模已达1500台；2013年8月15日，飞天5K成功，承载着阿里巴巴集团数据业务的“开放数据处理服务（Open DataProcessing Service，简称ODPS）”集群正式开始生产运营，单集群规模达到5000台。
在实现单集群5000节点之后，通过上层应用ODPS，飞天已经支撑了阿里内部大部分数据业务，其中包括阿里小贷、数据魔方、阿里妈妈广告联盟、广告搜索、点击预测模型训练、支付宝所有业务、淘宝指数、阿里无线等。2014年7月，以RESTful API方式提供数据仓库、数据挖掘和其他数据应用服务的ODPS，正式对外开放。今天，已有近百万应用部署在阿里云平台上面，客户遍及全国不同地域、不同行业领域。
取得一系列技术突破的背后，是不为人知的一场艰难的历程，其中更大的困难在于人。召集一群能够做这件事的人难，而召集一群能耐住寂寞为梦想实现而甘于奉献的人更难，无数难题让飞天人吃尽苦头。回想一路的历程，唐洪说：“当飞天第一天立项、从第一行代码开始，便是带着明知山有虎，偏向虎山行的决绝和勇气前进的。而这一路不仅仅有阿里巴巴集团的研发人员在投入这场战斗，还有更多的是我们的客户、合作伙伴的支持，才能走到今天5K的目标。2013年10月25日，杭州转塘阿里云创业创新基地专门为飞天5K设立了纪念标志，我们在这个标志上不仅留下了在项目室小黑屋封闭开发的程序员、赶着早高峰下班的开发运维人员的名字，也有每个周末都赶来陪同加班的家属，更有把身家性命放在阿里云上的客户的名字，其实从另一个维度来说，因为有了他们才有了今天的5K。”
未来，腾飞的阿里云计算
飞天5K的正式上线，也标志着阿里与Google、微软和Amazon比肩，从此成为世界上独立拥有相关技术能力的屈指可数的公司之一。
未来，唐洪看得更远：“目前飞天所支撑的业务占有市场份额还不足1%，接下来的路还很漫长且艰辛。着眼未来，
5K只能是飞天已经迈过的一道门槛，是阿里云一个新的起点。”
有一种追求叫自主研发！相信唐洪和这群有理想、有信仰的年轻人们在这片更加广阔的天空中能够更加自由地翱翔！
探索5K巅峰，云梯架设的飞天之梦
发表于2014-09-27 11:19| 2030次阅读| 来源未知| 2 条评论| 作者郭雪梅，童阳
阿里云飞天5K
摘要：5年的时间，飞天平台从1500台的集群规模到3000台的集群规模，再到2013年8月，飞天开放平台最终成功实现单集群超越5000台、同时支持多集群跨机房计算的目标。
IDC研究显示，包含结构化和非结构化的大数据正在以每年60%的增长率持续增长，到了2020年全球数据总量将增长44倍，达到35.2ZB。而着眼国内，2013年产生的数据总量已经超过0.8ZB，两倍于2012年，相当于2009年全球的数据总量。预计到2020年，中国产生的数据总量更可能超过8.5ZB。井喷的数据在给各个机构带来数不尽机遇和财富的同时，也在存储、计算、带宽等领域给企业带来无尽的挑战。拥有数亿注册用户的阿里巴巴感受最明显——2013年3月28日，一封来自技术保障部架构师的邮件直达阿里集团最高层：
“按照数据增量与未来业务增长的情况，云梯1（以Hadoop为底层的集群）系统存储和计算能力将在6月21日到达瓶颈，数据业务将会停滞，淘数据、量子等业务都会受到影响；而云梯2（以飞天为底层的集群）也有同样的问题，阿里金融的贷款业务将因为无法进行信用数据运算而中止。”
对任何企业而言，服务压力上涨都是幸福的烦恼。而到了阿里这样的规模，不管是幸福还是烦恼都被放大了无数倍。对于大规模分布式离线存储和计算集群来说，如果原有集群不能通过简单的增添主机来增加存储空间和计算能力，横向扩展遭遇不可逾越的瓶颈，就代表着系统重构的开始。此时，摆在阿里面前只有两个选择：第一，直接扩容云梯1，从成熟度、稳定性、项目的复杂程度、投入力量来看，这条路安全有效，但基于飞天的云梯2同样岌岌可危；第二，同时扩容云梯1和云梯2，扩容后两个数据系统的单集群规模都将达到5000台，实现跨机房集群处理，但3个月的deadline和巨额的人力、物力投入同样不容忽视。
面对只有不到3个月的实施时间，这道选择题变得异常艰难——是高效地选择尽快到达“安全地带”，还是在兼顾“安全”的同时，投入大量人力、物力，选择一次史无前例的“突破”？
意料之中，也是意料之外，阿里毅然选择了“背水一战”：云梯1和云梯2同时并行扩容！
扩容不可阻挡
事实上，无论是从规划理念、技术发展，还是从集群规模来看，飞天扩容的最佳时机已经到来。
回顾飞天的历史。2009年，自投身云计算，阿里云就立志要自主研发出以“飞天”为代号的大规模分布式计算系统。飞天的设计宗旨就是通过构建一套综合性的软硬件系统，将数以千计的服务器连成一台“超级计算机”，并最终实现两个目标：对内，通过对这台超级计算机进行物理资源分配、程序运行操控，以及保障服务及数据安全的操作系统，支撑阿里集团服务的核心技术平台；对外，将这台超级计算机的计算、存储等资源，以公共服务的方式，输送给互联网上的用户或者其他应用系统。云梯的元老级创建者罗李（花名鬼厉）曾表示，之所以起名云梯，项目组建时就被定义
为阿里云计算平台的铺路者，寓意奉献。而着眼飞天，这个项目无疑承载了阿里的云计算愿景，从第一行代码被写下时就意义非凡。
5年的时间，飞天平台从1500台的集群规模到3000台的集群规模，再到2013年8月，飞天开放平台最终成功实现单集群超越5000台、同时支持多集群跨机房计算的目标。
放眼全球，能做到这一点的企业，屈指可数。
诸神实现飞天之梦
飞天，是亲近水的一位神的名字，是可以为人们带来幸福和吉祥之神。和飞天一样，系统中的各个模块也被赋予了上古诸神的名字：分布式文件系统是开天辟地承载一切基础之神——盘古（Pangu）；负责任务调度和资源管理模块的是占卜和预测之神——伏羲（Fuxi）；从底层上监视和处理导致集群性能下降的集群诊断系统——华佗（Huatuo）；负责网络连接的模块——夸父（Kuafu）；监控系统——神农（Shennong）；集群部署——大禹（Dayu）……以诸神之名，映射出的是背后的理想主义色彩。
众神协作下，飞天负责管理数据中心Linux集群的物理资源，控制分布式程序进行，并隐藏下层故障恢复和数据冗余等细节，有效地提供弹性计算和负载均衡的服务。而数千节点规模下，无论是系统的打造还是扩容都面临着众多技术挑战，在5K扩容过程中，平台的各个模块在规模性能、高可用以及可运维性等方面都做了大量的改进和优化。
■ 盘古，在内部架构上盘古采用Master/ChunkServer结构，Master管理元数据，ChunkServer负责实际数据读写，通过Client对外提供类POSIX的专有API。在集群扩展到5K规模后，相关问题纷至沓来，主要可分为两个部分：首先，盘古MasterIOPS问题，因为更大的集群意味着更多文件和更多访问，上层应用对存储亿级文件和十亿级文件集群的IOPS是有显著区别的。同时更大规模的集群让快速发展的上层应用看到了更多可能性，导致更多业务上云，存储更多数据，也间接导致了对IOPS的更高需求。此前盘古Master较低的IOPS已经限制了上层业务的快速扩张，业务高峰期时有告警，亟待提升。另外一个规模相关问题就是盘古Master冷启动速度，更多的文件和Chunk数导致更长的冷启动时间，影响集群可用性。在具体的性能优化上，主要工作有克服锁瓶颈、优化架构（包括Pipeline优化和Group Commit），以及不断深入细节反复尝试以解决规模导致的冷启动时间过长，详情请阅读《优化无极限：盘古Master优化实践》。
■ 伏羲，飞天平台的分布式调度系统。在5K攻坚中，从设计到实现每一步都可能存在性能“陷阱”，原因主要在三个方面：规模放大效应，当节点数增大到数千个时，系统中原本不是瓶颈的与规模成正比的环节，其影响会被放大；木桶效应，未经优化的那一小部分很可能成为影响系统性能的致命的瓶颈；长路径模块依赖，被依赖模块性能的不稳定性最终会影响某个请求处理的性能和稳定性。为此，阿里从通信、关键函数、模块依赖等多个方面进行了优化，详情参阅《走近伏羲，谈5000节点集群调度与性能优化》。
■ 华佗，运维的模式随着5K的到来发生了很大的改变，在解决实际问题的过程中，华佗应运而生，上通飞天系统，下达运维各种系统。其架构足够健壮、简单和开放，PE可以很方便地将自己丰富的运维经验转换成华佗的插件。华佗可以针对各种异常情况，进行故障磁盘管理还有系统异常处理，PE也可以通过它做流程和管理自动化的工作。同时，不必再做几分钟的快速人工修复，而是当故障设备积累到一定量后批量地做替换，大量地节省了人力成本。当下华佗已经运用到磁盘管理、机器管理、网络故障检测等多个场景，更多详情可关注《走近华佗，解析自动化故障处理系统背后的秘密》。
■ 当运维的服务器达到数千台甚至上万规模机器的时候，必然会遇到诸多挑战，如硬件配置的差异化，用户数和任务数的急剧膨胀，大压力下的边界效应，小概率事件被触发等。在这个前提下需要做好快速部署，自动化运维、监控报警、Log分析、精细化计量等需求会越来越迫切。在这些方面，阿里付出了更多的心血以保证业务稳定和安全的运行，详情可见《飞天5K实战经验：大规模分布式系统运维实践》。
当飞天第一个五千台规模集群——飞天5K正式投入运营时，所承载上线的服务即是ODPS。以底层大规模分布式系统的性能优化和运维保障为基础，支撑起了更上层的平台——Open Data Processing System，开放数据处理服务。
ODPS谱写飞天5K应用
ODPS和飞天的关系，可以追溯到更早的时候。
2010年春节，ODPS的前身SQL Engine第一版上线，运行在当时30台机器的飞天集群上。2011年1月，由于业务上需要支持更多数据模型，SQL Engine被重构，命名为Data Engine数据仓库发布上线，稳定运行在100台机器上。但是，Data Engine 0.2支持的数据量还远不满足需要，而且它的稳定性还有待提升。2011年Q3，飞天团队开始探索支撑集团内部数仓业务，利用莫邪（Moye）系统，在1500台机器上并行运行云梯1的生产作业，并取得了不输于Hadoop的性能和稳定性成绩。2012年Q1，团队在Data Engine和莫邪之间做技术选择，并决定使用莫邪作为
ODPS产品的核心引擎，Data Engine退出历史舞台。飞天5K项目之后，ODPS随之进入5000台机器和跨机房调度时代。作为飞天的重要模块，它不仅仅得到了扩容，而且还进一步实现了跨集群的数据复制，详情见《ODPS跨集群迁移与数据同步经验分享》。
ODPS远不只是一个简单的大数据平台，功能包括SQL，基于Java的MapReduce编程框架，图计算编程模型，一系列机器学习算法的实现等。所有的功能是以RESTful API的形式对外提供，从系统边界上说，这层API隔离了ODPS 平台和用户的系统，和Hadoop的区别也很明显。ODPS设计之初就是为了对外开放，做基于互联网的多租户的公共数据处理服务，所以安全性在ODPS的设计和实现中具有最高的优先级。ODPS作为离线数据处理平台，许多新的技术也是第一次应用到5K项目，并且经受了准生产环境的检验，同时也为未来数据业务长期发展打下了坚实的基础。目前在阿里集团内部已经被广泛用于海量结构化数据的处理分析，帮助阿里集团将业务实践沉淀的海量数据进行提炼分析，从而让数据诞生新的价值。《ODPS技术架构及应用实践》一文中对这些内容有更详细的讲述。
期待更多飞天精神
时至今日，已经实现5000节点单集群的飞天5K拥有惊人的规模：10万核的计算能力；100PB存储空间；可处理15万并发任务数；可承载亿级别文件数目；100TB排序30分钟完成，远超今年7月1日Yahoo!在Sort Benchmark 排序测试Daytona Gray Sort所创造的世界纪录——100TB排序完成时间约71分钟。
飞天5K不仅成为阿里集团最为重要的技术平台，而且集群中的计算、存储等能力已经完全以云服务的方式在对外输出。这意味着“云计算可以让一个人的公司，跟一个很大的公司，站在同一条起跑线上竞争”。
飞天5K，不仅是阿里云计算技术发展的一个里程碑，同时也将注定在中国云计算技术发展的历史中留下浓墨重彩的一笔。展望中国云计算产业的将来，期待有更多像飞天一样的技术，也期待有更多像飞天一样，百折不挠的精神。
优化无极限：盘古Master优化实践
浏览次数：82次 CSDN 2014年10月22日字号: 大中小
分享到：QQ空间新浪微博腾讯微博人人网豆瓣网开心网更多0
盘古是一个分布式文件系统，在整个阿里巴巴云计算平台——“飞天”中，它是最早被开发出的服务，因此用中国古代神话中开天辟地的盘古为其命名，希冀能创建出一个全新的“云世界”。在“飞天”平台中，它是负责数据存储的基石性系统，其上承载了一系列的云服务（如图1所示）。盘古的设计目标是将大量通用机器的存储资源聚合在一起，为用户提供大规模、高可用、高吞吐量和良好扩展性的存储服务。盘古的上层服务中，既有要求高吞吐量，期待I/O能力随集群规模线性增长的“开放存储”；又有要求低时延的“弹性计算”，而作为底层平台核心模块的盘古必须二者兼顾，同时具备高吞吐量和低时延。
图1 飞天整体架构图
在内部架构上盘古采用Master/ChunkServer结构（如图2所示），Master管理元数据，多Master之间采用Primary-Secondaries模式，基于PAXOS协议来保障服务高可用；ChunkServer负责实际数据读写，通过冗余副本提供数据安全；Client对外提供类POSIX的专有API，系统地提供丰富的文件形式，满足离线场景对高吞吐量的要求，在线场景下对低延迟的要求，以及虚拟机等特殊场景下随机访问的要求。
图2 盘古简明架构图
自5K项目以来，集群规模快速扩张到5000个节点，规模引发的相关问题纷至沓来。首当其冲的就是盘古Master IOPS 问题，因为更大的集群意味着更多文件和更多访问，显然上层应用对存储亿级文件和十亿级文件集群的IOPS是有显著区别的。同时更大规模的集群让快速发展的上层应用看到了更多可能性，导致更多业务上云，存储更多数据，也间接导致了对IOPS的更高需求。此前盘古Master较低的IOPS已经限制了上层业务的快速扩张，业务高峰期时有告警，亟待提升。另外一个规模相关问题就是盘古Master冷启动速度，更多的文件和Chunk数导致更长的冷启动时间，影响集群可用性。
要解决上述问题，性能优化势在必行。但对于盘古这样复杂的大型系统，不可能毕其功于一役，需要在不同的阶段解决不同的性能瓶颈。优化通常会伴随整个生命周期，因此优化工作本身也需要进行经验、工具等方面的积累，为后续持续优化提供方便。因此在这次规模问题优化中，我们积极建设了自己的锁Profile工具，并依此解决了多个锁导致的性能问题；在解决主要的锁瓶颈后，我们进行了架构上的优化，包括Pipeline优化和Group Commit优化，取得了良好效果；最后我们通过对细节的不断深入，反复尝试，较好地解决了由规模导致冷启动时间过长的问题。
工具篇
在盘古这样复杂的大型系统上，锁是优化过程经常遇到的问题。优化的首要任务是找出具体瓶颈，切忌猜测和盲目修改代码。先用压测工具对盘古Master加压，通过Top、Vmstat等系统工具发现CPU负载不到物理核的一半，Context Switch高达几十万，初步怀疑是锁竞争导致。同事也觉得某些路径下的锁还有优化空间，但到底是哪些锁竞争厉害？哪些锁持有的时间长？哪些锁等待时间长？具体又是哪些操作需要这些锁？由于缺少切实可靠的数据支撑，不能盲目下手，而坚持数据说话是一个工程师应有的品质。
盘古Master提供了众多的读写接口，内部的不同模块使用了大量的锁，我们需要准确得知是哪类操作导致哪个锁竞争严重，此前常用的一些Profile工具难以满足需求，因此我们有必要打造自己的“手术刀”——锁分析工具，方便后续工作。
首先为了区分不同的锁，我们需要对代码中所有的锁进行统一命名，并将命名记录到锁实现内，同时为了区分不同的操作，还需要对所有的操作进行一个唯一的类型编号。在某个Worker线程从RPC中读取到具体请求时，将类型编号写入到该Worker线程私有数据中，随后在该RPC请求的处理过程中，不同锁的拿锁操作，都归类于该操作类型。
在每个锁内部，维护一个Vector数据，LockPerfRecord记录锁的Profile信息，具体定义如下：
每个操作对应Vector中的一个元素，线程私有数据中记录的操作编号即Vector下标。整体来看形成了表1中的稀疏二维数组，空记录表示该操作未使用对应锁。
表1 操作类型与锁统计示意表
具体实现上，Acquire Counts采用原子变量，时间测量上采用Rdtsc。谈到Rdtsc有不少人色变，认为有CPU变频、多CPU之间不一致等问题，但在长时间粒度（分钟级）和大量调用（亿次）的压测背景下，这些可能存在的影响不会干扰最终结果，多次实验结果也证实了这一点。其他实现细节，如定时定量（每n分钟或者每发起x次操作）发起不影响主流程的Perf Dump就不再赘述。整个代码在百行左右，对平台的侵入也很小，仅需要为每个锁添加一个初始化命名，在RPC处理函数的入口设定操作编号即可。
利器在手，按图索骥，对存在性能问题的锁进行各种优化。例如使用多个锁来替换原来全局唯一锁，减少冲突概率；减少加锁范围；使用无锁的数据结构，或者使用更轻量级的锁来优化。整个优化过程极富趣味性，经常是解决一个锁瓶颈后，发现瓶颈又转移到另外一个锁上，在工具的Profile结果中有非常直观的展示。先后优化了Client Session、Placement等模块中锁的使用，取得了显著的效果，CPU基本可以跑满，Context Switch大幅度下降，整个过程酣战淋漓。
架构篇
在锁竞争问题解决到一定程度后，继续进行锁的优化就很难在IOPS上取得较大收益。此时结合业务逻辑，我们发现可以从架构上做出部分调整，以提升整体的IOPS。
读写分离（快慢分离）
整个盘古Master对外接口众多，根据是否需要在Primary和Secondaries之间同步Operation Log来分成读和写两大类。所有读操作都不需要同步Operation Log，所有的写操作基于数据一致性必须同步。考虑到Primary和Secondaries随时都可能发生切换，要保证数据一致，Client端发送的每一个写请求，Primary必须在同步Operation Log完全成功后才能返回Client。显而易见，写比读要慢得多，如果让同一个线程池来同时服务读和写，将会导致什么结果？一个形象的隐喻是多车道的高速公路，如果一条高速公路上不按照速度来划分多车道，而是随心所欲地混跑，20码和120码的车跑在同一条车道上，整体的吞吐量无论如何也不会高。参照高速公路设计，进行快慢分离，耗时低的读操作占用一个线程池，耗时高的写操作使用另外一个线程池，双方互不干扰，进行这样一个简单的切分后，读IOPS得到显著提升，而写操作并未受影响。
Pipeline
读写分离后，读的IOPS性能得到极大提升，但写操作依然有待提升。写操作的基本流程如图3所示。
图3 写操作基本流程图
在Master端，写操作最大的时间开销在同步Operation Log到Secondaries。这里的关键缺陷在于同步Operation Log 期间，工作线程只能被动地等待一段相当长的时间，这个过程包括将数据同步到Secondaries上，并由Secondaries 将这个数据同步写入到磁盘，由于涉及到同步写物理磁盘（而非写Page Cache），这个时间是毫秒量级。所以写操作的IOPS肯定不会高。定位问题后，在结构上稍做调整如图4所示。
图4 写操作Pipeline简要流程图
类似中断处理程序，整个RPC的处理流程分成了上半部和下半部，上半部由Worker线程处理Request，将Operation Log提交到Oplog Server，不再阻塞等待同步Oplog成功，而是接着处理下一个Request。下半部的工作包括填充Response，将Response写入到RPC Server ，下半部由另外一个线程池承担，通过Oplog 同步成功的消息触发。这样Worker线程源源不断地处理新的Request，写操作IOPS显著提升。由于只有同步Oplog完全成功才会返回Response，所以数据一致性与此前的实现相同。
Group Commit
经过Pipeline优化后，写操作性能显著提升，但我们对结果依然不太满意，想进一步提升IOPS，为上层客户提供一个更好的结果。继续Profile，发现新实现下同步Oplog吞吐量较低，主要原因是每个写请求都导致一次主备间同步Oplog，而且这条Oplog在Primary和Secondaries上都需要同步写到磁盘。压力较高时，将有大量的同步RPC和小片数据同步写磁盘，导致吞吐量低。通常分布式系统会使用Group Commit技术来优化这个问题，将时间上接近的Oplog组成一个Group，整个Group一次提交，吞吐量可以明显提升。但传统的Group Commit会带来Latency的明显增加，需要在吞吐量和Latency之间做权衡。鱼与熊掌如何兼得？我们对Group Commit过程进行了适当优化，较好地解决了这个问题。
将组Group和同步Group分离，前者由一个Serialize线程承担，后者由Sync线程完成。Serialize线程作为生产者，Sync线程作为消费者，两者通过一个队列来共享数据，当Serialize线程发现队列中大于M个Group等待被同步的时候，将暂停组新的Group；而当Sync线程发现队列中等待的Group小于N个的时候，将唤醒Serialize线程组新的Group，由于Serialize线程经过了一段时间的等待，积累了一批数据，此时可以组成更大的Group，同时又不会造成Latency的提升。当整个系统负载低的时候，队列为空，Serialize无需等待，Latency很低；当系统负载较高的时候，队列中有堆积，此时暂停Serialize，也不会增加额外的Latency，而且随后可以组成较大的Group，获得高吞吐量收益。通过对Serialize和Sync操作的压力测试，可以确定最优化的M、N值。
细节篇
专注细节，做深做透对一个大型复杂系统而言尤为重要。在整个优化过程中，我们遇到很多富有趣味性的细节问题，经过深入挖掘后，取得了良好成果。其中具有代表性的一个例子就是Sniff的深入优化。
在5K项目前，盘古Master冷启动时间以小时计，5K后由于规模扩张，Chunk数剧增，冷启动时间会更长。冷启动时，需要做Sniff操作，获取所有ChunkServer上Chunk的信息（Chunk的数量在十亿数量级），将这些信息汇聚到几个Map结构中，在多线程环境下Map结构的插入和更新必须锁保护。通过锁工具Profile也证实瓶颈就在锁保护的Map上。所以缩短启动时间就转化为如何对锁保护的Map进行读写性能优化这样十分具体的细节问题。为减少锁竞争，调整结构如图5所示。
图5 Sniff优化示意图
引入一个无锁队列，所有的工作线程将数据更新到无锁队列，随后由单一线程从无锁队列中批量更新到Map，调整后Sniff期间Context Switch从40万降低到4万左右，耗时缩减到半小时，效果显著。但我们依然觉得过长，继续深挖，发现此时CAS操作异常频繁，而且单一的更新线程已经占满一个核，继续优化感觉无从下手了，此时回过头来研究业务特点，看看能否根据业务特点来减少某些约束。功夫不负有心人，最终我们发现了一些非常有趣的细节，即在Sniff阶段，我们基本不读取这些Map，只在Sniff完成后，第一个写请求的处理过程中需要读取Map，这意味着只要Sniff完成后Map结果保证正确即可，而在Sniff过程中，Map更新不及时导致的不准确是可接受的。根据这个细节，我们让每个工作线程在TSD（线程私有数据）中缓存一个同类型的Map，形成图6中的结构。
B/S架构的企业应用软件系统结构设计 一、需求概述: 系统实现以下功能：手工输入由各办事处报来的日、月销售报表，由系统生成月销售明细，该销售明细可以分别按客户、月份进行查询；同时生成各办事处的销售数量、金额汇总（月）、平均单价（按品名）；按各办事处的人员登记日记帐，可按人员汇总生成汇总帐（包括各项费用）；根据月销售明细生成包括收款金额和费用（该费用可手工修改），每笔账款可根据客户总金额从销售明细查询来源；根据销售回款额、销售成本和费用进行自动统计和损益分析，生成销售回款额、销售成本、毛利、本月费用汇总，得到本月纯利累计，并可查询回款明细；对库存（包括成品和原材料库存）的管理，包括出、入库操作，库存查询，根据手工输入的本月入库和本月出库的各个产品的数量结合上月结存由系统自动生成本月结存，其中本月入库包括公司发货和客户退货，本月出库包括客户、赠送及样品和退回公司。 二、运行环境: 1．硬件设备 运行该软件所需要的设备及其规格，包括： ?具有奔腾III、64兆内存配置的计算机 ? Microsoft鼠标或其它兼容鼠标 ?最少800MB的硬盘空间 ?VGA显示器或更高 ?一般计算机外设，如：打印机、扫描仪。如要配置网络环境，还需网络连接设备 2．支持软件 ?服务器操作系统：中文Windows98、Window 2000或更高、IIS ?通讯接口要求安装TCP/IP协议 ?数据库：SQL Server 2000 ?客户端软件：IE5.0及以上版本 三、处理流程 销售、财务部分：
库存部分： 四、软件结构 主要包含以下功能模块： 1.销售模块：手工输入由各办事处报来的日、月销售报表，由系统生 成月销售明细，该销售明细可以分别按客户、月份进行查询；同时 生成各办事处的销售数量、金额汇总（月）、平均单价（按品名）。 2.财务处理模块： 1)日记帐：按各办事处的人员登记，可按人员汇总生成汇总帐（包 括各项费用）； 2)编制应收账款明细表：根据月销售明细生成包括收款金额和费 用（该费用可手工修改），每笔账款可根据客户总金额从销售 明细查询来源； 3)编制损益表：根据销售回款额、销售成本和费用进行自动统计 和损益分析，生成销售回款额、销售成本、毛利、本月费用汇
企业应用架构的演进
企业应用架构是指一整套软件系统的构建，通过合理的划分和设计组合在一起，支持企业方方面面的经营运作。不论是传统企业，还是互联网公司，发展到一定阶段，都需要一整套体系化的应用架构来支撑其运转。良好的、合理的应用架构可以支持企业高效开展业务，控制经营风险，而混乱的、不合理的应用架构则会限制企业的快速发展，成为企业增长与变革的瓶颈。 企业信息化建设已经发展了几十年，传统企业和成熟互联网企业的应用架构并没有本质的区别。本文将通过一个线下小型门店成长为多元化集团的发展历程，逐步向读者展示企业应用架构的演变和设计的理念。完整的企业架构（EA，Enterprise Architecture）分析构建，包括业务架构、应用架构、技术架构、数据架构，本文聚焦应用架构，更加关注软件系统设计与公司经营管理的关系。不论是C端产品经理或者B端产品经理，理解应用架构的建设思路，能够帮助你更轻松的理解公司的业务运转，以及各个系统存在的目的与你所负责工作在整体团队中的定位和价值。 传统企业的应用架构演变1. 小门店的Excel管理之路 我们将从一个最简单的案例入手，来展开故事。假设你是一名个体经营者，在小区中开了一家小门店，售卖居民常用的生活用品。门店不大，只有十几平米，平常由你一个人负责经营管理，包括采购，摆货，销售。为了更准确、科学的打理你的生意，你设计了一个Excel文件来管理你的商品与销售数据。实际上你只需要做三张表格，第一张表格存储了你的货品信息，第二张表格存储了你的采购记录，第三张表格存储了你的销售记录。这三张标的结构和关系如下图所示。下图采用了ER模型来描述三张表的逻辑结构，*和1的含义是表和表之间的关联关系，例如采购记录和商品信息是多对一关系，即采购记录表中的每条数据只能对应商品信息表中的一条数据，商品信息表中的一条数据可以对应采购记录表中的多条数据。
很详细的系统架构图--专业推荐 2013.11.7
1.1.共享平台逻辑架构设计 如上图所示为本次共享资源平台逻辑架构图，上图整体展现说明包括以下几个方面： 1 应用系统建设 本次项目的一项重点就是实现原有应用系统的全面升级以及新的应用系统的开发，从而建立行业的全面的应用系统架构群。整体应用系统通过SOA面向服务管理架构模式实现应用组件的有效整合，完成应用系统的统一化管理与维护。 2 应用资源采集 整体应用系统资源统一分为两类，具体包括结构化资源和非机构化资源。本次项目就要实现对这两类资源的有效采集和管理。对于非结构化资源，我们将通过相应的资源采集工具完成数据的统一管理与维护。对于结构化资源，我们将通过全面的接口管理体系进行相应资源采集模板的搭建，采集后的数据经过有效的资源审核和分析处理后进入到数据交换平台进行有效管理。 3 数据分析与展现 采集完成的数据将通过有效的资源分析管理机制实现资源的有效管理与展现，具体包括了对资源的查询、分析、统计、汇总、报表、预测、决策等功能模块的搭建。 4 数据的应用 最终数据将通过内外网门户对外进行发布，相关人员包括局内各个部门人员、区各委办局、用人单位以及广大公众将可以通过不同的权限登录不同门户进行相关资源的查询，从而有效提升了我局整体应用服务质量。 综上，我们对本次项目整体逻辑架构进行了有效的构建，下面我们将从技术角度对相
关架构进行描述。 1.2.技术架构设计 如上图对本次项目整体技术架构进行了设计，从上图我们可以看出，本次项目整体建设内容应当包含了相关体系架构的搭建、应用功能完善可开发、应用资源全面共享与管理。下面我们将分别进行说明。 1.3.整体架构设计 上述两节，我们对共享平台整体逻辑架构以及项目搭建整体技术架构进行了分别的设计说明，通过上述设计，我们对整体项目的架构图进行了归纳如下：
软件系统的架构设计方案 架构的定义 定义架构的最短形式是：“架构是一种结构”，这是一种正确的理解，但世界还没太平。若做一个比喻，架构就像一个操作系统，不同的角度有不同的理解，不同的关切者有各自的着重点，多视点的不同理解都是架构需要的，也只有通过多视点来考察才能演化出一个有效的架构。 从静态的角度，架构要回答一个系统在技术上如何组织；从变化的角度，架构要回答如何支持系统不断产生的新功能、新变化以及适时的重构；从服务质量的角度，架构要平衡各种和用户体验有关的指标；从运维的角度，架构要回答如何充分利用计算机或网络资源及其扩展策略；从经济的角度，架构要回答如何在可行的基础上降低实现成本等等 软件系统架构(Software Architecture)是关于软件系统的结构、行为、属性、组成要素及其之间交互关系的高级抽象。任何软件开发项目，都会经历需求获取、系统分析、系统设计、编码研发、系统运维等常规阶段，软件系统架构设计就位于系统分析和系统设计之间。做好软件系统架构，可以为软件系统提供稳定可靠的体系结构支撑平台，还可以支持最大粒度的软件复用，降低开发运维成本。如何做好软件系统的架构设计呢？ 软件系统架构设计方法步骤 基于体系架构的软件设计模型把软件过程划分为体系架构需求、设计、文档化、复审、实现和演化6个子过程，现逐一简要概述如下。 体系架构需求：即将用户对软件系统功能、性能、界面、设计约束等方面的期望（即“需求”）进行获取、分析、加工，并将每一个需求项目抽象定义为构件(类的集合)。
体系架构设计：即采用迭代的方法首先选择一个合适的软件体系架构风格(如C/S、B/S、N层、管道过滤器风格、C2风格等)作为架构模型，然后将需求阶段标识的构件映射到模型中，分析构件间的相互作用关系，最后形成量身订做的软件体系架构。 体系架构文档化：即生成用户和研发人员能够阅读的体系架构规格说明书和体系架构设计说明书。 体系架构复审：即及早发现体系架构设计中存在的缺陷和错误，及时予以标记和排除。 体系架构实现：即设计人员开发出系统构件，按照体系架构设计规格说明书进行构件的关联、合成、组装和测试。 体系架构演化：如果用户需求发生了变化，则需相应地修改完善优化、调整软件体系结构，以适应新的变化了的软件需求。 以上6个子过程是软件系统架构设计的通用方法步骤。但由于软件需求、现实情况的变化是难以预测的，这6个子过程往往是螺旋式向前推进。 软件系统架构设计常用模式 目前软件领域广泛使用的软件系统架构模式，主要有层次化架构设计、企业集成架构设计、嵌入式架构设计和面向服务的架构设计模式。 层次化架构设计模式：分层设计是一种最为常见的架构设计方案，能有效地使系统结构清晰、设计简化。MVC模式是当今最为流行的多层设计模式。该模式把一个应用的输入、处理、输出流程进行分离并抽象为控制器(Controller)、模型(Model)、视图(View)三个模块，实现了业务逻辑层、数据库访问层和用户界面层
软件系统架构图-参考案例
————————————————————————————————作者：————————————————————————————————日期： ?
各种软件开发系统架构图案例介绍
第一章【荐】共享平台架构图与详细说明 1.1.【荐】共享平台逻辑架构设计 (逻辑指的是业务逻辑） 注:逻辑架构图－－主要突出子系统/模块间的业务关系, 这里的逻辑指的是业务逻辑如上图所示为本次共享资源平台逻辑架构图,上图整体展现说明包括以下几个方面： １应用系统建设 本次项目的一项重点就是实现原有应用系统的全面升级以及新的应用系统的开发,从而建立行业的全面的应用系统架构群。整体应用系统通过ＳOＡ面向服务管理架构模式实现应用组件的有效整合，完成应用系统的统一化管理与维护。 2 应用资源采集 整体应用系统资源统一分为两类，具体包括结构化资源和非机构化资源。本次项目就要实现对这两类资源的有效采集和管理。对于非结构化资源，我们将通过相应的资源采集工具完成数据的统一管理与维护。对于结构化资源，我们将通过全面的接口管理体系进行相应资源采集模板的搭建,采集后的数据经
过有效的资源审核和分析处理后进入到数据交换平台进行有效管理。 3数据分析与展现 采集完成的数据将通过有效的资源分析管理机制实现资源的有效管理与展现，具体包括了对资源的查询、分析、统计、汇总、报表、预测、决策等功能模块的搭建。 4数据的应用 最终数据将通过内外网门户对外进行发布，相关人员包括局内各个部门人员、区各委办局、用人单位以及广大公众将可以通过不同的权限登录不同门户进行相关资源的查询,从而有效提升了我局整体应用服务质量。 综上，我们对本次项目整体逻辑架构进行了有效的构建，下面我们将从技术角度对相关架构进行描述。
企业信息系统架构 This manuscript was revised by the office on December 22, 2012
企业信息系统架构 图1清晰的展现了我们企业在信息化建设的成果。并且,这些应用系统在各自服务的生产领域内提高了生产效率,提升了服务质量,同时也为决策层提供了可靠、准确的决策数据。 1 问题描述 以上各应用系统系我企业最初始的应用系统架构。由于各个应用系统是根据生产和管理需要逐步建立起来的,在投用初期并未体会到各个应用系统合理架构的重要性和必要性。在众多系统正式上线投用的时候,问题逐一暴露出来,下面列举最关键性问题: 不能完成“一站式”系统登录 通常一个用户需要使用多个应用系统,从图1的设计架构来看,需要对同一用户进行多个系统单独授权。这不仅可能需要用户记住很多的登陆账号,而且必然造成用户多次登陆才能进行相关业务操作的麻烦。 数据不唯一、未共享 对同一个企业,某些基础数据往往需要唯一、统一。如本系统的“物资管理系统”、“劳保工具系统”等中需要关联“员工管理系统”中的员工信息,进而了解该员工拥有的物资设备以及劳保发放情况等;而某些业务数据通常需要作为绩效考核等决策支持系统的原始数据。而原各独立设计的系统很难做到。 业务流程不统一、不规范 因为各个应用系统均为独立设计,开发。其各自的业务操作流程并未统一考虑,往往造成业务流程不统一、不规范。 功能重叠、交叉 各个应用系统的独立架构设计,必然造成系统功能的重叠、交叉。如,为进行“物资管理系统”、“劳保工具系统”等中员工物资设备及劳保情况的操作和统计,必须在各自的系统中添加员工信息等功能等。这既是功能上的重叠,又是开发中的重复。
企业管理软件架构（计算）的历史与发展（上） 企业管理软件是计算机软件应用的一个重要领域，在今天计算机软件除面向科学计算之外应用最广阔的也是企业管理应用，可以说计算机技术的发展推动着企业应用发展，企业管理需要也一方面影响着计算机技术的发展，今天，在我们的周末，企业管理应用软件开发人员占了总开发人员中的极大的比例。 今天我们就来通过回顾计算技术在企业应用中的发展历程来看看软件架构的发展。 主机-字符终端 在PC机没现世之前，极小数的企业使用大型业务处理主机处理企业计算机任务，在那个时候，计算机计算机价格非常昂贵，体积庞大，都是采用多个终端机连接上服务器的形式进行软件操作。 上图即所谓的主机--->终端结构，而一个终端，其实仅仅只是一台显示器和键盘而已，没有CPU和内存，只能接受操作输入和输出结果，没有任务的处理能力，我们可以理解终端为主机的延伸，那么他的逻辑结构呢，就是一个多用户多任务的处理程序。 客户机-服务器结构 PC机的问世，加速了企业应用软件的发展，一方面个人PC机的成本较低，功能也比较强大，企业有能力为员工配备更多的计算机提高工作效率。同时由于企业应用软件的功能逐渐丰富，应用范围越来越宽广和深入，所以对计算机性能的要求也越来越高。在高速的发展的企业应用需求下，传统的大型机的性能已经显现其不足，而与此同时，企业内部却有着大量空闲计算能力的PC电脑。因此，在经济利益的驱动下，企业应用软件开始向分布式的结构发展，将一部分的计算任务放到客户端PC来执行，而服务器仅仅只用来运行一些数据库软件，最大的程度的利用到所有计算机的计算能力，以提高性价比。这种企业软件的应用架构模式被称之为客户端（Clie nt）/服务器（Serv er）模式，也就是通常所说的C/S模式。 随便PC机性能的飞速发展，大量的服务器采用PC技术生产，即大家常见的PC服务器【（X86-X64）服务器】，其价格相对大型主机、小型机非常的低廉，而其计算机能力也越来越接近小型机。
浅谈企业应用架构（一） 一、什么是架构 在牛津高阶词典（第7版）中，架构（architecture）一词的解释是：the design an structure of a computer system，而架构师（architect）一词的解释是：a person who is responsible for planning or creating an idea, an event or a situation。 针对于企业应用，依据不同的关注点，架构可以分为如下几类： 业务架构（Business Architecture）：关注于业务及其流程； 应用架构（Application Architecture）：关注于应用系统设计； 基础架构（Infrastructure Architecture）：关注于基础技术； 数据架构（Data Architecture）：关注于数据存储及其规划； 这里所说的企业应用架构，即属于应用架构，包括如下几个部分： 1.目标和愿景。即应用系统所面临的问题域。 2.评价指标。从哪些纬度和指标来评价和度量解决方案。 3.原则和方法论。为解决这些问题，所采用的原则及其方法论。 4.技术架构。架构的技术层面，给出相应的设计以及结构，描述应用系统。 5.组织因素。架构的组织层面，组织的各个部分如何参与。 二、架构的目标和愿景 1. 架构的问题来源 1.外部，客户要求包括了业务和技术上。 2.内部，组织管理、项目管理和技术发展上。 特别的，架构需要解决的非业务问题包括如下： A.系统目标：系统性能，稳定性等。
B.项目目标：开发成本，项目质量等 C.项目过程：需求的不确定性和开发过程的团队协作性，即所谓的开发管理。 2. 架构的核心问题 问题可分解为两种类型，业务上和技术上。 1. 业务上。问题域分解为，逻辑的纵向抽象层次，以及逻辑的横向模块分解和集成。 2. 技术上。问题域分解为，纵向的技术主题，以及横向的技术职责的分解和集成。 A.领域化 传统的架构模式是三层或者四层模式，虽然从技术上有效的横向分解系统结构，但对业务模型如何建立，如何进行层次间传递，模型间关联关系，以及与服务逻辑耦合等问题没有给出进一步的细化，也带来了很多问题。 此外，在传统设计方法下，分析模型和设计模型的转换也是一个大的问题。 B.组件化 实施组件化或者说模块化，其需求分为两个层面。 1.内部管理，可以帮助开发过程中进行业务切分，帮助控制进度，降低风险，以及财务分析；对于大型复杂的项目，也有利于知识的传递和积累。 2.销售需要，All in one的系统因不符合发展趋势而不利于销售；组件化有助于产品销售，可以针对客户，将若干组件打包销售，同时减少集成的风险。 C.产品化 C.1 定制化问题 定制化问题的由来：1.面向行业的应用通常没有标准，或者完备的标准；2.通常产品的开发是针对于通用或者公共需求，不针对于特定客户；3.而一个确定的客户，其自身的业务差异和管理差异导致需求的差异性。 这种现象尤其在缺乏标准的行业应用中，以及系统的产品化过程中。 传统的简单的解决方式是为每个客户单独维护一个系统分支，在此情况下提供维护和升级，则维护成本巨大；因此如何解决领域的定制化就成为一个重大问题。
企业信息系统架构 图1清晰的展现了我们企业在信息化建设的成果。并且,这些应用系统在各自服务的生产领域内提高了生产效率,提升了服务质量,同时也为决策层提供了可靠、准确的决策数据。 1 问题描述 以上各应用系统系我企业最初始的应用系统架构。由于各个应用系统是根据生产和管理需要逐步建立起来的,在投用初期并未体会到各个应用系统合理架构的重要性和必要性。在众多系统正式上线投用的时候,问题逐一暴露出来,下面列举最关键性问题: 1.1 不能完成“一站式”系统登录 通常一个用户需要使用多个应用系统,从图1的设计架构来看,需要对同一用户进行多个系统单独授权。这不仅可能需要用户记住很多的登陆账号,而且必然造成用户多次登陆才能进行相关业务操作的麻烦。 1.2 数据不唯一、未共享 对同一个企业,某些基础数据往往需要唯一、统一。如本系统的“物资管理系统”、“劳保工具系统”等中需要关联“员工管理系统”中的员工信息,进而了解该员工拥有的物资设备以及劳保发放情况等;而某些业务数据通常需要作为绩效考核等决策支持系统的原始数据。而原各独立设计的系统很难做到。 1.3 业务流程不统一、不规范 因为各个应用系统均为独立设计,开发。其各自的业务操作流程并未统一考虑,往往造成业务流程不统一、不规范。
1.4 功能重叠、交叉 各个应用系统的独立架构设计,必然造成系统功能的重叠、交叉。如,为进行“物资管理系统”、“劳保工具系统”等中员工物资设备及劳保情况的操作和统计,必须在各自的系统中添加员工信息等功能等。这既是功能上的重叠,又是开发中的重复。 2 问题分析 各类问题的暴露,其根本在于设计之初缺乏ERP(Enterprise Resource Planing,企业资源管理计划)系统的设计思想和理念。尽管某些中小企业并不完全需要或完全符合ERP系统的设计、运营和管理模式。但为提高生产效率、开展企业管理创新、推进企业管理现代化和提高企业竞争力,我们有必要将ERP系统设计思想和理念融入到企业信息系统的建设中来。尽量做到系统运行集成化,业务流程合理化,绩效监控以及管理改善持续化。究其原因: 2.1 缺乏统一、集成化的架构 不管出于何种原因,主要由于建设的应用系统,仅仅从生产或管理需求的某一方面进行设计架构:1)未考虑到和其他应用系统的关联性,未做到很好的开放性;2)对企业待建应用系统预测性不高。 2.2 未进行关联应用系统统一设计 1)数据库未进行统一设计,各业务系统的数据唯一、共享基本没实现;2)软件系统没进行合理架构开发,从而造成操作上的繁杂和功能上的重叠。 2.3 操作流程不统一、不规范 部分应用系统的业务操作未结合企业的QHSE标准流程,有的业务办理流程则仅仅是从部分应用单位调研。从而导致应用系统的设计和操作流程不统一、不规范。 3 架构分析设计 鉴于以上各种各样的问题,必须进行企业信息系统合理架构。彻底改变原多系统、独立架构设计的模式,改进为集成化系统、合理化业务流程。从而更加符合用户的使用需求,更加适应企业管理的需要。 3.1 业务架构 1)根据企业的业务发展,准确地预见将来可能建设的业务系统,和已建应用系统进行业务统一规划、归类;2)梳理各类业务流程,以企业的QHSE标准流程为蓝本,并结合实际的业务操作流程。整理为统一、标准的业务操作流程,并且做到易合理化改进。当然企业的QHSE标准流程也随之得到完善和改进。 3.2 应用架构 以模块化的方式进行整个信息系统的集成化设计。即将类似或相关联的业务设计为同
各种系统架构图及其简介 1.Spring架构图 Spring是一个开源框架，是为了解决企业应用程序开发复杂性而创建的。框架的主要优势之一就是其分层架构，分层架构允许您选择使用哪一个组件，同时为J2EE应用程序开发提供集成的框架。Spring框架的功能可以用在任何J2EE 服务器中，大多数功能也适用于不受管理的环境。Spring的核心要点是：支持不绑定到特定J2EE服务的可重用业务和数据访问对象。这样的对象可以在不同J2EE环境（Web或EJB）、独立应用程序、测试环境之间重用。 组成Spring框架的每个模块（或组件）都可以单独存在，或者与其他一个或多个模块联合实现。每个模块的功能如下： 核心容器：核心容器提供Spring框架的基本功能。核心容器的主要组件是BeanFactory，它是工厂模式的实现。BeanFactory使用控制反转（IOC）模式将应用程序的配置和依赖性规范与实际的应用程序代码分开。 Spring上下文：Spring上下文是一个配置文件，向Spring框架提供上下文信息。Spring上下文包括企业服务，例如JNDI、EJB、电子邮件、国际化、校验和调度功能。 Spring AOP：通过配置管理特性，Spring AOP模块直接将面向方面的编程功能集成到了Spring框架中。所以，可以很容易地使Spring框架管理的任何对象支
持AOP。Spring AOP模块为基于Spring的应用程序中的对象提供了事务管理服务。通过使用Spring AOP，不用依赖EJB组件，就可以将声明性事务管理集成到应用程序中。 Spring DAO：JDBC DAO抽象层提供了有意义的异常层次结构，可用该结构来管理异常处理和不同数据库供应商抛出的错误消息。异常层次结构简化了错误处理，并且极大地降低了需要编写的异常代码数量（例如打开和关闭连接）。Spring DAO的面向JDBC的异常遵从通用的DAO异常层次结构。 Spring ORM：Spring框架插入了若干个ORM框架，从而提供了ORM的对象关系工具，其中包括JDO、Hibernate和iBatis SQL Map。所有这些都遵从Spring 的通用事务和DAO异常层次结构。 2.ibatis架构图 ibatis是一个基于Java的持久层框架。iBATIS提供的持久层框架包括SQL Maps和Data Access Objects（DAO），同时还提供一个利用这个框架开发的JPetStore实例。 IBATIS：最大的优点是可以有效的控制sql发送的数目，提高数据层的执行效率！它需要程序员自己去写sql语句，不象hibernate那样是完全面向对象的，自动化的，ibatis是半自动化的，通过表和对象的映射以及手工书写的sql语句，能够实现比hibernate等更高的查询效率。
企业应用的发展概述 在介绍企业服务总线之前，有必要花一些笔墨来介绍企业应用架构的发展和变迁。企业级应用架构的发展经历了以下几个阶段： 1.独立应用系统 2.EAI 阶段 3.SOA 阶段 独立应用阶段 20 世纪60 到70 年代，企业应用处于独立应用系统阶段，当时的企业应用是一种用来替代重复性劳动的简单设计，其目的是用计算机代替孤立的，体力性质的工作环节，将相关联的企业信息或数据管理起来。这些系统大部分是独立的系统——有独立的数据库、应用服务器、用户界面。因此有时候这类应用也叫“竖井型”的应用。 但是，随着业务和信息的不断扩展，独立应用系统渐渐不能满足企业对IT 的需求，表现在大量的信息冗余，因为在建立一个新的应用的时候需要重新建立一套数据库；功能的重新设计，相似的功能存在于多个系统中；例如，客户信息在一个公司中可能有多个拷贝分别存在于多个数据库中，不同时期建立的应用系统所使用的技术也会不同。对于获取客户资料这样的功能，必然存在于多个系统中，而且在不同的系统中其实现方式可能是Java/J2EE、Delphi、C/C++。 EAI 阶段 20 世纪80 到90 年代，一些公司或集成商意识到应用集成的价值和必要性。EAI 是一种将多个不同平台、用不同方案建立的异构的应用集成的一种技术和方法。它的目标包括以下几个方面：各个分离的系统间的相互通讯，消除信息孤岛，实现信息的共享。从功能的角度来看，EAI 包括信息接收、转换、翻译、路由、传播和业务流程管理。从架构上看有两种方式：Hub/Spoke 方式和Bus 方式。 图 1 所示的Hub/Spoke 结构使用一个中心代理（Hub）和多个适配器（Spoke）将Hub 和应用连接起来。适配器负责将应用的数据格式转换成Hub 可以理解的格式，Hub 将数据再转换成目标系统可以理解的格式，并执行消息的路由。Hub/Spoke 方式的弊端在于只有一个代理中心，当连接的应用种类增加或者消息量增大时，代理中心的性能将成为整个系统的瓶颈，在可扩展性方面也存在着一定的问题。
论企业应用系统的分层架构风格 摘要 2015年6月，我所在的公司为全国各级人民检察院开发了行贿犯罪档案互联网查询系统的产品，我担任系统架构师职务，主要负责软件架构和安全体系设计的工作，该项目是基于互联网，为单位、企业和个人等公众群体提供7*24小时的行贿犯罪档案查询申请服务，同时兼顾预防宣传工作的网站系统。 本文结合作者的实践，以行贿犯罪档案互联网查询系统为例，论述企业应用系统的分层架构风格，首先，分析了两层架构和三层架构，讨论三层架构中的表示层、业务逻辑层和数据访问层的设计过程和实施方法，最后说明了采用三层结构带来的效果。经过项目组近半年的努力，本产品已顺利开发完成，目前，已在浙江、云南等多个省上线使用，取得客户和公司领导的一致好评。 正文 随着应用中间件与Web 技术的发展，分层架构风格的设计和使用越来越流行。2015年6月，我所在的公司为全国各级人民检察院开发了行贿犯罪档案互联网查询系统的产品，我担任系统架构师职务，主要负责软件架构和安全体系设计的工作。 1.项目概述 全国检察机关在检察专网已全面完成全国行贿犯罪档案查询系统建设，作为政府采购和招标审查的必经关口，将有行贿犯罪记录者拒之“门”外，大大降低了政府采购、工程建设等领域官商勾结、权钱交易的几率，为有效预防贿赂、震慑犯罪提供了很好的积极作用。但检察专网与互联网物理相互隔离，单位、企业和个人等社会公众群体需要到检察院现场申请查询，不便于申请查询工作及时开展。而且随着申请查询量越来越大，各级检察机关尤其是基层检察院受人力限制，工作量也越来越大。 随着互联网的飞速发展，基于互联网平台建设行贿犯罪档案查询系统（IBCRQ），为单位、企业和个人等公众群体提供实时、高效、方便的行贿犯罪
J a v a企业应用系统框架的比较与选择https://www.doczj.com/doc/9211544905.html,作者：不详来源：不详2006年10月22日发表评论进入社区 引言 EJB的体系结构是J2EE的基础和核心，J2EE定义了整个标准的应用开发体系结构和一 个功能复杂的重量级框架。 J2EE1.4标准规定的EJB 2.1框架缺少设计且实现起来有些过于复杂。当前J2EE5.0的新规范提出的EJB 3.0的目标就是简化开发[1]，借鉴了一些基于POJO的思想，它相对于EJB2.1中两个重要的变化分别是：一是使用了Java5中的程序注释工具，注释取代了过多的XML配置文件并且消除了严格组件模型需求；二是采用了基于Hibernate和TopLink思想的O/R Mapping模型。
J2EE5.0的新规范中定义企业应用三个层次的标准实现为：表现层采用JSF（Java Server Face），JSF的开发流程的核心是事件驱动，组件和标签的封装程度非常高，很多典型应用已经不需要开发者去处理http。整个过程是通过IoC(依赖注入)[2]来实现的；业务组件层采用EJB3.0的Session Bean。EJB3.0允许开发者使用藕合松散的组件来开发应用。这些组件通过自己发布的商业接口来耦合，不必像EJB 2.1规范定义的那样一个Bean必须遵守的严格的组件模型，每一个EJB类必须从某一种抽象类中继承，并为容器提供了回调的钩子；持久层采用EJB3.0实体Bean持久化模型，吸收了Hibernate的一些思想采用O/R Mapping 重用；持久层框主要有Hibernate和各种JDO产品，以及iBATIS。Hibernate是一个开源的O/R Mapping框架，它对JDBC进行了非常轻量级的对象封装，可以应用在任何使用JDBC 的场合，可以在应用EJB的J2EE框架中取代CMP，完成数据持久化的重任。iBATIS是一个简易的SQL Map工具，它是将手工编写的在xml配置文件中的SQL语句映射成Java对象。
各种软件开发系统架构图案例介绍
第一章【荐】共享平台架构图与详细说明 1.1.【荐】共享平台逻辑架构设计 (逻辑指的是业务逻辑) 注:逻辑架构图--主要突出子系统/模块间的业务关系,这里的逻辑指的是业务逻辑如上图所示为本次共享资源平台逻辑架构图，上图整体展现说明包括以下几个方面： 1 应用系统建设 本次项目的一项重点就是实现原有应用系统的全面升级以及新的应用系统的开发，从而建立行业的全面的应用系统架构群。整体应用系统通过SOA面向服务管理架构模式实现应用组件的有效整合，完成应用系统的统一化管理与维护。 2 应用资源采集 整体应用系统资源统一分为两类，具体包括结构化资源和非机构化资源。本次项目就要实现对这两类资源的有效采集和管理。对于非结构化资源，我们将通过相应的资源采集工具完成数据的统一管理与维护。对于结构化资源，我们将通过全面的接口管理体系进行相应资源采集模板的搭建，采集后的数据经过有效的资源审核和分析处理后进入到数据交换平台进行有效管理。 3 数据分析与展现
采集完成的数据将通过有效的资源分析管理机制实现资源的有效管理与展现，具体包括了对资源的查询、分析、统计、汇总、报表、预测、决策等功能模块的搭建。 4 数据的应用 最终数据将通过内外网门户对外进行发布，相关人员包括局内各个部门人员、区各委办局、用人单位以及广大公众将可以通过不同的权限登录不同门户进行相关资源的查询，从而有效提升了我局整体应用服务质量。 综上，我们对本次项目整体逻辑架构进行了有效的构建，下面我们将从技术角度对相关架构进行描述。 1.2.【荐】技术架构设计 注:技术架构图--主要突出子系统/模块自身使用的技术和模块接口关联方式
各种系统架构图与详细说明 2012.07.30
1.1.共享平台逻辑架构设计 如上图所示为本次共享资源平台逻辑架构图，上图整体展现说明包括以下几个方面： 1 应用系统建设 本次项目的一项重点就是实现原有应用系统的全面升级以及新的应用系统的开发，从而建立行业的全面的应用系统架构群。整体应用系统通过SOA面向服务管理架构模式实现应用组件的有效整合，完成应用系统的统一化管理与维护。 2 应用资源采集 整体应用系统资源统一分为两类，具体包括结构化资源和非机构化资源。本次项目就要实现对这两类资源的有效采集和管理。对于非结构化资源，我们将通过相应的资源采集工具完成数据的统一管理与维护。对于结构化资源，我们将通过全面的接口管理体系进行相应资源采集模板的搭建，采集后的数据经过有效的资源审核和分析处理后进入到数据交换平台进行有效管理。 3 数据分析与展现
采集完成的数据将通过有效的资源分析管理机制实现资源的有效管理与展现，具体包括了对资源的查询、分析、统计、汇总、报表、预测、决策等功能模块的搭建。 4 数据的应用 最终数据将通过内外网门户对外进行发布，相关人员包括局内各个部门人员、区各委办局、用人单位以及广大公众将可以通过不同的权限登录不同门户进行相关资源的查询，从而有效提升了我局整体应用服务质量。 综上，我们对本次项目整体逻辑架构进行了有效的构建，下面我们将从技术角度对相关架构进行描述。 1.2.技术架构设计
如上图对本次项目整体技术架构进行了设计，从上图我们可以看出，本次项目整体建设内容应当包含了相关体系架构的搭建、应用功能完善可开发、应用资源全面共享与管理。下面我们将分别进行说明。 1.3.整体架构设计 上述两节，我们对共享平台整体逻辑架构以及项目搭建整体技术架构进行了分别的设计说明，通过上述设计，我们对整体项目的架构图进行了归纳如下： 综上，我们对整体应用系统架构图进行了设计，下面我们将分别进行说明。
这是我近几年看过的对三层架构设计最有价值的文章 与大家分享，希望大家从中得到系统性的启发 ——华哥第一篇：三层架构模型实战。 一．三层架构图 二．系统各层次职责 1．UI（User Interface）层的职责是数据的展现和采集，数据采集的结果通常以Entity object提交给BL层处理。与UI平行的Service Interface层用于将业务发布为服务（如WebServices）。 2．BL（Business Logic）层的职责是按预定的业务逻辑处理UI层提交的请求。 （1）Business class 子层负责基本业务功能的实现。 （2）Business Flow 子层负责将Business class子层提供的多个基本业务功能组织成一个完整的业务流。（Transaction通常在Business Flow 子层开启。） 3．DataAccess层的职责是提供全面的数据访问功能支持，并向上层屏蔽所有的SQL语句以及数据库类型差异。 （1）DB Adapter子层负责屏蔽数据库类型的差异。
（2）ORM子层负责提供对象－关系映射的功能。 （3）Relation子层提供ORM无法完成的基于关系（Relation）的数据访问功能。（4）BEM（Business Entity Manager）子层采用ORM子层和Relation子层来提供业务需要的基础数据访问能力。 三．Aspect Aspect贯穿于系统各层，是系统的横切关注点。通常采用AOP技术来对横切关注点进行建模和实现。 1．Securtiy Aspect：用于对整个系统的Security提供支持。 2．ErrorHandling Aspect：整个系统采用一致的错误/异常处理方式。 3．Log Aspect：用于系统异常、日志记录、业务操作记录等。 四．规则 1．系统各层次及层内部子层次之间都不得跨层调用。 2．Entity object 在各个层之间传递数据。 3．需要在UI层绑定到列表的数据采用基于关系的DataSet传递，除此之外，应该使用Entity object传递数据。 4．对于每一个数据库表（Table）都有一个Entity class与之对应，针对每一个Entity class 都会有一个BEM Class与之对应。 5．在数量上，BEM Class比Entity class要多，这是因为有些跨数据库或跨表的操作（如复杂的联合查询）也需要由相应的BEM Class来提供支持。 6．对于相对简单的系统，可以考虑将Business class 子层和Business Flow 子层合并为一个。 7．UI层和BL层禁止出现任何SQL语句。 五．错误与异常 异常可以分为系统异常（如网络突然断开）和业务异常（如用户的输入值超出最大范围），业务异常必须被转化为业务执行的结果。 1．DataAccess层不得向上层隐藏任何异常（该层抛出的异常几乎都是系统异常）。2．要明确区分业务执行的结果和系统异常。比如验证用户的合法性，如果对应的用户ID 不存在，不应该抛出异常，而是返回（或通过out参数）一个表示验证结果的枚举值，这属于业务执行的结果。但是，如果在从数据库中提取用户信息时，数据库连接突然断开，则应该抛出系统异常。 3．在有些情况下，BL层应根据业务的需要捕获某些系统异常，并将其转化为业务执行的结果。比如，某个业务要求试探指定的数据库是否可连接，这时BL就需要将数据库连接失败的系统异常转换为业务执行的结果。 4．UI层除了从调用BL层的API获取的返回值来查看业务的执行结果外，还需要截获所有的系统异常，并将其解释为友好的错误信息呈现给用户。 六．项目目录结构
1.Spring 架构图 Spring 是一个开源框架，是为了解决企业应用程序开发复杂性而创建的。框架的主要优势之一就是其分层架构，分层架构允许您选择使用哪一个组件，同时为J2EE 应用程序开发提供集成的框架。Spring 框架的功能可以用在任何J2EE 服务器中，大多数功能也适用于不受管理的环境。Spring 的核心要点是：支持不绑定到特定J2EE 服务的可重用业务和数据访问对象。这样的对象可以在不同J2EE 环境（Web或EJB ）、独立应用程序、测试环境之间重用。 组成Spring 框架的每个模块（或组件）都可以单独存在，或者与其他一个或多个模块联合实现。每个模块的功能如下： ?核心容器：核心容器提供Spring 框架的基本功能。核心容器的主要组件是BeanFactory ，它是工厂模式的实现。BeanFactory 使用控制反转（IOC ）模式将应用程序的配置和依赖性规范与实际的应用程序代码分开。 ?Spring 上下文：Spring 上下文是一个配置文件，向Spring 框架提供上下文信息。Spring 上下文包括企业服务，例如JNDI 、EJB 、电子邮件、国际化、校验和调度功能。 ?Spring AOP ：通过配置管理特性，Spring AOP 模块直接将面向方面的编程功能集成到了Spring 框架中。所以，可以很容易地使Spring 框架管理的任何对象支持AOP 。Spring AOP 模块为基于Spring 的应用程序中的对象提供了事务管理服务。通过使用Spring AOP ，不用依赖EJB 组件，就可以将声明性事务管理集成到应用程序中。 ?Spring DAO ：JDBC DAO 抽象层提供了有意义的异常层次结构，可用该结构来管理异常处理和不同数据库供应商抛出的错误消息。异常层次结构简化了错误处理，并且极大地降低了需要编写的异常代码数量（例如打开和关闭连接）。Spring DAO 的面向JDBC 的异常遵从通用的DAO 异常层次结构。
目前流行的Java企业应用系统框架种类繁多，为了使开发人员正确选择系统架构从而提高Java企业应用的开发效率，首先针对基于EJB和基于POJOs的较为流行的几种框架分别进行了概述，然后对这些框架从表现层、业务逻辑层和持久层的实现细节进行了对比，总结了Java企业应用系统框架选择需要侧重考虑因素，得到了基于EJB的框架和基于POJOs 的框架分别适用的范围。 EJB的体系结构是J2EE的基础和核心，J2EE定义了整个标准的应用开发体系结构和一个部署环境，基于EJB的框架一度成为人们开发Java企业应用的首选。随着Java开源项目阵营的发展壮大，一些基于POJOs(Plan Old Java Objects)的开源框架被越来越广泛地引入到Java企业应用的开发中来。根据复杂程度人们习惯把前者称为重量级框架，把后者称为轻量级框架。Java企业应用框架一般被划分为三个层次：表现层、业务逻辑组件层和持久层。本文主要对目前企业应用对应于这三个层次的两种类型的流行框架进行了细节比较，最后针对Java企业应用的系统框架选择提出作者的观点。 两种类型框架概述 1、基于EJB的重量级框架 由于EJB容器能够很好的处理系统性能、事务机制、安全访问权限以及分布式运算等问题，基于EJB框架进行开发能保证企业应用平滑发展，而不是发展到一种规模就重新更换一套软件系统，且可以保证开发人员将大部份精力集中在业务逻辑的开发上。采用EJB 框架开发的企业应用具有必须继承或依赖EJB容器的特点。EJB充分考虑到了顶级大型项目的需求，使用它几乎能解决企业级应用涉及到的所有问题，相应的基于EJB框架也是一个功能复杂的重量级框架。 J2EE1.4标准规定的EJB 2.1框架缺少设计且实现起来有些过于复杂。当前J2EE5.0的新规范提出的EJB 3.0的目标就是简化开发[1]，借鉴了一些基于POJO的思想，它相对于EJB2.1中两个重要的变化分别是：一是使用了Java5中的程序注释工具，注释取代了过多的XML配置文件并且消除了严格组件模型需求；二是采用了基于Hibernate和TopLink思想的O/R Mapping模型。 J2EE5.0的新规范中定义企业应用三个层次的标准实现为：表现层采用JSF（Java Server Face），JSF的开发流程的核心是事件驱动，组件和标签的封装程度非常高，很多典型应用已经不需要开发者去处理http。整个过程是通过IoC(依赖注入)[2]来实现的；业务组件层采用EJB3.0的Session Bean。EJB3.0允许开发者使用藕合松散的组件来开发应用。这些组件通过自己发布的商业接口来耦合，不必像EJB 2.1规范定义的那样一个Bean必须遵守的严格的组件模型，每一个EJB类必须从某一种抽象类中继承，并为容器提供了回调的钩子；持久层采用EJB3.0实体Bean持久化模型，吸收了Hibernate的一些思想采用O/R Mapping 模式，EJBQL也有许多重要的改变。 2、基于POJOs的轻量级框架 在基于POJOs轻量级框架上开发的应用程序无需依赖于EJB容器可独立运行，对应于Java企业应用三个层次的轻量级框架技术分别都得到了一定的发展，这三个层次流行的框架如下： 目前比较流行的开源表现层框架主要有Struts和Tapestry。Tapestry与Struts应用框架不同的是，它是基于组件，而不是面向脚本语言（比如JSP和V elocity）的，组件是由一个定义文件(以XML的格式)、一个HTML模板、一个JA V A类构成的；业务组件层轻量级解决方案也不少，包括Spring、Hivemind等。但是目前使用最为广泛的还是Spring框架，Spring 框架是一个基于IoC和AOP（面向方面）[3]的构架。采用IoC使得它可以很容易的实现bean