1.分层架构分层架构（layeredarchitecture）是最常见的软件架构，也是事实上的标准架构。如果您不知道要使用什么架构，请使用它。这种架构把软件分成几个水平的层，每一层都有明确的作用和分工，不需要知道其他层的细节。各层通过接口相互通信。虽然对于软件必须分为多少层并没有明确的约定，但四层结构是最常见的。表现层（presentation）：用户界面，负责视觉和用户交互业务层（business）：实现业务逻辑持久层（persistence）：提供数据，SQL语句放在这一层数据库（database）：保存数据一些软件之间在逻辑层和持久层之上，增加了一个服务层（service），提供不同业务逻辑需要的一些通用接口。用户的请求会依次经过这四层处理，任何一层都不能跳过。优点是结构简单，易于理解和开发。不同技能的程序员可以分工负责不同的层次。自然适合大多数软件公司的组织结构。每一层都可以独立测试，模拟其他层的接口，解决不足之处。一旦环境发生变化，需要调整代码或增加功能时，通常部署起来既麻烦又费时。即使只是修改了一个小地方，往往也需要重新部署整个软件。持续发布软件升级并不容易，可能需要暂停整个服务。可扩展性差。当大量用户请求增加时，每一层都必须依次扩展。由于每一层都是内部耦合的，所以扩展会很困难。2.事件驱动架构事件（event）是软件在状态发生变化时发出的通知。事件驱动架构是一种通过事件进行通信的软件架构。它分为四个部分。事件队列（eventqueue）：接收事件的入口分发器（eventmediator）：分发不同的事件到不同的业务逻辑单元事件通道（eventchannel）：分发器和处理器之间的通信通道事件处理器（eventprocessor）：实现业务逻辑，处理完成后会发送事件触发下一步操作对于简单的项目，事件队列、分发器和事件通道可以合二为一，整个软件分为两部分：事件代理和事件处理器。优点分布式异步架构，事件处理器之间解耦度高，软件扩展性好，适用性广，各种类型的项目都可以使用性能更好，因为事件的异步性，软件不容易阻塞事件处理器可以加载且独立卸载，易于部署缺点涉及异步编程（必须考虑远程通信、丢失响应等），开发相对复杂，难以支持原子操作，因为涉及到多个处理器的事件传递，是难以回滚分布式和异步特性使得这种架构更难测试3.微内核架构微内核架构（microkernelarchitecture），也称为“插件架构”，是指软件的核心比较小，主要功能和业务逻辑全部通过插件。内核（core）通常只包含系统运行所需的最少功能。插件之间是相互独立的，插件之间的通信应该减少到最低限度，以避免相互依赖的问题。优点良好的功能扩展性（extensibility），需要什么功能，开发一个插件即可。功能隔离，插件可独立加载卸载，更易于部署，可定制性强，适应不同开发需求可增量开发，逐步添加功能缺点可扩展性（scalability）较差，内核是通常是一个独立的单元，不容易做到分布式开发相对困难，因为涉及到插件与内核的通信，以及插件内部的注册机制4.MicroserviceArchitecture微服务架构（microservicesarchitecture）是面向服务架构（SOA）的升级。每个服务都是一个独立的部署单元（separatelydeploymentunit）。这些单元是分布式的，相互解耦，通过远程通信协议（如REST、SOAP）进行通信。微服务架构分为三种实现模式。RESTfulAPI模式：通过API提供服务，云服务属于此类RESTful应用模式：通过传统的网络协议或应用协议提供服务，其背后通常是一个多功能的应用程序，常见于内部的集中式消息传递企业：使用消息代理（messagebroker）可以实现消息队列、负载均衡、统一日志和异常处理。缺点是会出现单点故障。消息代理可以做成一个集群。优点是扩展性好，服务间耦合度低，易于部署。该软件已从单个可部署单元拆分为多项服务。每个服务都是一个易于开发的可部署单元，每个组件都可以以持续集成的方式开发。可实时部署，不间断升级，易于测试，每个服务都可以单独测试。由于强调相互独立和低耦合，服务可能会被拆分成细小的部分。这导致系统依赖大量的微服务，变得非常杂乱和繁琐，性能也会很差。一旦服务需要通信（即一个服务需要使用另一个服务），整个架构就会变得复杂。一个典型的例子是一些常见的Utility类。一种解决方案是将它们复制到每个服务，交换冗余以简化架构。分布式的特性使得这种架构很难实现原子操作，事务回滚会很困难。5、云架构云架构（cloudarchitecture）主要解决可扩展性和并发性问题，是最容易扩展的架构。它的高扩展性主要是因为它不使用中央数据库，而是将所有数据复制到内存中，成为一个可复制的内存数据单元。然后，将业务处理能力封装成处理单元。当访问次数增加时，创建一个新的处理单元；当访问次数减少时，处理单元关闭。由于没有中央数据库，可扩展性的最大瓶颈就消失了。由于每个处理单元的数据都在内存中，所以最好进行数据持久化。该模型主要分为两部分：处理单元（processingunit）和虚拟中间件（virtualizedmiddleware）。处理单元：实现业务逻辑虚拟中间件：负责处理单元的通信、维护会话、数据复制、分布式处理、部署。虚拟中间件由四个组件组成。MessagingGrid：管理用户请求和会话，并决定当请求进来时分配给哪个处理单元。数据中间件（DataGrid）：将数据复制到每个处理单元，即数据同步。确保一个处理单元得到相同的数据。处理中间件（ProcessingGrid）：可选，如果一个请求涉及不同类型的处理单元，中间件负责协调处理单元部署中间件（DeploymentManager）：负责处理单元的启动和关闭，监控负载和响应时间，当负载增加时，处理单元重新启动，当负载减少时，处理单元关闭。优点高负载，高扩展性缺点动态部署实现复杂，成本高主要适用于网站应用，不适合数据吞吐量大的大型数据库应用难以测试
