常见的软件架构模型可以分为三种架构模型：3/N层架构，“框架+插件”架构，地理分布式架构。一。三种架构模型1.3/N层架构这是一个经典的多层架构模型。很难想象一个稍复杂或特别复杂的系统不使用分层架构。下图是一个经典的三层架构：如今，任何程序员都可以谈论三层/N层架构。这确实是解决系统复杂度的主流模型。但是，只要采用3/N层架构，是不是就一定能解决系统的复杂性呢？不一定，关键是你如何在你的系统中实现你的3/N层结构。采用3/N层架构后，我们还要解决以下几个很重要的问题：系统的可扩展性（可以从容应对变化）、系统的可维护性（因为系统不会用一次就扔掉）、Easydeployment（容易在需求变化时部署新的业务功能）和其他系统质量属性。然而，系统的可扩展性和可维护性是大多数软件系统必须解决的最重要的问题，这是由当前复杂多变的软件环境所决定的。正如满足功能需求是最基本的一样，采用3/N层架构只是万里长征的第一步。我采用“框架+插件”的架构来解决系统的可扩展性、可维护性和部署相关的问题。2、“框架+插件”架构经典的3/N层架构是对系统进行“纵向”分层，而“框架+插件”架构则是对系统进行“横向”分解。3/N层架构与“框架+插件”架构处于同等地位，没有任何依赖关系。但我经常一起使用它们。我们的系统可以看作是经过3/N层架构的垂直分层和“框架+插件”架构的水平分层之后的“网格”结构。某些网格可以被视为“扩展点”，我们可以在其中挂接“插件”。也就是说，我们可以在3/N层架构的每一层附加合适的插件来完成这一层的一些功能。例如：插件的主要特点是可以实现“热插拔”，即可以在不停止服务的情况下动态加载/移除/更新插件。因此，插件技术可以实现以下功能：(1)在UI层，我们可以在运行时替换一些用户界面或者加载与新服务相关的用户界面。在业务逻辑层，我们可以在运行时加载、替换或删除业务服务。在数据访问层，我们可以通过插件技术动态添加对新数据库类型（如MySQL）的支持。插件的“热插拔”功能使我们的系统具有很强的可扩展性。（2）如果我们需要升级系统，很多时候只需要升级我们的插件（比如业务插件），我们可以在服务运行的时候自动升级插件。(3)为了使系统成为“框架+插件”的结构，我们需要在系统的每一层进行“松耦合”设计，只有松耦合的组件才能做成“插件”.在3/N层架构中集成“框架+插件”架构，最难的是业务逻辑层的松耦合，这需要我们仔细分析业务需求之间的关系，将紧耦合的服务封装在一个component中，通过这种方式得到的相互独立的业务组件，可以有机会成为插件。这个过程可能需要不断的重构，设计重构。我们知道，松耦合的组件比那些紧耦合的组件更清晰，更容易维护。另外在架构模型中引入了AOP框架，对Aspect焦点（如处理日志记录、权限管理等）进行集中编程，使得Aspect代码不会混杂在正常的业务逻辑代码中，使代码清晰，可维护性进一步增强。从上面的介绍可以看出，通过结合3/N层架构和“框架+插件”架构，可以增强系统的扩展性、可维护性、简单的部署和升级能力。3.地域分布式架构我无意中发明了“地域分布式架构”这个词，哈哈，不知道意思对不对。地域分布式架构主要针对像LBS（location-basedservices）这样需要地域分布的应用。地域分布架构是基于上述3/N层架构和“框架+插件”架构，它们的关系如下：下面简单介绍一下地域分布架构。假设我们需要为全国各个主要城市提供我们的业务功能服务，假设每个城市都有大量的客户，每个城市访问的数据可能不同（比如每个城市的地图数据），则访问的功能也各不相同（例如，一些城市提供天气查询服务，而另一些则不提供）。客户除了通过我们的系统请求服务外，还可能希望通过我们的系统与他的好朋友进行交流，而他们的好朋友可能与他在同一个城市，也可能在另一个城市。好吧，让我们看看异地分布式架构是如何解决上述需求的。首先，地域分布式架构将用户管理和业务功能服务分离，分别负责应用服务器（AS）和功能服务器（FS），然后分别部署在不同的节点上。AS和FS均采用3/N层架构结合“框架+插件”架构。比如FS通过功能插件提供功能服务。比如武汉地区，我们部署了一个AS和一个FS，客户端连接到AS上请求服务。假设有一天，我们武汉的客户激增，压力最大的就是FS，因为所有的业务计算都是在FS上做的。这时，地域分布式的架构将允许我们在不停止任何服务的情况下动态添加FS服务器，新添加的FS服务器会自动注册到AS中。AS可以监控各个FS的负载情况（如CPU消耗、内存消耗），当有客户端请求到来时，AS会将请求交给负载最低的FS进行处理，实现了FS的负载均衡。如果ClientA需要和ClientB进行实时通信，这些通信消息会通过AS进行中转。上面大家看到的是我们系统在武汉的部署，其他城市也是一样的。这种情况下，AS和AS是相互独立的，但是经常会出现AS之间需要通信的情况，例如：ClientA需要和ClientE进行实时通信，或者ClientA需要请求一个唯一的服务等。地理分布式架构使用区域间应用服务器（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之间的通信；跨地域的服务请求等。感觉上面的架构设计主要偏向于J2EE系统设计。如果是通讯系统等其他设计，可能另当别论。
