20年架构师带你深入SpringCloud微服务架构：传统软件行面临挑战

传统软件行业面临的挑战

自20世纪50年代计算机诞生以来，软件行业也迎来了蓬勃的发展。软件从最初的手工作坊式的交付方式，演变成为职业化开发、团队化开发，进而定制了软件行业的相关规范，形成了软件产业。

但在早期的计算机系统中，软件往往围绕着硬件来开发。硬件之间能够通用，而软件程序却往往是为一个特定的硬件中的某个目标功能而编写，软件的通用性非常有限。

早期的软件，大多数是由使用该软件的个人或机构开发的，所以软件往往带有非常强烈的个人色彩。早期的软件开发没有什么系统的方法论可以遵循，也不存在所谓的软件设计，纯粹就是某个人的头脑中的思想表达。而且，由于在软件开发过程中不需要与他人协作，所以,软件除了源代码外，往往没有软件设计、使用说明书等文档。这样，就造成了软件行业缺乏经验的传承。

从20世纪60年代中期到70年代中期是计算机系统发展的第二个时期，在这一时期软件开始被当作- -种产品而广泛使用。所谓产品，就是可以提供给不同的人使用，从而提高了软件的重用率,降低了软件开发的成本。例如，以前，-套软件只能专门提供给某个人使用，现在同-套软件可以批量地卖给不同的人，显然，就分摊到相同软件上的开发成本而言，卖得越多，成本自然就越低。这个时期，出现了类似“软件作坊”的专职替别人开发软件的团体。虽然是团体协作，但软件开发的方法基本.上仍然沿用早期的个体化软件开发方式，这样导致的问题是软件的数量急剧膨胀，软件需求日趋复杂，软件的维护难度也就越来越大，开发成本变得越来越高，从而导致软件项目频频遭遇失败。这就演变成了“软件危机”。

软件危机概述

“软件危机”迫使人们开始思考软件的开发方式，使人们开始对软件及其特性进行了更加深入的研究，人们对待软件的观念也在悄然地发生改变。在早期，由于计算机的数量很少，只有少数军方或科研机构才有机会接触到计算机，这就让大多数人认为,软件开发人员都是稀少且优秀的(一开始确实也是如此)。由于软件开发的技能只能被少数人所掌握，所以大多数人对于“什么是好的软件”缺乏共识。实际上，早期那些被认为是优秀的程序常常很难被别人看懂，里面充斥着各种程序技巧。加之当时的硬件资源比较紧缺，迫使开发人员在编程时,往往需要考虑更少地占用机器资源，从而会采用不易阅读的“精简”方式来开发,这更加加重了软件的个性化。而现在人们普遍认为，优秀的程序除了功能正确和性能优良外，还应该更加让人容易看懂、容易使用、容易修改和扩充。这就是软件可维护性的要求。

1968年NATO (北大西洋公约组织)会议上首次提出“软件危机”( Software Crisis)这个名词,同时，提出了期望通过“软件工程( Software Engineering)”来解决“软件危机”。“软件 工程”的目的就是要把软件开发从“艺术”和“个体行为”向“工程”和“群体协同工作”进行转化，从而解决“软件危机”。

“软件工程”包含以下两个方面的问题:

(1 )如何开发软件，以满足不断增长、日趋复杂的需求;

(2)如何维护数量不断增长的软件产品。

在软件的可行性分析方面，首先对软件进行可行性分析，可以有效地规避软件失败的风险，提高软件开发的成功率。

在需求方面，软件行业的规范是，需要制定相应的软件规格说明书、软件需求说明书，从而让开发工作有了依据，划清了开发边界，并在- -定程度上减少了“需求蔓延”情况的发生。

在架构设计方面，需制定软件架构说明书，划分系统之间的界限，约定系统间的通信接口,并将系统分为多个模块。这样更容易将任务分解，从而降低系统的复杂性。

软件架构的发展

软件工程的出现，在一定程度上减少了软件危机的发生。但随着软件行业的高速发展，人们对于软件的要求也越来越高。在30年前，软件也许只是满足数据计算。而今,软件不只在娱乐、金融、节能、医疗等各个行业发挥作用，同时，软件架构也不断向着分布式、高并发、高可用、可扩展等方面演进。

早期的软件往往采用集中式的部署方式。这种部署所需要的主机要有非常高的可靠性，因为这样的主机一旦宕机，那么，部署在该主机上的软件就不可用了。同时，这类主机又需要有比较高的配置，能够承载业务的升级需要。

依据摩尔定律，计算机芯片每18个月集成度翻番，价格减半。传统的晶体管是由硅制成的，然而2011年来硅晶体管已接近原子等级，达到物理极限，由于这种物质的自然属性，硅晶体管的运行速度和性能难有突破性发展。正是由于硬件上的限制，使得主机的性能不可能无限地提升。单机的部署方式自然会受到限制，所以近些年来，分布式部署的方式越来越普及。

然而，对于集中式的部署而言,分布式部署软件的方式也不是没有缺点。在设计分布式系统时，经常需要考虑如下的挑战。

人的因素

不管软件行业如何发展，始终围绕的-一个话题是，人在软件开发过程中产生的影响。这里的人特指软件开发人员。

软件行业的人，相比其他行业而言，有其独特性。软件开发的本质是- – 个艺术创作的过程，即很难通过相同的技能传授来使每个开发人员具备相同的技术经验。软件开发受制于开发人员的思考,即便是相同的开发人员，在不同的环境或不同的心情下，所产生的软件质量也参差不齐。而且，软件开发的工作量也存在比较难的量化过程，很难通过代码行数或工时来评定开发人员的工作量。这就是艺术的特点，具备太多的不确定性，需要有创作思维。

Frederick P. Brooks在《人月神话》( The Mythical Man-Month) – -书中阐述道:人力(人)和时间(月)之间的平衡远不是线性关系，在项目的进展过程中会存在各种不可预知的问题，增加人员反而导致项目进度越来越慢。自该书出版以来，40 多年过去了，书中的观点也仍然符合现状,这表明软件开发总是非常困难的，不会有特定的技术和方法，可以使软件项目开发的能力有突破性的进展，甚至可以说，好的开发人员是项目成功的关键。- -个成功的项目里面肯定会有好的开发人员，但好的开发人员并不-一定能造就项目的成功。

软件行业相比其他行业，还是一个比较新的行业， 所以，经验不足是这个行业的通病。有数据表明，从1950年以来，每5年世界上的程序员的数量就增加一倍。各地软件开发的培训班如雨后春笋-一般。很多培训班往往只是提供-些速成的方法，帮助学员来应付面试。这就是为什么很多用人单位发现，应聘者面试时能说会道，但真正用起来却是捉襟见肘。也就是说，这个行业虽然看上去从业人员很多，但大部分都是缺乏开发经验者，缺乏实际解决问题的能力，所以只能从事比较低级的、相对不需要太多“创作”的工作。

在传统的项目中，往往会较少关注人的因素。其实，人的心理决定了做事的质量。一个斗志昂扬、怀抱愿景的开发人员，肯定要比态度消极、浑浑鼉疆的开发人员的效率要高很多。

近些年，不少企业也关注到了这个问题。这也是为什么很多企业极力宣传企业价值观，甚至专门设置了提高开发人员幸福感的“程序员鼓励师”职位的原因。

技术的迭代创新

软件行业的一个最大的特点就是技术更新快。以Java语言为例，Sun 公司最初设计Java是准备用于智能家电类(如机顶盒)的程序开发。然而，由于当时机顶盒的项目并没有成功拿下，于是Java被阴差阳错地应用于万维 。搭着互联 的快车，Java 在移动终端、桌面程序及企业级应用中都占据了很大的市场份额。

然而，技术的发展之快令人侧目，特别是Android、iOs系统的普及，让Java在Java ME领域几乎已经没有市场了。同时，C#、Node.js 等语言的发展，也在“蚕食”着Java桌面应用的市场。

就目前来说，Java 语言在企业级应用方面还占有一定的地位。

20世纪末21世纪初，在HTML平台只能展示简陋的文字排版的时候，Flash 俨然成为令人啧啧称奇的魔法。单调的 页- – 旦使用了Flash,面貌往往会焕然一新。 Flash 可以说是动态 页的最佳解决方案，被广泛应用于 页游戏、门户 站、广告、视频 站、企业级应用(Flex)等领域，当时99%的浏览器都安装了Flash 插件，成为事实上的标准。

然而，Flash Player在顶峰时期，并没有完全解决两方面的致命问题，- 一个是安全漏洞，另一个是耗电。Flash Player几乎每周都要发布新版本，来解决安全方面的漏洞，但漏洞总是频频出现,引发了一系列的安全问题。同时，在移动端，由于Flash Player 耗电这- -事实并没有多大改变,从而被Steve Jobs逐出了iOs手机端。同时，由于HTML 5的标准出现，HTML 5开始逐步代替之前Flash的应用场景。2012年8月15 日，Flash也退出Android平台，正式告别移动端。在过去的一年里，包括Chrome、Edge 和Safari在内的各大浏览器都陆续开始屏蔽Flash。截至2020年，Ado-be将正式停止支持Flash, Flash 终将走到生命的终点。

数据成为基础设施

大数据时代，数据就是互联 的“水电气煤”。

以前，评价一个 站的价值，很大程度上是靠流量。流量大，意味着这个 站的用户活跃度高，黏性大，甚至有些企业为了“搏出位”，采用购买流量的方式，来提升企业在互联 中的地位。

如今，这一切悄悄发生了转变，大企业如Google、Amazon 等互联 巨头早就在抢占数据这个新的制高点。Amazon 利用其20亿个用户账户的大数据，通过预测分析140万台服务器上的10亿GB的数据来促进销量的增长。Amazon 采用追踪电商 站和APP上的- -切行为，尽可能多地收集信息。看一下Amazon.com的“账户”部分，就能发现其强大的账户管理，这也是为收集用户数据服务的。主页上有不同的部分，如“愿望清单”“为你推荐” “浏览历史” “ 与你浏览过的相关商品”“购买此商品的用户也买了”，Amazon 保持对用户行为的追踪，为用户提供卓越的个性化购物体验。

尽管Google并没有把自己标榜成数据公司，但实际上它的确是数据宝库和处理问题的工具。

它已经从一个 页索引发展成为一个实时数据中心枢纽，几乎可以估量任何可以测量的数据，比如天气信息、股票、购物等。当我们进行Google搜索时，大数据就会起作用。Google使用工具来对数据分类和理解，计算程序运行复杂的算法，旨在将输人的查询与所有可用数据相匹配。通过大数据的搜索，它还能推断出你是否正在寻找新闻、事实、人物或统计信息，并从适当的数据库中提取数据。对于更复杂的操作，如中英文翻译，Google会调用其他基于大数据的内置算法。Google的翻译服务研究了数以百万计的翻译文本或演讲稿，旨在为顾客提供最准确的解释。Google还能通过分析我们浏览的 页，向我们展示可能感兴趣的产品和服务的广告。

毫无疑问，每天互联 产生了数以亿计的数据。这些大数据如何被存储、分类、检索和分析，都将挑战着这个时代的技术极限。

开发方式的转变

早些年，瀑布模型还是标准的软件开发模型。瀑布模型将软件生命周期划分为制订计划、需求分析、软件设计、程序编写、软件测试和运行维护六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。在瀑布模型中,软件开发的各项活动严格按照线性方式进行，当前活动接受上一项活动的工作结果，实施完成所需的工作内容。当前活动的工作结果需要进行验证，如验证通过，则该结果作为下一项活动的输人，继续进行下一项活动，否则返回修改。

瀑布模型的优点是严格遵循预先计划的步骤顺序进行，- -切按部就班，整个过程比较严谨。同时，瀑布模型强调文档的作用，并要求每个阶段都要仔细验证文档的内容。但是，这种模型的线性过程太理想化，主要存在以下几个方面的问题。

●各个阶段的划分完 全固定，阶段之间产生大量的文档，极大地增加了工作量。

●由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险。

●早期的错误可 能要等到开发后期的测试阶段才能发现，进而带来严重的后果。各个软件生命周期衔接花费的时间较长，团队人员交流成本大。

瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的，所以瀑布式方法非常适合需求明确的软件开发。但在如今，时间就是金钱，如何快速抢占市场是每个互联 企业需要考虑的第一要素。 所以，快速迭代、频繁发布的原型开发和敏捷开发方式，被越来越多的互联 企业所采用。甚至很多传统企业也在逐步向敏捷、“短平快” 的开发方式靠拢，毕竟，谁愿意等待呢?

客户将需求告诉了你，当然是希望越快得到反馈越好，那么，最快的方式莫过于在原有系统的基础上，搭建一个原型提供给客户作为参考。客户拿到原型之后，肯定会反馈他的意见，好或坏的方面都会有。这样，开发人员就能根据客户的反馈对原型进行快速更改，快速发布新的版本，从而实现良好的反馈闭环。

2017年8月23日，Martin Fowler在其博客宣布，他的老板Roy Singham将会出售其所在的公司ThoughtWorks。ThoughtWorks 是世界著名的软件供应商及咨询服务机构，而Martin Fowler 自2000年起，就一.直在该公司担任首席科学家，宣导其敏捷开发的工作方式。这次ThoughtWorks的交易，也引发了业界的猜想。虽然新东家Apax Funds承诺接手后，原有的管理方式不会改变，但这也从侧面反映了传统的软件外包模式和传统的构建软件的方法是存在危机的。

2017年8月，Oracle 在其官方博客上宣称，会将Java EE开源。这意味着，传统闭源的开发方式不一定是最佳的方案，即便是像Oracle 这样的大企业，也无法靠- -己之力来运营像Java EE这样的企业级产品。Oracle 希望Java EE能够更快、更好地为企业服务，那么将Java EE开源，无疑是更加开放、更加贴近开源 区。通过开源 区更多的力量来共同促进Java EE的发展，无论是对于Oracle还是 区，都是双赢的选择。未来软件行业的发展，开源的软件开发方式也会占有一定的市场。

总之，软件开发天生就没有银弹!开发人员唯有不断地学习技术，做好创新,才能不断地满足这个时代对于技术的要求。

今天给大家讲述的是传统软件行业面临的挑战内容，喜欢的朋友可以转发关注一下小编！！

明天给大家分享常见分布式系统架构的内容，感谢大家支持！！！！