我的架构经验小结－－ 常用的架构模型

原文：http://www.cnblogs.com/zhuweisky/archive/2006/12/23/601116.html

   经过这几年的积累，在系统架构方面逐渐积累了一些自己的经验，到今天有必要对这些经验作个小结。在我的架构思维中，主要可以归类为三种架构模型：3/N层架构、“框架＋插件”架构、地域分布式架构。

一．三种架构模型

1．3/N层架构

       这是经典的多层架构模型，对于稍微复杂一点或特别复杂的系统，不使用分层架构是很难想象的。下图是经典的3层架构：
 

   如今，凡是个程序员都能侃侃而谈3/N层架构，这确实是解决系统复杂性的一种主流模式，但是，只要采用了3/N层架构是不是就一定能解决系统的复杂性了？不一定，关键在于你在你的系统中如何实作你的3/N层结构。
   在采用了3/N层架构后，我们还是要解决以下非常重要的问题：系统的可扩展性（能从容地应对变化）、系统的可维护性（因为系统并不是使用一次就被抛弃）、方便部署（在需求变化时，方便部署新的业务功能）、还有等等其它系统质量属性。然而系统的可扩展性和可维护性是大多数软件系统必须解决的重中之重，这是由于当前需求复杂多变的软件环境决定的。就像实现功能需求是最基本的，采用3/N层架构也只是万里长征的第一步。
   我采用“框架＋插件”架构来解决与系统的可扩展性、可维护性和部署相关的难题。 

2. “框架＋插件”架构

       经典的3/N层架构是对系统进行“纵向”分层，而“框架＋插件”架构对系统进行“横向”分解。3/N层架构和“框架＋插件”架构处于一个平等的位置，它们没有任何依赖关系。
 

   但是我经常将它们结合在一起使用，我们的系统在经过3/N层架构的纵向分层和“框架＋插件”架构的横向分层后，可以被看作一个“网格”结构，其中的某些网格可以看作是“扩展点”，我们可以在这些扩展点处挂接“插件”。也就是说我们可以在3/N层架构的每一层都挂接适当的插件来完成该层的一些功能。如：
 

   插件最主要的特点是可以实现“热插拔”，也就是说可以在不停止服务的情况下，动态加载/移除/更新插件。所以，采用插件技术可以实现以下功能：
（1）在UI层，我们可以在运行时，替换掉某些用户界面、或加载与新的业务相关的用户界面。在业务逻辑层，我们可以在运行时加载、替换或者删除某项业务服务。在数据访问层，通过使用插件技术我们可以动态地添加对新的数据库类型（如MySQL）的支持。
   插件的“热插拔”功能使得我们的系统有非常好的可扩展性。
（2）如果我们需要升级系统，很多情况下，只要升级我们的插件（比如业务插件）就可以了，我们可以做到在服务运行的时候进行插件的自动升级。
（3）要想将系统做成“框架＋插件”的结构，要求我们需要在系统的各层进行“松耦合”设计，只有松耦合的组件才可以被做成“插件”。
   
   在3/N层架构中融合“框架＋插件”架构，最难的是对业务逻辑层的松耦合处理，这需要我们细致分析业务需求之间的关联，将耦合度紧密的业务封装在一个组件中，如此得到的相互独立的业务组件便可以有机会成为插件。这个过程可能需要不断的重构、设计的重构。
   我们知道，相比于那些紧密耦合的组件，松耦合的组件更加清晰明确、更加容易维护。另外，在该架构模型中引入了AOP框架进行Aspect焦点的集中编程（比如处理日志记录、权限管理等方面），使得Aspect代码不会掺杂在正常的业务逻辑代码中，使得代码的的清晰性、可维护性进一步增强。
   从上述介绍可以看出，采用3/N层架构和“框架＋插件”架构相结合，我们可以增强系统的可扩展性、可维护性和简单部署升级的能力。

3.地域分布式架构

       我无意中发明了“地域分布式架构”这个词，呵呵，不知道意思是否表达得准确。地域分布式架构主要针对类似LBS（基于位置的服务）的需要进行地域分布的应用。      地域分布式架构基于上述的3/N层架构和“框架＋插件”架构，它们的关系如下：
 

   现在我对地域分布式架构作个简单的介绍。假设我们需要为全国的各个大城市提供我们的业务功能服务，假设每个城市的客户量很大，而且每个城市访问的数据可能是不一样的（如每个城市的地图数据）、访问的功能也不尽相同（如有的城市提供天气查询服务，而另一些城市不提供）。客户除了跟我们的系统请求服务之外，可能还想通过我们的系统与他的好朋友进行即时通信，而它们好朋友可能与他在同一个城市，也可能位于另外一个城市。
   好了，我们看地域分布式架构是如何解决类似上述的需求的。
   首先，地域分布式架构将用户管理和业务功能服务分开，分别由应用服务器（AS）和功能服务器（FS）负责，然后将它们部署到不同的节点上。AS和FS都采用了3/N层架构和“框架＋插件”架构相结合的架构，比如，FS通过功能插件提供功能服务。
   比如，对于武汉这个地域，我们部署了一台AS和一台FS，客户端通过连接到AS进行服务请求。假设有一天，我们在武汉的客户急剧增加，这是压力最大的是FS，因为所有的业务计算都是在FS上完成的。
   这时，地域分布式架构将允许我们在不停止任何服务的情况下，动态的添加FS服务器，新添加的FS服务器会自动注册到AS。
 
   AS可以监控每个FS的负载（如CPU消耗、内存消耗），再有客户端请求到来时，AS会将请求交给负载最低的FS处理，这就实现了FS的负载均衡。
   如果Client A需要与Client B进行即时通信，那么这些通信消息将通过AS中转。
   上面看到的是我们的系统在武汉的部署，而在其他城市部署情况也一样。

   在这种情况下，AS和AS之间是相互独立的，但是经常会发生AS之间需要相互通信的情况，比如：Client A需要与Client E进行即时通信，或者Client A需要请求上海地区独有的服务，等等。
   地域分布式架构使用跨区域的应用服务器（IRAS）来解决AS之间的通信问题。所有AS在启动的时候，将自动向IRAS注册。
   如果，我们想在长沙市也提供我们的服务，那么我们只需要在长沙部署我们的AS和FS，这样就可以融入到上图表示的整个地域分布式架构中。
   关于地域分布式架构，就简单的介绍这么多，更多的内容，读者可以自己去分析挖掘。

二．对架构模型的支持

       如果没有自己的一套工具对上述的架构模型作支持，那么你可能会认为我是在这里胡扯、夸夸其谈。在这几年的开发中，我积累了几套框架和类库用于对上述架构模型提供支持。
（1）    DataRabbit 提供了基于关系和基于ORM（轻量）的数据访问，通过插件的方式来支持新的数据库类型。

（2）    ESFramework 解决了分布式系统（如上述的地域分布式架构）之间的底层通信（直接基于TCP和UDP）。

（3）    AddinsFramework 为“框架＋插件”架构模型提供支持。

（4）    ESAspect 通过Proxy方式实现的AOP框架，对方面编程提供支持。

（5）    EsfDRArchitecture 为地域分布式架构模型提供支持。比如支持，FS的动态添加/移除；FS的负载均衡；AS与FS、AS与IRAS之间的通信；跨区域的服务请求等等。   可以参见http://zhuweisky.cnblogs.com/archive/2006/03/15/350408.html了解更多。

    上面介绍的很多内容在我以往的blog文章中都有提及，读者可以针对我早期的blog来进一步了解这些内容。

   在 我的架构经验小结（一）－－ 常用的架构模型 一文中简单介绍了我常采用的几种架构模型，本文将稍微深入地介绍其中的一种 －－ 三层架构模型。

一．三层架构图
 
二．系统各层次职责
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．目录结构：以EAS系统为例。

2．命名空间命名：每个dll的根命名空间即是该dll的名字，如EAS.BL.dll的根命名空间就是EAS.BL。每个根命名空间下面可以根据需求的分类而增加子命名空间，比如，EAS.BL的子空间EAS.BL.Order与EAS.BL.Permission分别处理不同的业务逻辑。

七．发布服务与服务回调
   以EAS系统为例。
1．如果EAS系统提供了WebService（Remoting）服务，则EAS必须提供EAS.Entrance.dll。EAS.Entrance.dll封装了与EAS服务交换信息的通信机制，客户系统只要通过EAS.Entrance.dll就可以非常简便地访问EAS提供的服务。
2．如果EAS需要通过WebService（Remoting）回调客户系统，则必须提供仅仅定义了接口的EAS.CallBack.dll，客户系统将引用该dll，实现其中的接口，并将其发布为服务，供EAS回调。
3．当WebService的参数或返回值需要是复杂类型，则该复杂类型应该在对应的EAS.Entrance.dll或EAS.CallBack.dll中定义，WebService定义的方法中的复杂类型应该使用Xml字符串代替，而Xml字符串和复杂类型对象之间的转换应当在EAS.Entrance.dll或EAS.CallBack.dll中实现。
   在 我的架构经验小结（二）－－ 关于三层架构 一文中，已经比较深入的介绍过三层架构方面的一些经验了，现在，我们来使用一个更小的比例尺来近距离观察我所理解的三层架构。

一．三层架构图

 

二．系统各层次职责
1.UI（User Interface）层的职责是数据的展现和采集，数据采集的结果通常以Entity object提交给BL层处理。Service Interface侧层用于将业务或数据资源发布为服务（如WebServices）。
2.BL（Business Logic）层的职责是按预定的业务逻辑处理UI层提交的请求。
（1）Business Function 子层负责基本业务功能的实现。
（2）Business Flow 子层负责将Business Function子层提供的多个基本业务功能组织成一个完整的业务流。（Transaction只能在Business Flow 子层开启。）
3．ResourceAccess层的职责是提供全面的资源访问功能支持，并向上层屏蔽资源的来源。
（1）BEM（Business Entity Manager）子层采用DataAccess子层和ServiceAccess子层来提供业务需要的基础数据/资源访问能力。
（2）DataAccess子层负责从数据库中存取资源，并向BEM子层屏蔽所有的SQL语句以及数据库类型差异。
DB Adapter子层负责屏蔽数据库类型的差异。
ORM子层负责提供对象－关系映射的功能。
Relation子层提供ORM无法完成的基于关系（Relation）的数据访问功能。
（3）ServiceAccess子层用于以SOA的方式从外部系统获取资源。
注：Service Entrance用于简化对Service的访问，它相当于Service的代理，客户直接使用Service Entrance就可以访问系统发布的服务。Service     Entrance为特定的平台（如Java、.Net）提供强类型的接口，内部可能隐藏了复杂的参数类型转换。
（4）ConfigAccess子层用于从配置文件中获取配置object或将配置object保存倒配置文件。
4．Entity侧层跨越UI/BEM/ResourceManager层，在这些层之间传递数据。Entity侧层中包含三类Entity，如下图所示：

 
三．Aspect
 Aspect贯穿于系统各层，是系统的横切关注点。通常采用AOP技术来对横切关注点进行建模和实现。
1．Securtiy Aspect：用于对整个系统的Security提供支持。
2．ErrorHandling Aspect：整个系统采用一致的错误/异常处理方式。
3．Log Aspect：用于系统异常、日志记录、业务操作记录等。

四．规则
1．系统各层次及层内部子层次之间都不得跨层调用。
2．Entity object 在各个层之间传递数据。
3．需要在UI层绑定到列表的数据采用基于关系的DataSet传递，除此之外，应该使用Entity object传递数据。
4．对于每一个数据库表（Table）都有一个DB Entity class与之对应，针对每一个Entity class都会有一个BEM Class与之对应。
5．有些跨数据库或跨表的操作（如复杂的联合查询）也需要由相应的BEM Class来提供支持。
6．对于相对简单的系统，可以考虑将Business Function子层和Business Flow 子层合并为一个。
7．UI层和BL层禁止出现任何SQL语句。

五．错误与异常
        异常可以分为系统异常（如网络突然断开）和业务异常（如用户的输入值超出最大范围），业务异常必须被转化为业务执行的结果。
1．DataAccess层不得向上层隐藏任何异常（该层抛出的异常几乎都是系统异常）。
2．要明确区分业务执行的结果和系统异常。比如验证用户的合法性，如果对应的用户ID不存在，不应该抛出异常，而是返回（或通过out参数）一个表示验证结果的枚举值，这属于业务执行的结果。但是，如果在从数据库中提取用户信息时，数据库连接突然断开，则应该抛出系统异常。
3．在有些情况下，BL层应根据业务的需要捕获某些系统异常，并将其转化为业务执行的结果。比如，某个业务要求试探指定的数据库是否可连接，这时BL就需要将数据库连接失败的系统异常转换为业务执行的结果。
4．UI层(包括Service层)除了从调用BL层的API获取的返回值来查看业务的执行结果外，还需要截获所有的系统异常，并将其解释为友好的错误信息呈现给用户。

六．项目组织目结构
 以BAS系统为例。
1．主目录结构：
 
2．命名空间命名：每个dll的根命名空间即是该dll的名字，如EAS.BL.dll的根命名空间就是EAS.BL。每个根命名空间下面可以根据需求的分类而增加子命名空间，比如，EAS.BL的子空间EAS.BL.Order与EAS.BL.Permission分别处理不同的业务逻辑。
3.包含众多子项目的庞大项目的物理组织：
 
核心子项目Core的位置：

 
Core子项目中包含一些公共的基础设施，如错误处理、权限控制方面等。

七．发布服务与服务回调
以EAS系统为例。
 
1．同UI层的Page一样，服务也不允许抛出任何异常，而是应该以返回错误码(int型，1表示成功，其它值表示失败)的形式来表明服务调用出现了错误，如果方法有返回值，则返回值以out参数提供。
2.如果BAS系统提供了WebService（Remoting）服务，则BAS必须提供BAS.Entrance.dll。BAS.Entrance.dll封装了与BAS服务交换信息的通信机制，客户系统只要通过BAS.Entrance.dll就可以非常简便地访问BAS提供的服务。
3．如果BAS需要通过WebService（Remoting）回调客户系统，则必须提供仅仅定义了接口的BAS.CallBack.dll，客户系统将引用该dll，实现其中的接口，并将其发布为服务，供BAS回调。
4．当WebService的参数或返回值需要是复杂类型――即架构图中的Service Entity，则Service Entity应该在对应的BAS.EntranceParaDef.dll或BAS.CallBackParaDef.dll中定义。WebService定义的方法中的复杂类型应该使用Xml字符串代替（注意，Entrance和CallBack接口对应服务的方法的参数是强类型的），而Xml字符串和复杂类型对象之间的转换应当在BAS.Entrance.dll或BAS.CallBack.dll中实现。

      在06、07年的时候，我写过一些关于三层架构方面的东西（参见这里），现在看来，觉得有很多实用性的内容需要补充到里面去。我们还是先从架构图看起，然后一一解释，你就会发现相比于两年前，这个架构做了哪些变化和调整。

一．三层架构图

 

二．系统各层次职责

1.UI（User Interface）层的职责是数据的展现和采集，数据采集的结果通常以Entity object提交给BL层处理。

  Web表示我们常用的B/S应用，WinForm表示我们常用的C/S应用。

Network层以Socket的方式提供服务给客户端。

Service层用于将业务或数据资源发布为服务（如WebServices）。

 

2.BL（Business Logic）&Platform层的职责是按预定的业务逻辑处理UI层提交的请求，并对核心资源进行管理。

（1）Business Function 子层负责基本业务功能的实现。

（2）Business Flow 子层负责将Business Function子层提供的多个基本业务功能组织成一个完整的业务流。

（3）Platform子层用于统一管理有状态的数据和资源。

（4）注意：Transaction只能在BusinessFlow/Platform层开启。

（5）BL最好是没有状态的，而必需的状态管理可以放到Platform中的某些模块/子系统进行。如此可增强系统的可伸缩性。

（6）Cache子层用于缓存系统常用的数据信息，Cache对于提供系统的并发量和吞吐能力起到至关重要的作用。Cache可以分为以下几类：

 

StaticCache

HotCache

SyncEntityCache

RefreshCache

SubObjectCache

 

   StaticCache：如果某数据表中的数据是静态的、不会发生变化的，那就非常容易，我们只需要在系统启动的时候，将其加载到内存，以后每次从内存读取数据即可。

   HotCache：如果数据表中的记录非常多，并且修改方面只会有Insert操作，那么我们可以使用HotCache，把那些经常使用的记录缓存在内存中，并且可设定超时机制删除内存中长期不使用的记录。

   SyncEntityCache：如果我们的某个数据表中的数据会发生变化（增删改），但是变化的频率比较低，但是我们的系统对这个表的数据的实时性的敏感度也特别高，那这时候我们就需要用到【实时同步的实体缓存】，这个缓存中的数据在任何时候都与数据表中的数据是完全一致的。

   RefreshCache：如果数据表中的数据会发生变化（增删改），但是变化的频率非常低，而恰巧我们的系统对数据实时性的敏感度也不是特别高，那我们可以使用定时刷新的缓存。

   SubObjectCache：如果某个数据表的修改经常是Insert和Update操作，但是无论如何Update，每条记录有些固定栏位的值都是不会发生变化的，那我们可以把这些不会发生变化的栏位封装在一个【子对象SubObject】中，然后在内存中缓存这些子对象。

 

3．DataAccess层的职责是提供全面的资源访问功能支持，并向上层屏蔽资源的来源。

BEM（Business Entity Manager）子层负责从数据库中存取资源。

DB Adapter子层负责屏蔽数据库类型的差异。

ORM子层负责提供对象－关系映射的功能。

Relation子层提供ORM无法完成的基于关系（Relation）的数据访问功能。

 

4．Entity侧层跨越UI/BL&Platform/DataAccess层，在这些层之间传递数据。Entity侧层中包含三类Entity，如下图所示：

 

5.DB层可以采用数据库分散放置、读写分离策略来支持超大并发。图中数据库名称，M代表Master（主库），S代表Slave（从库）。

 

6.Tools层，架构图中还一个虚线表示的Tools层，之所以用虚线，是因为它并不真的是系统交付的一部分，它并不实现系统的逻辑功能。但它的存在是如此的重要，特别是在我们的开发和测试阶段。它的主要作用有：

（1）DataMonitor：能将数据库中最重要的信息方便的呈现给工程师，比如重要表和超大表的记录数等。

（2）DataChecker：直接对数据库中的数据进行完整性、一致性检查。使我们能最及时的发现业务逻辑在数据处理方面的重大失误和错漏。

（3）DataRepairer：当发现了数据错误并对程序的bug进行修正后，Tools能够对数据进行补充或修复。以使后续开发和测试能立即继续进行。

 

三．Aspect

Aspect贯穿于系统各层，是系统的横切关注点。通常采用AOP技术来对横切关注点进行建模和实现。

1．Securtiy Aspect：用于对整个系统的Security提供支持。

2．ErrorHandling Aspect：整个系统采用一致的错误/异常处理方式。

3．Log Aspect：用于系统异常、日志记录、业务操作记录等。

（1）通常我们会记录相邻两层的交互接口所引发的所有异常的详细信息，包括方法调用的堆栈帧、调用方法的参数的具体值。（参考这里）

（2）通常我们会跟踪相邻两层的交互接口的每个方法执行所消耗的时间，用于检查系统的性能瓶颈在哪些地方。（参考这里）

（3）通常我们会记录所有数据库访问异常的详细信息，包括sql语句内容、各参数的具体值。（参考这里）

（4）在测试阶段，通常我们会记录所有每个事务访问数据表的顺序，通过对比这些顺序，我们可以发现可能出现死锁的地方，从而加以调整。（DataRabbit内置支持）

（5）另外，一些重要的作业操作我们也会记录到日志。

 

四．规则

1．系统各层次及层内部子层次之间都不得跨层调用。

2．使用Entity object 在各个层之间传递数据，而不是关系型的DataSet。只有在特殊情况下，才将UI绑定到DataTable，比如返回的结果集没有Entity与之对应的时候。

3．UI层和BL层禁止出现任何SQL语句。

4．对于每一个数据库表（Table）都有一个DB Entity class与之对应，针对每一个Entity class都会有一个BEM Class与之对应。

5．有些跨数据库或跨表的操作（如复杂的联合查询）也需要由相应的BEM Class来提供支持。

6．对于相对简单的系统，可以考虑将Business Function子层和Business Flow 子层合并为一个。

 

五．错误与异常

        异常可以分为系统异常（如网络突然断开）和业务异常（如用户的输入值超出最大范围），业务异常必须被转化为业务执行的结果。

1．     DataAccess层不得向上层隐藏任何异常（该层抛出的异常几乎都是系统异常）。

2．     要明确区分业务执行的结果和系统异常。比如验证用户的合法性，如果对应的用户ID不存在，不应该抛出异常，而是返回（或通过out参数）一个表示验证结果的枚举值，这属于业务执行的结果。但是，如果在从数据库中提取用户信息时，数据库连接突然断开，则应该抛出系统异常。

3．     在有些情况下，BL层应根据业务的需要捕获某些系统异常，并将其转化为业务执行的结果。比如，某个业务要求试探指定的数据库是否可连接，这时BL就需要将数据库连接失败的系统异常转换为业务执行的结果。

4．     UI层(包括Service层)除了从调用BL层的API获取的返回值来查看业务的执行结果外，还需要截获所有的系统异常，并将其解释为友好的错误信息呈现给用户。

5．     当WebService的参数或返回值需要是复杂类型――即架构图中的Service Entity，则Service Entity应该在对应的*.EntranceParaDef.dll中定义。WebService定义的方法中的复杂类型应该使用Xml字符串代替，而Xml字符串和复杂类型对象之间的转换应当在*.Entrance.dll中实现。

       最后，系统架构的思想是重要的，但是架构不能纸上谈兵、不能脱离实践。

 

      不知您有何补充或建议，请指点一二，呵呵。