步骤3 对应用的了解
了解你的应用在完成的时候的大概情况。这将会使你的架构更实际，并与具体的条件限制和决定有更密切的联系。创建应用的大概视图应该包括以下步骤：
·决定应用的类型。首先决定所构建的应用的类型。它是一个移动应用、富客户端、服务、网络应用、还是组合应用？
·了解部署限制。然后，了解所部署的目标环境和它将对架构产生什么影响。
·确定重要的架构特点。确定你的架构将使用哪些类型。面向服务的架构？客户服务器？分层？消息总线或是某几种的组合？
·确定相关的技术。最后，根据应用类型和各种条件限制确定相关的技术。
决定应用的类型
选择正确的应用类型是应用架构设计的关键。需求和设备限制决定了合适的应用类型。以下几点将帮助你做出合适的选择。
·移动应用可以作为瘦客户端或富客户端。富客户端移动应用可以支持非联网或偶然联网的场景。网络应用或瘦应用只支持联网场景。设备资源将成为这种设计的条件限制。
·富客户应用通常是独立的应用，可以使用多种控制手段在图形界面上显示数据。富客户应用可以用于支持非联网和偶然联网的场景，因为这种应用是运行在客户机上的。
·富因特网应用可以支持多平台和多浏览器并显示多媒体和图形内容。富因特网应用运行在浏览器沙盒上，其对客户端的访问受到限制。
·服务应用用于实现客户与服务器之间的松耦合。服务可以让用户从本地或远程访问复杂的功能。服务操作使用基于基于XML的消息格式的传送机制。
·网络应用通常支持联网场景，通常支持多浏览器和多操作系统平台。
了解部署限制
在设计应用架构的时候，你必须同时考虑企业的政策和程序以及目标部署设备。在目标环境确定的情况下，你的应用设计必须能够反映出实际存在的各种限制。你在进行设计的时候必须考虑到服务质量（QoS）属性，比如安全性和易维护性。有时候由于政策程序上的限制或网络布局的原因，你必须作出一些折衷措施。
要在设计过程的早期确定这些需求和限制，这样你才能尽早地选择合适的部署环境、解决应用与设备架构之间的冲突。
1.分布式与非分布式架构
应用部署通常有两种方式：
非分布式部署 除了数据存储功能，其它功能和层都在同一服务器上。
分布式部署 各层与应用分布在不同的物理级上。
在大部分情况下，我们都建议采用分布式。虽然当一个过程需要跨越物理界限的时候需要对数据进行序列化，因此性能会受到影响。但是由于某些原因我们需要把功能分散到各服务器上。另外，你也可以根据服务器的位置选择最优化的通信协议。
非分布式部署
在非分布式的架构中，呈现、业务和数据存取代码虽然在逻辑上是分开的，在物理层面上却是位于同一网络服务器上的。图2描述了这样的场景。
图2 非分布式部署
优势
非分布式架构更为简单。
由于本地调用，非分布式架构具有性能上的优势。
劣势
难于与其它应用共享业务逻辑。
服务器资源是跨层共享的。这既有好的一面也有不好的一面--因为总有一层处理繁忙状态，如果各层合作良好，资源就能获得充分利用。但是一旦某一层要求更多的资源，其它层可能就会无法利用资源。
分布式部署
如图3所示，分布式部署可以让你把应用的不同层分布在各物理级上。
图3 分布式部署
优势
分布式架构易于扩展，并且可以独立地加载平衡业务逻辑。
各层有自己的资源可以利用。
灵活。
劣势
需要额外的序列化，并由于远程调用而产生网络延迟。
通常更为复杂、更为昂贵。
2.保持相同的过程
尽量避免远程调用。由于序列化和网络延迟等原因，跨物理界限（过程和机器）的远程调意味着昂贵的成本。如图4所示，你可以在当前的服务器中添加更多的硬件或者在网络应用级中添加更多的服务器。
图4 在网络应用级中添加服务器
你可以把应用的业务逻辑寄存到网络服务器上，或者一个物理意义上独立的应用服务器上。通过把业务逻辑放到网络服务器的网络应用过程中，你可以获得非常好的的性能。只要你在应用设计中能够避免或可以利用服务器亲和力，你就可以使用这种方法进行扩展。
3.除非必须，否则不要把应用逻辑放在远程
除非你确实需要这么做，或者已经做过权衡对比，否则决不要把业务逻辑层分离出去。远程逻辑会增加性能成本。这是在网络中环行所造成的网络延迟和序列化必然导致的结果。
然而，你可能确实需要从物理级上将业务层分离出去，比如以下场景：
·你可能想把网关服务器和关键的合作伙伴放到一起。
·你可能需要为既有的一套业务逻辑添加一个网络前端。
·你可能需要在多个客户端应用之间共享业务逻辑。
·企业的安全政策不允许在前端网络服务器上安装业务逻辑。
·可能你的业务逻辑对运算速度非常敏感，所以你需要把这个处理过程减负到一个单独的服务器上。
