我一直在谈论框架。 这句话听起来很贵。 大型企业的在线CTO演讲中也经常会提到这一点，但框架其实很多，涉及的概念也很复杂，光是经典的框架就有20多种。
软件体系结构是软件的基本结构。 体系结构的本质是管理的复杂性。 如果您认为体系结构不重要，则可能没有做复杂的事情，也可能没有管理复杂性。 体系结构模型很多，但常用的只有它。
1 .分层体系结构
2 .事件驱动体系结构
3 .微核心架构(也称为插件架构) ) )
4 .微服务架构
5 .云架构
一、层次结构
分层架构(layered architecture )是最常用的软件架构，也是事实上的软件标准架构。 如果不知道使用什么样的体系结构，就使用它。 有人说在软件的职业生涯中只使用了一个框架，那一定也是。 目前，许多产品的顶级体系结构几乎无一例外都是分层体系结构。
分层体系结构将软件分成几个级别，每个级别都有明确的作用和分工，不需要了解其他级别的详细信息。 层和层之间通过接口进行通信。 虽然没有明确约定必须将软件分成多少层，但最常见的是四层结构。
提供表达层(presentation )用户界面、实现负责视觉和用户交互的业务层(business )业务逻辑的持久层)持久性数据，SQL语句是这一层的数据库) 保存数据
有些软件在逻辑层和持久层之间添加了服务层(service )，提供不同业务逻辑所需的通用接口。 用户的请求依次通过这四个层次结构的处理，无法跳过任何一个层次结构。
分层体系结构的优点：
1、结构简单，容易理解和开发
2、不同技能的程序员分工，可以负责不同的层，天然适合很多软件公司的组织结构。 虽说框架决定组织，但实际上排在架子上3、结构多服从组织；
3、各层可以独立测试，其他层的接口通过模拟解决。
分层体系结构的缺点：
1、如果环境发生变化，则需要调整代码或追加功能时，通常需要时间和精力
2、部署麻烦，即使只修改一个地方，也经常需要重新部署整个软件，不容易持续发布
3、软件升级时，可能需要暂停整个服务；
4、扩展性差。 用户需求大幅增加时，必须依次扩展各层，各层内部耦合，因此扩展变得困难。
二、事件驱动架构
事件(Event )是指在状态发生变化时，由软件发出的通知，从而触发相关的操作。 “事件驱动体系结构”(event-driven architecture )是通过事件进行通信的软件体系结构。 分为四个部分：
接收事件队列(event queue )事件的门户调度程序(event mediator )将不同的事件分发到不同业务逻辑单元的事件通道(event channel )。 调度程序和处理器之间的联系通道事件处理器)事件处理器)实现业务逻辑，处理完毕后发布事件
在简单的项目中，可以将事件队列、分配器和事件通道集中在一起，整个软件分为事件代理和事件处理器。
事件驱动体系结构的优点：
1、分布式异步体系结构，事件处理器之间的高级解耦，软件可扩展性好
2、适用性广，可以使用各种类型的项目；
3、性能好，由于事件异步的本质，软件不易堵塞；
4、事件处理器可以独立加载和卸载，易于部署。
事件驱动体系结构的缺点：
1、异步编程(必须考虑远程通信、无法响应等情况)、开发比较复杂
2 .难以支持原子操作。 由于事件通过涉及多个处理器，因此回滚很困难
3、分布式和异步的特性使得该体系结构的测试变得困难。
事件驱动架构在通信产品中也得到了非常广泛的应用，典型的是状态机处理等。 事件驱动的体系结构不适合顶级体系结构，但更适合本地实施，几乎遍布通信软件的每个角落。
三、微核结构
“微内核体系结构”(microkernel architecture )也称为插件体系结构(插件体系结构)，是软件的内核)比较小，主要功能和业务
内核通常只包含系统执行的最小功能，插件是彼此独立的业务功能。 插件之间的通信应该尽量减少，避免相互依存
的问题。微核架构的优点：
1、良好的功能延伸性（extensibility），需要什么功能，开发一个插件即可；
2、功能之间是隔离的，插件可以独立的加载和卸载，使得它比较容易部署；
3、可定制性高，适应不同的开发需要；
4、可以渐进式地开发，逐步增加功能。
微核架构的缺点：
1、扩展性（scalability）差，内核通常是一个独立单元，不容易做成分布式；
2、开发难度相对较高，因为涉及到插件与内核的通信，以及内部的插件登记机制。
微核架构的设计和开发难度较高，这就注定它在企业产品中用得不多，虽然它的优点还不少。
四、微服务架构
微服务架构（microservices architecture）是面向服务架构（service-oriented architecture，缩写 SOA）的升级。每一个服务就是一个独立的部署单元（separately deployed unit）。这些单元都是分布式的，互相解耦，通过远程通信协议（比如REST、SOAP）联系。
微服务架构分成三种实现模式：
RESTful API 模式：服务通过 API 提供，云服务就属于这一类；RESTful应用模式：服务通过传统的网络协议或者应用协议提供，背后通常是一个多功能的应用程序，常见于企业内部；集中消息模式：采用消息代理（message broker），可以实现消息队列、负载均衡、统一日志和异常处理，缺点是会出现单点失败，消息代理可能要做成集群。微服务架构的优点：
1、展性好，各个服务之间低耦合；
2、容易部署，软件从单一可部署单元，被拆成了多个服务，每个服务都是可部署单元；
3、容易开发，每个组件都可以进行持续集成式的开发，可以做到实时部署，不间断地升级；
4、易于测试，可以单独测试每一个服务。
微服务架构的缺点：
1、由于强调互相独立和低耦合，服务可能会拆分得很细。这导致系统依赖大量的微服务，变得很凌乱和笨重，性能也会不佳；
2、一旦服务之间需要通信（即一个服务要用到另一个服务），整个架构就会变得复杂。典型的例子就是一些通用的 Utility 类，一种解决方案是把它们拷贝到每一个服务中去，用冗余换取架构的简单性；
3、分布式的本质使得这种架构很难实现原子性操作，交易回滚会比较困难。
微服务架构易开发、易测试、易部署，解耦，扩展性好，所以它成为当今的网红也绝非偶然。但服务变多变细，势必带来新的管理复杂性。好在当前工具工程能力的强大，管理复杂性在一定程度上可以通过自动化来解决。尽快如此，服务的划分仍然很重要，不要通过后端的自动化来掩盖前端的不足。
五、云架构
云架构（cloud architecture）主要解决扩展性和并发的问题，是最容易扩展的架构。云化软件架构的核心是数据库去中心化，数据变成可复制的内存数据单元。业务处理能力封装成一个个处理单元。业务流程和数据分离，业务状态外置，处理单元水平扩展。访问量增加，就新建处理单元；访问量减少，就关闭处理单元。由于没有中央数据库，所以扩展性的最大瓶颈消失了。由于每个处理单元的数据都在内存里，最好要进行数据持久化。云化架构对于云上应用的可靠性、高扩展和高并发至关重要。
这个模式主要分成两部分：处理单元（processing unit）和虚拟中间件（virtualized middleware）。
处理单元：实现业务逻辑；
虚拟中间件：负责通信、保持sessions、数据复制、分布式处理、处理单元的部署。
虚拟中间件又包含四个组件：
消息中间件（Messaging Grid）：管理用户请求和session，当一个请求进来以后，决定分配给哪一个处理单元；数据中间件（Data Grid）：将数据复制到每一个处理单元，即数据同步。保证某个处理单元都得到同样的数据；处理中间件（Processing Grid）：可选，如果一个请求涉及不同类型的处理单元，该中间件负责协调处理单元；部署中间件（Deployment Manager）：负责处理单元的启动和关闭，监控负载和响应时间，当负载增加，就新启动处理单元，负载减少，就关闭处理单云架构的优点：
1、高负载，高扩展；
2、动态部署。
云架构的缺点：
1、实现复杂，成本较高；
2、主要适合网站类应用，不合适大量数据吞吐的大型数据库应用；
3、较难测试。
以上是从技术本质，对架构进行分类。实际应用中，各种架构并不是孤立的，可以根据业务环境和业务诉求，对各种架构进行综合和嫁接。曾对微服务架构和微核架构进行综合，总结出微插件架构，适合于在资源受限的场景应用微服务的架构。另外，就如上面列举，每种架构都有其优点和缺点。优点不必多说，缺点则几乎都是通过工具工程能力的方法来规避，工具工程对软件架构非常重要。