我的架构经验小结（一）—— 常用的架构模型

     转自zhuweisky博客，点击查看原文

     传送门：

     我的架构经验小结（二）—— 关于三层架构

     我的架构经验小结（三）—— 深入三层架构

     我的架构经验小结（四）—— 实战中演化的三层架构

     我的架构经验小结（五）—— 日志记录

     经过这几年的积累，在系统架构方面逐渐积累了一些自己的经验，到今天有必要对这些经验作个小结。在我的架构思维中，主要可以归类为三种架构模型：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层架构的每一层都挂接适当的插件来完成该层的一些功能。如：

      

      但是我经常将它们结合在一起使用，我们的系统在经过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来进一步了解这些内容。