点击上方红色字体，选择“加星标公众号”
优质文章，第一时间送达
作者 |
来源|urlify.cn/V3U7zm
软件架构和设计模式之间的区别
很多程序员经常将软件架构与设计模式混淆，比如认为MVC架构就是一种设计模式。 事实上，它们是完全不同的概念软件。 软件架构一般考虑代码重用，而设计模式则考虑设计重用，应用框架则介于两者之间。 部分代码复用，部分设计复用，有时分析也可以复用。 软件开发过程中的重用分为三个级别。
(1)内部复用：即共同使用的具体块在同一个应用上复用。
(2)代码复用：将正式的通用模块组合成一个库或工具集，可用于多个应用和领域。
(3)架构复用：即为专用领域提供通用的或现成的基础设施，以获得最高级别的可复用性。
软件架构和设计模式可能看起来很相似，但它们有根本的不同。 设计模式是对在一定环境下重复出现的问题的描述以及问题的解决方案。 它比软件架构更具体； 软件架构可以用代码来表达，也可以直接执行或重用。 ，只有实例可以用代码表达。 设计模式是比软件架构更小的元素。 软件架构通常富含一种或多种设计模式。 一个软件架构总是针对特定的应用领域，但相同的设计模式可以适用于不同的应用。 可以说，软件架构就是应用程序，而设计模式就是开发应用程序的具体方式。 我们经常使用的软件架构包括MVC架构、ORM架构等。
三层架构
一般的三层架构（3-TierArchitecture）将整个业务应用从下到上定义为数据访问层（DataAccessLayer，DAL）、业务逻辑层（BusinessLogicLayer，BLL）和表示层（UserInterfaceLayer，UI）。 区分层次的目的是为了凸显“高聚合、低耦合”的设计理念。 在软件架构设计中，分层结构是最常见也是最重要的结构。
三层架构的编程模型
三层架构的编程模型如下
在这三个层次中，系统的主要功能和业务逻辑都是在业务逻辑层处理的。
1. 表示层
表示层也称为表示层。 它位于三层结构的最底层，与用户直接接触，主要是B/S信息系统中的Web浏览页面。 作为网页浏览页面，表示层的主要功能是实现系统数据的输入和输出。 在这个过程中，无需使用逻辑判断操作，就可以将数据传输到业务逻辑层进行数据处理。 处理后，结果将反馈到表示层。 也就是说，表现层实现用户界面功能，沟通反馈用户需求，并利用业务逻辑层或Model进行调试，保证用户体验。
2.业务逻辑层
业务逻辑层的作用是对具体问题进行逻辑判断并执行操作。 表示层接收到用户指令后，会连接到数据访问层。 业务逻辑层位于三层架构中表示层和数据访问层的中间，也是表示层和数据访问层之间的桥梁。 数据的更改、获取、删除等功能，并将处理结果反馈给表示层，实现软件功能。
3.数据访问层
数据访问层是数据库的主控制系统，实现数据的缩减、删除、修改、查询等操作，并将操作结果反馈给业务逻辑层。 在实际操作过程中，数据访问层没有逻辑判断能力。 为了实现代码编译的严谨性，提高代码阅读水平软件设计模式有哪些，软件开发人员通常会在这一层编译SQL语句，以保证数据访问层的数据处理功能。
三层架构的异同
1、优点
（1）有利于系统的去中心化开发。 每一层可以由不同的人员开发。 只要遵循socket标准，就可以使用相同的对象模型实体类，这样可以大大提高系统的开发速度。
（2）很容易用新的实现替换原来级别的实现，有利于标准化。
（3）有利于各层逻辑的代码复用，增加层与层之间的依赖关系。
(4) 阻止表示层直接访问数据访问层，表示层只与业务逻辑层连接，增强了数据安全性。
(5)方便的系统移植。 如果要将C/S系统改成B/S系统，只需要改变三层架构的表示层即可。 业务逻辑层和数据访问层可以很容易地移植到网络上，几乎不需要做任何改变。
（6）项目结构更加清晰，分工更加明确，大大增加了维护成本，减少了维护时间。
2、缺点
(1)提高了系统的性能，这是不言而喻的。 如果不采用分层结构，很多业务可以直接访问数据库来获取相应的数据，但现在必须通过中间层来完成。
(2)有时会引起级联变化。 这些变化在自上而下的方向上尤其明显。 如果需要在表示层减少某个功能，为了保证其设计符合层次结构，可能需要在相应的业务逻辑层和数据访问层减少相应的代码。
(3)降低开发成本。
ORM框架
ORM（ObjectRelationalMapping，对象关系映射）是一种解决面向对象和关系数据库之间不匹配的技术。 简单来说，ORM通过描述对象与数据库之间映射关系的元数据，手动将程序中的对象持久化到关系数据库中。 实现持久化的一个相对简单的解决方案是使用硬编码方法为每个可能的数据库访问操作提供单独的方法。 这个操作是在三层架构中的数据访问层完成的。 因此，ORM框架是专门针对数据操作层设计的。
ORM架构的编程模型
ORM框架的编程模型如右图所示。
ORM 方法基于四个核心原则。
(1)简单：ORM以最基本的方式对数据进行建模。 例如，ORM会将MySQL表映射到Java类（模型），表的主键就是这个类的成员变量。
（2）精确：ORM使得所有MySQL数据表能够按照统一的标准精确映射到Java类，从而使系统在代码层面保持精确和统一。
(3) 易于理解：ORM使数据库结构文档化。 例如，MySQL数据库通过ORM转换为Java程序员可以理解的Java类。 Java程序员只能专注于自己擅长的Java水平（其实精通MySQL更好）。
（4）易用性：ORM包含了对持久对象进行CRUD操作的API，如创建create()、更新update()、保存save()、加载load()、查找find()等，即SQL 所有的查询都被封装成编程语言中的函数，通过函数的链式组合生成最终的SQL语句。 通过这些封装，可以防止不标准、冗余、不统一的SQL语句，防止很多人为的bug，也有利于编码风格的统一。 目前市面上采用ORM架构的经典框架有MyBatis、JPA、Hibernate等。
ORM的异同
1、优点
(1)提高开发效率，降低开发成本。
(2)使开发更加面向对象。
(3)便携式。
(4)可以方便地引入数据缓存等附加功能。
2、缺点
(1)关系型数据库手动映射，消耗系统性能。 虽然这里的性能成本比较小，但通常可以忽略不计。
(2)在处理多表联合查询、复杂的where条件等查询时，ORM的句型会显得复杂。
MVC框架
MVC的全称是ModelViewController，是模型（Model）-视图（View）-控制器（Controller）的缩写。 它指导我们以业务逻辑、数据、界面显示分离的方式组织代码，将业务逻辑集中到一个组件中。 在改进和定制界面和用户交互的同时，无需重写业务逻辑。 MVC 是专门为将传统输入、处理和输出功能映射到逻辑 GUI 结构而开发的。
编程模型
MVC框架提供了一种完全隔离HTML、CSS和Javascript等后端代码的编程方法。 各模块之间分工明确，职责明确。 下面详细介绍MVC模块。
(1)模型层用于处理部分应用数据逻辑，负责访问数据库中的数据。
(2)视口用于处理数据显示部分，根据模型数据渲染总视图。
(3)控制层用于处理用户交互，负责从视图读取数据、控制用户输入、发送数据到模型。
三层之间的主要交互流程如右图所示。
目前，市场上使用MVC框架的主流应用框架有SpringMVC、JSF、JFinal等。
MVC的异同
1、优点
(1)增加耦合度。 视口层和业务层是分离的，这允许修改视口代码而无需重新编译模型和控制器代码。 同样，应用程序的业务流程或业务规则的更改只需要更改MVC的模型层。 由于模型与控制器和视图分离，因此很容易更改应用程序的数据层和业务规则。 (2)增强代码的复用性。 随着IT技术的不断升级，应用程序需要以越来越多的形式被访问。 MVC 模式允许使用不同风格的各种视图来访问相同的服务器端代码，因为多个视图可以共享一个模型。 由于模型返回的数据没有格式化，因此同一个预制件可以被不同的接口使用。
(3)软件生命周期内的维护成本增加。 由于MVC的采用，开发和维护用户界面的技术集中度增加，视口和业务逻辑层的分离也使得Web应用程序更容易维护和更改。
(4)部署速度更快，使用MVC大大减少了开发时间。 它使Java 开发人员能够专注于业务逻辑，而界面开发人员能够专注于表示。
（5）有利于代码工程化管理，因为不同层各司其职，各层不同应用具有相同的特性，有利于通过工程化和工具来管理程序代码。 控制器还提供了一个好处，那就是控制器可以用来连接不同的模型和视图来完成用户的需求，这样控制器就可以为构建应用程序提供强大的手段。 给定一些可重用的模型和视图，控制器可以根据用户的需求选择模型进行处理，然后选择视图将处理结果显示给用户。
缺点
(1)没有明确的边界界定。 作为初学者完全理解 MVC 并不是一件容易的事。 使用MVC需要仔细的设计，因为它的内部原理比较复杂软件设计模式有哪些，所以需要花一些时间去思考。 同时，由于模型和视图必须严格分离，给调试应用程序带来了一定的困难。 每个预制构件在使用前都经过彻底测试。 (2)不适合大中型开发。 由于开发人员需要花费大量时间来理解 MVC 的设计理念，因此将 MVC 应用于不是很大的应用程序通常不会有回报。
(3)降低系统结构和实现的复杂度。 对于一个本来就很简单的界面，如果严格遵守MVC，将模型、视图和控制器分离，就会降低结构的复杂度，并且可能会形成过多的更新操作，从而提高运行效率。
(4)视图和控制器之间的连接太紧。 事实上，视图和控制器在设计上是相互分离的，但逻辑上它们是密切相关的组件。 如果视图不存在而没有控制器，则它是无用的，反之亦然，这使得视图和控制器的代码不能独立地重用。
(5)提高了视图对模型数据的访问效率。 根据操作套接字的模型，视图可能需要多次调用才能获取足够的显示数据。 不必要地频繁访问未更改的数据会提高操作性能。
RPC框架
RPC（Remote procedure Call，远程过程调用）是一种建立在Socket通信之上的设计。 一台机器上运行的主程序可以调用另一台机器上规划的子程序，如LPC（LocalProcedureCall，本地过程调用）。 也就是说有两台服务器A和B，服务器A上部署了一个应用程序，如果想调用服务器B上的应用程序提供的函数/方法，是不能直接调用的，因为不在同一个服务器上视频内存空间。 需要通过网络来表达和调用。 语义并传达调用的数据。
RPC架构的编程模型
RPC架构主要分为3部分，如右图所示。
（1）服务器（Provider）：运行在服务器上，提供服务套接字定义和服务实现类。
（2）注册中心：运行在服务器端，负责将本地服务发布为远程服务，管理远程服务，并提供给服务消费者。
（3）消费者（Consumer）：运行在客户端，通过远程代理对象调用远程服务。
上图中，服务器启动后，主动向注册中心注册机器IP、端口和服务列表； 当消费者启动时，注册中心获取服务器提供者的地址列表。 目前使用RPC框架的开源框架有很多，示例如下。
（1）应用级相关服务框架：阿里的Dubbo/Dubbox、GoogleGRPC、SpringBoot/SpringCloud。
（2）与远程通信相关的契约：RMI、Socket、SOAP（HTTPXML）、REST（HTTPJSON）。
（3）通信相关框架：Mina、Netty。
RPC 的异同
1、优点
(1)提高系统的可扩展性。
(2)提高系统的可维护性和持续交付能力。
(3)实现系统的高可用性。
2、缺点
(1) 开发一个已建立的RPC``框架的框架是很困难的。
(2)RPC框架的框架调用的成功率受到网络条件的限制。
(3)调用远程方法对于初学者来说比较困难。
未来架构演进之路
随着越来越多的人参与到互联网中，以前的单体应用架构越来越难以满足需求。 因此，分布式集群架构应运而生。 为此，分布式构建和开发成为了Web开发者必须掌握的技能之一。 该技术包括但不限于ZooKeeper、Dubbo、消息队列（ActiveMQ、Kafka、RabbitMQ）、NoSQL（Redis、MongoDB）、Nginx、分库分表MyCat、Netty等。分布式架构构建于RPC 架构的基础。 右边这张图大概很多人都看过，这是在Dubbo官网上找到的描述项目结构演变过程的图。
分布式架构是建立在RPC架构的基础上的。 右边这张图大概很多人都看过，这是在Dubbo官网上找到的描述项目结构演变过程的图。
它描述了每种架构所需的特定配置和组织。 当网站流量很小时，只需要一个应用程序，所有功能部署在一起，减少节点部署和成本。 我们一般采用单一应用架构。 后来出现了ORM框架，大大简化了增删改查的操作流程，提升了开发人员的工作效率。
随着用户数量减少，访问量逐渐减少，单个应用减少机器带来的加速度越来越小。 我们需要将应用拆分成多个互不干扰的应用来提高效率，于是垂直应用框架就出现了。 。 MVC框架是一个非常经典的加速后端页面开发的框架。
当垂直应用越来越多时，应用之间的交互是不可避免的。 将核心业务抽取出来作为独立的服务，逐渐生成稳定的服务中心，使后端应用能够更快地响应不断变化的市场需求，于是就有了分布式服务架构。 分布式架构下的服务数量逐渐减少。 为了提高管理效率，RPC架构应运而生。 RPC架构用于提高业务复用和集成。 分布式服务架构下，RPC架构是关键。
下一代框架将是流量估计框架抢占主流。 当服务越来越多时，小服务的容量评估、资源浪费等问题就越来越明显。 这时就需要减少一个调度中心，根据访问压力实时管理集群容量，提高集群的利用率。 采用SOA（Service-Oriented Architecture，面向服务的架构）架构来提升集群的利用率。 在资源调度和治理中心方面，SOA架构是关键。
粉丝福利：Java从入门到入门的学习路线图
长按上方微信二维码 2 秒
感谢您的支持
