从个人软件到企业软件

什么是企业软件

还记得我们一开始写程序的时候吗？那还是在学生时代，因为兴趣，或者你做毕业设计的时候，写出几行代码，实现了一个简单的功能，如计算出一个数学结果，或者弹出来一个窗口，你的心情是那么激动，你充满了成就感！好像看到世界掌握在你的手里了，后来你慢慢实现了很多的功能，一个比一个酷，觉得写一个软件不过如此，但当你毕业了，找工作的时候却遇到了困难：没有工作经验！我可以做软件啊？我可以实现很多功能啊？他们为什么说我不行呢？为什么说我没有经验呢？我和经验老道的工程师有什么区别呢？

我们现在就来探讨这个问题，为什么你写的东西幼稚？为什么人家不敢用你辛苦写的软件？当然，我们在这里讨论的是大部分普通学生，那些天才的高手不属于这个范围。当你以后逐步成为中国软件行业的主力军后，你会发现，你当年写的东西只能属于自娱自乐的“个人软件“,而行业内需要的是正规软件。就如那个文化站站长(尊龙饰)搞的那个”关中女侠“，在小范围内大家乐乐还可以，放到全国电影院线恐怕就不行了！达到我们所说的”企业软件“，这个进化过程，是一个需要大约2年的历练，当然，有人会更短，有人会更长。

企业应用软件，一般指的是那些为商业组织、大型企业而创建并部署的解决方案及应用，这些大型企业级应用的结构复杂，涉及的外部资源众多、逻辑复杂、事务密集、数据量大、用户数多，有较强的安全性、可靠性等考虑。

注意企业应用系统和通用商业软件的区别，商业软件一般是具有通用性的产品，比如金碟、用友的财务软件，它们作为产品，质量要求非常高，非常具有专业性，能满足多数客户的需求；而企业软件系统作为项目，常常是为一个企业定制的，业务比较复杂，直接面对需求多变的用户，需要良好的架构以满足需求的变化。通常会有较多的售后支撑工作。

企业软件的特征

我们现在先列出两种企业软件，来让你对企业软件有个感性的认识。

有一种企业软件的特征是访问量特别大，那些大型的门户网站，比如新浪，就是个例子，很多上班族到公司第一件事情就是打开新浪网，全国范围，全世界范围的华人，假如某个时刻有0.0001%的人在访问它的首页，那也是一个不得了的数字！这样的网站硬件要过得去，软件架构也绝对是非常出色的！

还有一种是业务逻辑特别复杂，要在某个大型的企业内部署，来解决一类业务问题，我们知道，企业内的业务不是孤立的，而是在不同层次上互相关联的，需要和企业已有的系统来建立联系，也可能需要外面的用户、供应商从中获取、输入数据，等等。而且这种软件的需求是不断变化的，你的软件需要适应这种变化。满足这样需求的软件肯定也是非常了不起的！

我们现在来探讨一下企业应用系统具有那些要求或者说特征，一般来说，它在如下的方面要求很高：

l 性能

l 可靠性

l 安全性

l 可用性

l 伸缩性

l 扩展性

l 管理性

这些苛刻的要求都是长时间以来用户提出的，他们希望我们能做到这些，才敢用我们的软件，才敢把他们重要的数据和业务放到我们的软件系统之中！想想那些重要的数据，我们银行存款，我们的手机费用记录，当然还有什么国防机密、卫星上天等数据，我们自己都想象不出来，如果出错，或者丢失，后果会怎样？？？

用户对我们IT界提出挑战，我们要应对这种挑战，我们要让他们信任我们，使用我们的技术，所以，IT技术一直发展到今天，IT的价值已经广泛被人们认同并应用。我们IT人员不断的努力，努力去满足用户的要求，给用户更好的体验。这种努力包含大体可以分为硬件技术和软件技术，硬件技术发展很快，那是我们同行努力的结果，我们在这里不多谈，但要给他们敬意！这里谈的是我们软件方面。

软件又分为系统软件和应用软件，系统软件一般为国外的大厂商所拥有，比如微软，IBM等，系统软件和硬件结合的比较紧密，而且很多前沿技术还处于研究阶段，学术范围之内，距离我们普通的程序员还比较远，我们这里也不多谈，我们只谈和我们关系比较紧密的应用软件，它的发展，它的技术和用户对它的理解！

每个特征的分析

我们来逐个讨论一下每个特征的解释和软件界应对这些挑战而发展的技术。其实，回顾软件技术发展历史，我们可以看出，很多技术就是来解决以上几个方面的要求（另外的技术用于解决软件行业的生产率提高问题），技术应需求而来，用户提出了这么苛刻的要求，我们软件行业就要想方设法来满足他们——因为他们是上帝，是我们软件从业人员的衣食父母！

性能

性能的概念很好理解，从用户角度来看，这个软件系统运行快，反应时间短，就说这个系统性能高。而从系统上来说，用的是事务吞吐量和资源使用率等指标。

为了提高性能，我们可以进行如下方案的选择：

分布式计算，和硬件结合，用若干个服务器，把软件系统也相应分为几个模块(层)，一般为表示层、业务层、数据层，更复杂的还可以多加几个层。每个层在不同的服务器上运行，上层调用下层计算，下层把计算结果返回上层。这样就避免了使用性能更高的服务器，控制了成本，实现了分布式计算。

需要进行文件 IO 或繁重的数字处理的应用程序可能将繁重的工作卸载到另一个或更多的层上，这些层可以方便地伸缩以满足峰值负载需要。比如生成大报表、创建文档或发送 SMTP 邮件的组件就是这样一个例子。

分布式系统学习曲线比较陡峭，只有在一些大型系统中用到，Java平台上的RMI 与 .NET中的Remoting都为分布式计算提供了良好的支持，我们可以从案例研究来学习和实践分布式软件开发，比较出名的案例是“宠物店网站”，java版本和net版本都有。

缓存，以空间换时间，把将来会重复调用的数据、对象预先加入内存或者第一次使用后不销毁，而是缓存到内存中。这样可以节省很多数据生成或者销毁的时间，换来响应速度的提高。常见的缓存有：

l 线程池。节省了大部分线程创建和销毁的时间。典型的例子是Web服务器软件，每个用户访问进来，则线程池会提供一个线程来处理请求。在Java和.Net都提供了创建线程池的机制。

l 对象缓存池。如果某些对象的创建很费时间和资源，则可以当这些对象使用完后先不销毁，而是缓存起来，以备以后使用。J2EE架构中的EJB就是一种典型的对象池技术（图1）。

图 1 EJB 容器的对象池

对象池如果不是为了研究或者学习，请直接用运行平台提供的成熟实现来完成。

l 资源连接池。最常见的是数据库连接池，一般的商业运行平台都实现了此技术，我们只要进行一些简单的配置即可，比如下面的ADO.net数据库连接字符串：

server=localhost;user id=test;password=test;database=Sample;min pool size=4;max pool size=40;

这里设置了数据库连接池中连接的最大数量为40，最少数量为4，ADO.net按照此字符串的设置来提供连接池功能。

l 页面缓存。如果一个B/S系统用户访问量非常之大，我们就可以把某些web页面计算结果缓存起来，当众多客户访问此页面时，将不再计算，直接把结果放到输出流中，从而极大的提高响应速度。比如我们在asp.net页面上直接设置页面缓存：

<%@ OutputCache Duration="60" VaryByParam="type" %>

上面的指令表示缓存此页，缓存期限为60秒，并且根据传入参数type来缓存不同的版本。

并行计算，用多线程技术来达到并行计算，java和C# 都为多线程提供了语言层的支持。多线程可以让响应速度提高，特别是在多用户并发访问时，最常见的是Web服务器软件。每个用户访问到达时，Web服务器会为此用户提供一个线程来处理用户的请求。并行计算可能在企业软件中用的并不多，多数是用在一些系统软件中。但我们需要有清晰的了解，所以你还是有必要自己写点程序来实现一下。

对技术方案的选择，我们举一个例子：事务，事务对性能影响较大，减少使用事务可以提高性能。在开发中使用事务有级别上的差别，比如：

1. 自动事务，由容器（如EJB容器或者Com+）实现，一般你只需做个事务标记，容器会帮你实现。这类事务一般处理复杂的、分布式事务。

2. 手动事务，比如直接在业务层的代码中实现的事务。

3. 数据库脚本事务，直接实现在数据库系统内嵌模块，比如在存储过程中。

从性能上说，事务级别越高级，对性能影响越大。性能最高的事务是在数据库系统中直接实现的事务。微软提倡数据库操作一般写到存储过程中，很重要的一方面是为了性能的考虑。

系统和代码优化，优化你写的代码和后台数据库系统的性能，优化数据库访问，比如只获得你需要的数据，可以减少数据传送量从而提高性能。我们这里说一个常见的分页的例子：

假如一个分页的web页面，页面展示的数据非常庞大，需要分为好多页面，初学者经常会写一个固定的查询语句，如：“Select * from Users”，这样用户每次只查询一页的数据，但我们却每次都返回了所有的数据。浪费很多服务器和网络资源。我们可以写成这样：

select top 20 * from Users where id>lastId

其中lastId 可以根据上一页最后一条记录得到。

图 2 只返回每页的数据

还有一个相似的例子是值对象模式，我们把访问的相关数据打包成一个对象，传送到客户端，客户端代码可以从容访问此对象的各个属性，而不是每访问一个属性就去和服务器交互一次，这样可以减少网络访问次数，从而提高性能。

可靠性

可靠性衡量应用程序能正常运行的程度，更正式的定义为平均故障间隔时间 (MTBF)，即应用程序在发生故障前运行的平均时间长度：

MTBF = 小时数/失败次数

还有一个我们经常用到的指标，即一年中正常运行时间的比率。我们说某个系统的可靠性达到了几个”9”,指的就是这个，如果系统在一年中失败了3个小时，那么可以达到：

(1-3/(365*24))=0.9997

大概是三个9。电信网络一般可以达到5个9，你想想它的失败率有多低！

提高可靠性是一个复杂的系统工程，涉及到硬件、操作系统、运行平台、开发人员和操作人员的培训等等，因为有人为和环境因素，要一个系统达到100%的可靠性是不可能的。可靠性与其他特征紧密相关，如安全、性能、扩展性等，安全性不强，任何人都可以进去捣乱，你还有什么可靠性？

提高可靠性需要考虑成本，不能一味地去追求。对于我们开发者来说，除了尽可能的优化你的代码外，还需要进行如下的考虑：

数据冗余，主要就是备份，包括各种冷、热备份。备份已经是企业软件系统不可缺少的措施，有条件的还需要异地备份，来防止自然灾害等。美国的911袭击过后，世贸中心里的一些金融机构可以马上恢复业务，主要就是他们的完善的异地备份措施。

服务冗余，集群具有容错性，在集群中，同样的服务可以由多台服务器实现，每台服务器的硬件和软件配合提供同样的服务（特别是软件）。当一台服务器因为某种原因而崩溃后，一个监测机制会及时发现失败的机器，迅速用另外的机器来接管它的工作。从而保证业务正常进行，这个过程就是故障转移。

图 3 用集群的故障转移技术

图4的第一台服务器 (Database01) 是处理所有事务的活动服务器。 仅当 Database01 发生故障时，处于空闲状态的第二台服务器 (Database02) 才会处理事务。 集群将一个虚拟 IP 地址和主机名 (Database10) 在客户端和应用程序所使用的网络上公开。

事务，提高可靠性的一种典型方法，在对数据进行一组连续操作时，为了防止意外，如中间的某个步骤出现错误，某个操作不能运行，甚至系统瘫痪、网络突然断掉等，我们就要使用事务。事务保证了数据的正确性、完整性、一致性，从而提高了可靠性。

重试机制，当一次操作失败后，会重复运行命令，重试次数可以设置，如果最后仍然失败后，可以给管理员发出警告。通常用在后台程序、异步执行等情况下。

减少计划内停机时间。比如要把数据库连接字符串放到一个文件中动态读取，才能不至于当数据库有变动时重启系统。

要有错误日志，系统出错后能迅速发现，迅速改正，使故障时间达到最小。

一个增强可靠性的例子是ASP.net中的会话状态存储。Asp.net提供了几种存储会话状态的机制：

1. 进程内模式，会话状态存储在进程内，一旦Web服务器失败，状态将丢失。

2. 状态服务器模式，会话状态存储可以存储在另外的服务器上，一旦Web服务器失败，状态将不会丢失。

3. SQL Server 模式，会话状态竟然可以存储在SQL Server服务器中。

选择后两种模式的应用软件，很明显就可以增强它的可靠性。

安全性

如果你自己写了一个好玩的游戏，并且放到自己攒的电脑在家里玩，你的电脑没有联网，这是几年前我们做过的事情，那个时候，我们根本不用考虑安全性，不用为它写一行代码。而当今的企业应用系统基本上都是网络系统，若干用户从网络上访问系统，得到他们所需要的计算结果，安全性考虑随着网络因素空前的被重视。

应用程序的安全性受很多因素的影响，如网络、操作系统、软件运行平台，你需要进行综合的考虑，要进行各个因素的分析和针对的应对措施，我们开发人员要干什么呢？我们应该多了解一些知识，在其他配置完备的情况下，如数据库备份，操作系统设置，防火墙设置等后，根据系统对数据的安全性要求选用一些技术，如SSL、VPN等，尽量利用软件运行平台的安全设置，如Net平台提供了很多的安全性设置，选择平台提供的验证模式，而不要自己去写一套验证的代码。

初学者还要了解如下的几点：

数据的加密,一些重要的数据，用户的密码都应该加密，尤其是密码，可以用不可逆算法加密。请不要写自己的加密代码，无论你觉得写的多么好，在黑客的攻击下完全没有作用，徒增笑料而已。一般我们要使用成熟的、已经实现好的加密API,这些在Net和Java类库中都存在。

不信任用户的输入，这点初学者尤其要注意，要过滤掉一些特殊的字符，这里顺便说一下我刚开始写代码犯的一个典型的错误，它是初学者容易犯的错误：登录。我们看这个语句

Select * from User where name=’aa’ and password=’11’

其中”aa”,”11”是登录窗体用户名和密码两个文本框输入的数据，假如用户在密码框中输入：1’ or ‘1’=’1

则上面的SQL语句变为：

Select * from User where name=’aa’ and password=’1’ or ‘1’=’1’

结果是什么？无论用户名输入的是什么，他都可以通过验证！

使用最小授权原则。给用户和代码最低的资源访问权限，初学者最容易犯的毛病是SQL Server数据库连接字符串中用的是”sa”，要知道sa的权限有多大？你敢用吗？

我们还举上面的例子，假如有个聪明的人输入了：1’ drop table user，天哪，你的用户信息被清空了！假如你用的不是sa，而是一个没有删除权限的用户，那起码可以避免这样的攻击。

应用分层。相当于设立几个隔离层，你攻破web服务器，但后面还有应用服务器，最后面有数据库服务器，层与层之间设立严格的权限认证。从一层到下一层的通信应只通过特定信道来进行。每一层都为攻击者进入添加一道额外的屏障。电子政务系统所要求的内网和外网分离，也是基于这个思路。

可用性

可用性在有的地方定义为：一个系统可以为用户所使用时间的百分比，即正常运行时间的百分比。我这里说的可用性和它不太一致，这里的可用性主要在用户体验方面。可用性当然和其他的特征，如可靠性、安全、性能联系非常紧密，也可以说包含所有的其他特征，这些都会在用户使用中体现出来。

为什么现在对可用性越来越重视呢，在我看来，可用性是以用户为中心来考虑问题的，我们去问用户：这个软件用的怎么样？他们或者满意的回答：好，或者会给你一大堆抱怨。我们当然希望得到一个简单的“好“字，但这个”好“字却得来不易，它一般包含如下的要求：

l 系统不出错；

l 系统运行稳定；

l 操作简单、实用、功能全面；

l 容易上手，不要让我一直打求助电话麻烦你。

后面两点尤其要引起我们注意，经常有朋友说工作烦死了、烦死了，其实是因为这个系统的可用性不高，所以客户天天找你麻烦，你难道以为客户无聊找你吗？为了减少售后服务成本，使我们的软件利润不至于消耗殆尽，我们应该重视可用性。

提高可用性，需要从开始就要以用户为中心，及早了解用户的需求，从设计到测试，从界面到功能，都尽可能考虑到用户，或者让用户来参与。下面是比较常用的做法：

人性化、标准化，比如一个良好的、模块化的工作界面，不搞一套花哨、另类的界面以致用户找个菜单要找半天，界面元素一般有标准化的Window风格，你需要尽量用标准化元素。初学者往往在这里做的很差，比如随便写一个窗体，窗体标题没有设置；一个表单上的表单元素很不整齐，这些是事情看来很小，但却是一个优秀系统不可缺少的，能尽早养成这样的习惯，对以后有很大好处的。

用户友好的消息，记住一些错误、警告消息要包装成用户理解的语言，不要出现一大堆技术消息。当用户操作成功时，请不要画蛇添足的去告诉用户：操作成功，只在错误发生时提示用户。

“推”信息，不要让用户去查找，要把下一步的操作自动的推到用户面前。比如很多系统的“待办事宜”功能，比如很多邮件通知服务。如果你把这点做到，那就有点专业的味道了，呵呵。

自定义信息，不要自以为是，要让用户来决定，比如查询，要让用户来选择查询条件，让用户来对数据进行他们想要的过滤和排序。

向导机制，对于复杂的操作，需要几个步骤，你可以做个向导来引导用户，这样会深得用户的欢心。在一些大型的针对大众的商业网站，经常有这样例子，我们也可以应用到企业应用系统中。

另外我们说说关于用户习惯方面的事情，你不去现场是考虑不到他们的做法的，我印象深刻的一个教训是刚参加工作写一个增加记录的表单，用户在按“增加”按钮出来一个表单页面，我在表单页面执行的开始生成一个ID ，用户填写完毕后按“保存”按钮，把记录保存到数据库中，谁曾想软件使用的第一天就出现麻烦，原来用户按“保存”按钮保存完毕后，添加第二笔记录时，并不是再按“增加”按钮，而是按IE的“后退”按钮，重用刚才的“过期”页面进行操作（他们倒也懂重用），这样不出错才怪呢！

伸缩性

可伸缩性就是通过增加资源使服务容量产生线性（理想情况下）增长的能力，也就是说，当你的业务发展一日千里，用户每天都在增加，访问量每天都在破记录时，伸缩性好的系统只需要增加几台服务器，或者换一台性能更高的服务器即可，而不用让程序员来修改代码！

伸缩性和性能密切相关，提高伸缩性，实质就是在负载增加的时候使性能不下降。对于伸缩性，我们采取的措施一般有：

负载平衡技术，这是一个经典的提高伸缩性技术。利用服务器群和负载平衡(Load Balancing)技术,当负载增加的时候，我们增加几台机器，进行适当配置后，负载平衡会自动把一部分计算任务迁移到新的机器上，从而使性能保持。

图 4 负载平衡

这将得到一个标准的负载平衡设计。硬件设备或运行在主机上的软件将虚拟主机名 (AppServer20) 和 IP 地址分配给 AppServer1、AppServer2 和 AppServer3。负载平衡的群集向网络公开此虚拟 IP 地址和主机名，并在组内的正常运行服务器之间均衡地分配传入请求的负载。如果 AppServer1 出现故障，则只需将请求定向到 AppServer2 或 AppServer3 即可。取决于提供此功能的技术，可以将一定数目的额外服务器添加到负载平衡的群集中，以最大限度地提高可伸缩性，并超前满足不断增长的需求。

负载平衡技术和故障转移技术很相似，强调的是两个不同的方面，一般会结合起来使用。

隔离事务性方法，尽量使事务性方法和非事务性方法分开，因为事务的整个运行过程都需要系统开销。事务一般由容器实现(如EJB服务器或者com+)，你如果标示你的组件需要事务，而把一个非事务的方法也放进去，显然是愚蠢的。

尽量使组件无状态，保持状态需要耗用资源，多一个用户访问，就需要消耗一点内存。所以你需要少用Session，少用有状态的ejb。

“池”的技术。同提高性能的缓存是一样的道理，池中的对象可以为任何客户端所使用，你可以设置池中对象的最大值和最小值。池中的对象也需要仔细的设计和权衡，如池中的对象一般会频繁使用，而且对象的创建时间长、使用时间短；对象不允许保存客户端状态。Windows平台上的Com+就提供了一个很好的对象池基础服务。这里你只要进行一些简单的设置，就能建立自己的对象池，而且利用com+管理窗口，我们还获得了很好的管理性。下图是在com+中配置对象池的一个窗口：

图 5 在 com+ 中配置对象池

异步和消息队列，如果一个动作需要很长时间运行，可以用异步调用，或者用消息队列技术，而这个用户会话也可以立即返回。只有那些用户并不需要立即看到结果的操作才可以设置为异步，异步执行过程中如果发生错误，我们要找一个合适的方式来通知客户，因为这个时候用户可能在做其他事情，或者已经离开系统了。是否用异步方式也需要权衡和考虑用户的需求。

扩展性

扩展性主要针对需求更改频繁的应用程序，这样的应用程序，我们开发人员都碰过不少，我们也不去讨论是因为需求没有做好，还是其他的问题，我们可以在其他地方做出自己的努力，比如提高它的扩展性！

我们这里讨论的重点不是开发者自己的工作，而是指用户的二次开发。把开发交给用户自己！我们岂不省事多了？说起来容易，但做到用户完全自主去扩展一个系统是很难的，这需要你小心的去设计你的系统，要有足够的灵活性，预留足够的接口，这样才能提高系统的扩展性。

动态编译，提高扩展性的常用方法，经典例子是微软的Office系列软件，你甚至可以用VBA代码自己写程序！Office太复杂了，我们说一个简单的东西：简易的脚本解释器。在一些工作流软件中经常会嵌入这样一个模块。因为用户的流程很复杂，而且经常随业务发展而改变，我们不可能每次都去为它改写代码，所以我们把这些工作交给用户，让用户自己去设计流程！比如原来一个帐单超过1万元需要总经理审批：

If money>10000 then 发送至总经理

现在公司有钱了，总经理只审批超过或等于5万元的帐单：

If money>=50000 then 发送至总经理

用户只要改一个数字和一个逻辑符号，系统会自动的更改这个流程！

松散耦合，提高扩展性要记住一个原则：代码（或者功能、数据）之间关联越松散，扩展性、灵活性就越高！你需要经常做一些看起来罗嗦、烦琐的事情，比如：

l 一个数据表变为两个数据表；

l 一个类分为两个类来写；

l 在两个模块间加另外一个模块来关联；

l 用事件和消息来关联。

其实设计模式通篇讲的就是这个道理，多走一步会给以后带来多几倍的收益。软件开发我们提倡松耦合，也是这个道理。松散耦合系统保证了以后扩展工作的高效率，提高了客户进行二次开发的可行性。

配置参数，不要写死到代码里，要写到一个配置文件中，目前多数系统都用一个一定格式的xml文件做配置文件，配置的数据可以是数据库连接字符串，可以是资源变量，甚至可以是组件的位置和名字，在运行中用另外的组件来代替现在运行的组件，这就是软件的热插拔。著名的ERP软件SAP功能完备的一个原因就是它强大的参数配置模块。

Web 服务，提供web服务接口，能极大的提高系统的扩展性，用户可以用自己的技术和编程语言来为系统扩展功能，使系统能够和其他应用系统交互，完成一些原先没有的功能。

管理性

你还记得微软公司的那则广告吗：”一个人在两个小时内可以升级200台机器”，说的就是Windows 2003 server的易管理性，软件部署后，在运行期间，可能需要对它进行管理，如升级、打包、配置更改、迁移等。一个成熟的企业软件，需要有很好的管理性。管理一个企业应用程序是这个程序的总成本中相当重要部分。现在企业软件也越来越重视软件的部署、配置、升级、监视等过程。

现在软件技术，如Java和.net平台为我们解决了很多的基础问题，如部署和升级，都可以不用注册，直接拷贝，.net还提供了很好的版本管理策略。这些都让我们开发者欢喜不已。很多人觉得J2EE部署和配置还是很复杂，我们期待J2EE产品商能进一步提高他们产品的管理性。

我们除了了解我们软件运行平台提供的功能，并正确的运用外，自己在开发软件也可以为减少管理员工作而做出自己的努力！比如：

管理模块，需要和业务系统模块分开，单独做一个管理模块，用户可以在这里直接配置数据。管理模块只有管理员可以进去，这样避免了每次更改配置需要跑到机房的麻烦，但也要注意需要极高的安全性设置。

移植性，系统迁移的容易程度，除了你的运行平台为你提供之外，你还需要在开发中注意移植性。比如在Web系统开发中，请用相对路径，所有与周围资源相关的代码和设置请放到一个配置文件中。这是一个基本的技巧，比如在Asp.net中的web.config中，你可以进行大量的这样的配置。

补丁管理，尤其对于C/S系统，每台客户机都跑去打补丁无疑是一场恶梦。对于补丁更新的方便性，我们开始就要考虑好方案，让补丁能够自动下载和安装，而不影响程序的运行，这是最完美的。

系统监视功能，监视系统的运行情况，提炼出有用的数据，从而为管理提供帮助。

提醒和报警，使用邮件或者其他提醒方式，使管理员更快的掌握系统运行情况，通常在重要的事件发生后，写一个邮件发送程序，把事件信息发送到管理员邮箱中。

企业应用系统开发中的权衡

因为企业软件范围很广，有不同的用途，有不同的考虑和重点，所以某个企业软件不一定满足所有以上特征的要求，而只强调其中几个方面。比如一个面向个人的通用的产品，如Office方面的软件，就要在可用性方面下工夫，而在伸缩性方面就可以不太考虑。但如果是一个大型的商业网站，随着用户的逐步增加，他就必须有很高的伸缩性，而且还要有极高的安全性。

达到某些方面的要求是需要付出成本的，而且可能与其他方面的要求相矛盾。例如我们要提高可伸缩性，可以用集群，但集群是一个相对复杂的技术，需要复杂的部署的管理，这就和提高管理性相矛盾。易管理性就是越简单越好，最好是把东西拷贝到客户那里，马上就OK了，也就是我们说的”交钥匙”工程，但一般的大型的系统是达不到这样的要求的，否则，也就不用雇佣系统管理员了！我们需要怎样来设计软件，这就需要权衡的艺术，软件的设计，相当程度上都是一种权衡的结果，你可以想想，如果没有权衡，软件还需要设计吗？

企业应用系统发展的趋势

随着互联网应用的逐渐普及，企业、政府业务的信息化，电子商务的快速发展，用户对软件系统的要求也在不断的提高，我们这里讨论三点：互联，可访问性和智能化。

互联

原来单机上的一个应用，原来解决一块独立业务的应用系统被应用系统互联、应用系统集成所代替，而且范围也从一个部门、一个企业到整个产业链，到与政府的信息互联，比如可以分为 企业对雇员(B2E)、企业对企业(B2B) 和企业对客户(B2C)等应用。

用户不想让原有的投资打了水漂，他们不想重新开发一个大而全的系统，更要命的是，很可能原来的每个应用系统都建立在不同的平台之上，它们是“异构”的。企业应用集成（Enterprise Application Integration，EAI）就是应对这些挑战而发展而来的热门技术。EAI深得企业用户的欢心，就在于它很好的考虑了用户的利益。

现在很热的Web服务技术，就是一种很好的互联技术。Java平台上的 JCA(J2EE Connector Architecture)架构也是为了应用系统之间集成而做的一个技术标准。EAI虽然比较复杂，但是我们在开始工作的时候经常会碰到一些情况，比如用户在这个系统把一些数据输入，还需要在另外的系统中再输入一遍，其实用户最反感这种工作，我们就可以抓住这种机会来实践自己的EAI了！

可访问性

应用系统是互联了，可如此众多的系统，使用它们就不是一项简单的工作了。我为了某项工作要进几个系统，为了达到一个报表，要进行多次的数据搜集，用户就又提出要求了：能不能让我更容易的访问它们，更简便的使用它们呢？有！那就是现在同样热门的“门户”概念。

门户对公司内所有应用系统提供一个统一的认证和操作平台，它的后面一般都是各个应用系统之间已经有效的集成了，用户可以在这个平台上操作自己所需要做的全部工作，不用再登录到每个应用系统上做了，甚至还可以把这个平台按照自己的意愿改变它的界面风格！而且客户端可以是浏览器，也可以是手持设备等。公司可以规定员工可以使用哪些内容和应用程序，并可以根据员工的职位定制这些内容

智能

商务智能 （ Business Intelligence ），是现在正在兴起一个热门领域，有人说，商务智能是IT应用系统的历史终结者。其实 商务智能是企业软件自然发展的必然结果，从简单的数据整理，到结合企业业务的各种应用，再到目前的智能决策支持，用户不断增长的需求，已经使企业级软件历经了三个阶段的演化。

用户希望软件系统为他们整理出有用的数据和统计报表，帮助企业管理者决策，并且可以利用工作流技术，重新设计他们的流程，优化他们的管理，利用软件技术，使更多的手工劳动交给软件系统。

常见的一个商务智能技术是数据挖掘，SQL Server里包含了这项服务，它可以帮助公司筛选大数据集，借以发现隐藏的变化模式，对未来商业趋势做出有价值的预测。

我们的修炼之路

上面我们谈了企业软件的特征、企业应用的发展趋势，以及初学者在开始开发中的一些失误，其实这都是一些经验之谈，提出来希望能给初学者的一些帮助，但修炼主要还要靠自己，别人永远代替不了你！

我觉得修炼过程要注意如下的几点

1. 开始就要建立以用户为中心，站在用户的角度看问题的习惯，不能钻到某个技术深层去花费太多的时间，你的技术再深也不大可能超过学术界那帮人的水平！对于每一项技术，尤其是你第一次接触时，你要问一下，它要解决什么问题？为什么会出现这项技术？很多时候你会一通百通、豁然开朗的。

2. 尽快让自己成为专业人员，建立一个“工程”的思维，不要被一些小家子气的成就感长久的占据你的头脑，要知道，你的成就感应该来自于客户的赞扬和传颂！

最后是提倡多看看一些现成的企业级软件的案例（宠物店），多研究一下它们，它们为什么要这样去写？为什么那么的繁杂？开始看不懂也没关系，因为它们很多是为了技术的 demo 的，不要让这些干扰你，你看的是他的设计和架构，以及思维。