IT运行环境正在发生激烈的变化。一方面，由于互联网的普及、Web 2.0的流行以及虚拟化、云计算等技术的出现使得软件所要面对的环境日益复杂，不仅要面对种类更多的数据源，同时也要求软件能支持动态的配置和重组; 而另一方面，IT的普及带来了数据量的剧增，根据IDC的研究，未来5年，企业的结构化数据每年会保持20%的增长，而非结构化数据量的增加则高达60%。数据量急剧增加的一个必然后果是软件越来越大，也越来越复杂。
　　越来越多的数据、支持更复杂的数据源、软件能自动配置和重组等这些要求最终都需要更灵活和可靠的软件架构来实现，而传统的软件架构显然难以适应新的IT环境。实际上，以前我们设计应用软件架构的前提如今都已经发生了改变，因而软件的架构也需要改变，特别是考虑云计算在未来5年内的普及，我们的软件必须为云计算而设计。
　　IT成为业务的支柱
　　过去，IT主要用于完成一些可重复的业务流程的自动化，比如读取某个报表中的数据并对此进行计算。ERP算得上是IT最典型的应用方式，它实现了订单、记账和库存跟踪的自动化，从而大幅度提升工作效率。而如今IT技术的这种应用方式正在发生变化，因为今天的企业所经营的业务已经很难和IT分开。
　　一个典型例子就是一种在线音乐服务——网络收音机。提出这种业务的公司在一些专业人士的帮助下为它的客户提供定制的音乐，它们会跟踪每个客户的收听习惯和听完音乐后的反馈，以保证它们为每个客户推送的都是客户喜欢的节目。很显然，没有强大的IT基础设施和计算能力作为保证，这项服务是不可能实现的。
　　而物联网的兴起更是推动了应用软件的变化，使得软件从人机交互为主到全面的自动化。应该说，到目前为止，大多数计算都是由人类活动发起的，比如订购了一个商品、访问一个网页等等。而未来，由各种各样的设备（如传感器）发起而非人类活动发起的计算会越来越多。比如，如今智能电表在很多城市得到普及，它取代了传统的人工抄表方式，省时省力。方便的背后是因为它主动发起了很多操作: 这种智能电表与电力公司的数据中心相连，它自动地把账单信息上传到电力公司的数据中心。除此之外，它还能实时地记录用户的电力使用细节，这些信息能帮助电力公司了解某个用户使用电力的情况，从而制定相应的价格策略。这与每月仅仅读取一个用电数相比，要传输和处理的数据量多了很多，也使得后台的处理工作量大了很多，最终必然会影响后台的软件架构。
　　架构设计需应对四个挑战
　　应用程序需要处理的数据量、数据类型以及应用程序的应用场景的变化，给未来的应用软件设计带来很多挑战。具体来说，有四个方面:
　　应用程序负载变化大。工作任务变化和工作环境的复杂都使得应用程序的负载变得不可预测。比如，酒店传统的高峰时段是每天早上（主要为退房）和下午4～9点（入住）。而在未来，业务的多样化将使得应用程序随时都有可能出现高负荷。也就是说，应用程序将是全天候处于工作状态，而不仅仅只在某几个小时。
　　用户接口类型更加复杂。过去很多应用程序是面向人的，因此非常重视人机交互，比如会有很大的显示屏以方便用户输入，而如今数据来源趋于多样化，除了人工输入外，更多时候是来自于其他应用程序、传感设备或者来自用户上载的文件或者之前根本没有想到过的某个数据源。因此，在接口方面除了传统的服务接口、上载接口还要考虑各种终端或者外设的输入，除了单数据的输入还要考虑批量上载。相应地，在应用程序的架构设计时就必须把各种新的数据流考虑进来。
　　要支持移动应用。过去的应用程序通常都工作在一个相对稳定的场合，与外部的连接通常也是可靠的，而架构设计通常也是基于这样的前提设计的。而今，随着无线网络的普及，无线应用越来越多，而在无线网络中，连接并非一定是可靠的。比如，用户正在一个急驶的出租车中，他所使用的服务可能随着位置的变化很快不可用。因此，程序必须充分考虑这一点，即在网络联通时能快速获得所需的数据，一旦中断能保护好工作“现场”，以待下次网络恢复时继续。
　　应用程序的拓扑结构更复杂。数据处理规模的不可预测，要求软件架构的设计必须改变。比如，很多程序开始大量使用内存缓存数据以提高处理速度，而不一定把每个都保存到数据库。而且，应用程序复杂常常是与异步处理和计算密集性的任务相伴相随的，这时通常都会用到消息队列，在应用程序的软件架构时都必须考虑到这些问题。
　　从软件架构开始支持云计算
　　为了保证应用系统能够满足企业未来的新需求，特别是支持云计算，对于新的软件系统有必要在软件架构上做好准备。建议可以从以下几个方面进行考虑:
　　1.对应用软件中准备使用的中间件（或组件）进行重新评估。现有大多数中间件是面向静态环境进行设计的，通常采用手工配置，偶尔进行升级。这些中间件一般都有一个配置文件，人工进行流程编排。中间件启动时，先读取这个配置文件，然后根据文件要求完成规定的任务。未来，随着云计算环境的普及，不断会有新的连接加入也会有连接退出，这就会导致与中间件的连接关系发生变化，上述手工方式就开始显出不足来。为此，未来的架构必须支持在线调整中间件在流程中的关系、能动态增加和删减连接。
　　2.在软件的设计和开发过程中时刻牢记负载平衡。很多应用软件支持在Web服务器层的负载平衡，但进行负载均衡的时候要求所连接的组件数量固定而且IP地址也是固定的。而实践中，负载变化的幅度可能很大，所以应用软件的每个部分都应是可扩展的，也就是说要支持动态的负载均衡，在设计应用软件架构时不能先假定只有一个或者几个组件。
　　3.不要忘了可扩展性。可扩展性一直是设计软件架构时应该考虑的，只是未来软件的可扩展问题可能变得更重要。换句话说，未来的软件必须要有能支持2倍、3倍甚至10倍负载的能力，因为将来软件的应用软件放到云环境中后，负载会变得不可预测，为此必须特别注意可能存在的性能瓶颈，而且要考虑好如何在程序运行的过程中解决可能存在的问题。事实上，如果设计时不考虑到可扩展性，未来的软件架构将很难应对超出的负载。
　　4.支持应用软件的动态更新。40年前汽车制造商要生产一种新的车型，需要用两周的时间来对生产线进行调整，而后来丰田汽车率先实现了工厂的动态升级，仅用两个小时就实现了这种调整。今天的应用软件设计所处的情景与此相似，在云计算时代，应用程序24小时运行，不允许为了对软件进行升级而停机。因此，今天的应用软件架构设计必须考虑到如何在不影响用户使用自己所需服务的同时，对软件进行升级和调整，正如丰田汽车所做的那样。同样，与数据库有关的模型设计也必须支持这种新的软件使用模式。

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。