@TOC

REST

REST详解：

• REST，表示性状态转移（representation statetransfer）。简单来说，就是用URI表示资源，用HTTP方法(GET, POST, PUT, DELETE)表征对这些资源的操作。 ①Resource: 资源，即数据，存在互联网上的可被访问的实体 ②Representation： 数据的某种表现形式，如HTML, JSON。 ③State Transfer：状态变化，HTTP方法实现
• RESTful API 就是REST风格的API。现在终端平台多样，移动、平板、PC等许多媒介向服务端发送请求后，如果不适用RESTfulAPI，需要为每个平台的数据请求定义相应的返回格式，以适应前端显示。但是RESTful API要求前端以一种预定义的语法格式发送请求，那么服务端就只需要定义一个统一的响应接口，不必像之前那样解析各色各式的请求。
• RESTful 是典型的基于HTTP的协议。它有哪些设计原则和规范呢？ ①资源。首先要明确资源就是网络上的一个实体，可以是文本、图片、音频、视频。资源总是以一定的格式来表现自己。文本用txt、html；图片用JPG、JPEG等等。而JSON是RESTful API中最常用的资源表现格式。 ②统一接口。对于业务数据的CRUD，RESTful 用HTTP方法与之对应 ③URI。统一资源标识符，它可以唯一标识一个资源。注意到，URL(统一资源定位符)是一种URI，因为它可以唯一标志资源。但URL != URI。应该说URL 是URI的子集。因为URL使用路径来唯一标识资源，这只是唯一标识资源的一种方式。还可以用一个唯一编号来标识资源，如example.html.fuce2da23。只不过这种方式并不被广泛使用。总之，要在概念上对URL和URI有所区分。 ④无状态。 所谓无状态是指所有资源都可以用URI定位，而且这个定位与其他资源无关，不会因为其他资源的变动而变化。这里引入一个幂等性的概念：无论一个操作被执行一次还是多次，执行后的效果都相同。比如对某资源发送GET请求，如果访问一次和访问十次获得的数据一样，那么就说这个请求具有幂等性。 ⑤URL中只能有名词，不能出现动词。这是因为在REST要求对资源的操作由HTTP 方法给出，而方法是由HTTP 请求报文头部给出的，自然不需要在URL中暴露操作方式。

RPC

RPC是什么？

• RPC 的全称是 Remote Procedure Call 是一种进程间通信方式。它允许程序调用另一个地址空间（通常是共享网络的另一台机器上）的过程或函数，而不用程序员显式编码这个远程调用的细节。
• 即程序员无论是调用本地的还是远程的，本质上编写的调用代码基本相同。
• 简单：RPC 概念的语义十分清晰和简单，这样建立分布式计算就更容易。
• 高效：过程调用看起来十分简单而且高效。
• 通用：在单机计算中过程往往是不同算法部分间最重要的通信机制。
• 通俗一点说，就是一般程序员对于本地的过程调用很熟悉，那么我们把 RPC 作成和本地调用完全类似，那么就更容易被接受，使用起来毫无障碍。
• 使用RPC的优点是不需要了解底层网络技术的协议，为通信程序之间携带信息数据。在网络通信模型中，RPC 跨越了传输层和应用层。RPC 使得开发包括网络分布式多程序在内的应用程序更加容易。

RPC框架或方案：

• RMI（JDK自带） ①JDK自带的RPC
• Dubbo/ Dubbox ①阿里巴巴公司开源的一个Java高性能优秀的服务框架，可以和Spring框架无缝集成，相关资料很丰富。 ②遗憾的是已经停止维护了，相关的依赖类比如Spring，Netty还是很老的版本。倒是当当网之类的再继续维维护，即Dubbox，并且实现了REST的支持。 ③Dubbo主要实现了服务治理，其他为保证集群安全、可维护、可测试等特性方面都没有很好的实现，但是几乎大部分关键组件都能找到第三方开源来实现。 ④所以，如果选择Dubbo请务必在各个环节做好整套解决方案的准备，不然很可能随着服务数量的增长，整个团队都将疲于应付各种架构上不足引起的困难，不能让各环节人员真正的专注于业务逻辑。 ⑤Dubbo建议使用Zookeeper作为服务的注册中心： <1>Zookeeper的作用：zookeeper用来注册服务和进行负载均衡，哪一个服务由哪一个机器来提供必需让调用者知道，简单来说就是ip地址和服务名称的对应关系。 <2>dubbo：是管理中间层的工具，在业务层到数据仓库间有非常多服务的接入和服务提供者需要调度，dubbo提供一个框架解决这个问题。 <3>zookeeper和dubbo的关系：Dubbo的将注册中心进行抽象，是得它可以外接不同的存储媒介给注册中心提供服务，有ZooKeeper，Memcached，Redis等。
• Hessian ①Hessian是一个轻量级的remotingonhttp工具，使用简单的方法提供了RMI的功能。相比WebService，Hessian更简单、快捷。采用的是二进制RPC协议，因为采用的是二进制协议，所以它很适合于发送二进制数据。
• Thrift ① Apache Thrift是Facebook开源的跨语言的RPC通信框架，目前已经捐献给Apache基金会管理，由于其跨语言特性和出色的性能，在很多互联网公司得到应用，有能力的公司甚至会基于thrift研发一套分布式服务框架，增加诸如服务注册、服务发现等功能。
• Motan ①新浪微博的服务治理框架，2016年5月开源，Motan是一个小而精的 RPC 框架，它的特点是简单、易用，是一个轻量级 RPC框架。 ②与Dubbo相比，Motan在功能方面并没有那么全面，也没有实现特别多的扩展。用的人比较少，功能和稳定性有待观望。对跨语言调用支持较差，主要支持java。
• Spring Cloud（推荐） ①Spring Cloud 完全基于Spring Boot，是一个非常新的项目，2016年才 1.0 release。版本提升非常迅速，发展势头良好。 ②Spring Cloud依然发扬了Spring Source整合一切的作风，以标准化的姿态将一些微服务架构的成熟产品与框架揉为一体，并继承了Spring Boot简单配置、快速开发、轻松部署的特点，让原本复杂的架构工作变得相对容易上手一些。服务调用方式是基于REST API的。 ③缺点是项目很年轻，很少见到国内业界有人在生产上成套使用，一般都是只有其中一两个组件。相关的技术文档大部分是英文的，案例也相对较少，使用的话需要摸索的时间会长一些。 ④下图是Spring Cloud和Dubbo的对比：
• gRPC ①Google发布的开源RPC框架，高性能、开源、将移动和HTTP/2放在首位的通用的RPC框架，基于HTTP/2, netty4.1, proto3, 拥有非常丰富而实用的特性，堪称RPC 框架的典范。 ②但它本身它不是分布式的，所以要实现上面的框架的功能需要进一步的开发。

实现 RPC 的程序包括 5 个部分：

• 这里 user 就是 client 端，当 user 想发起一个远程调用时，它实际是通过本地调用 user-stub。 user-stub负责将调用的接口、方法和参数通过约定的协议规范进行编码并通过本地的 RPCRuntime 实例传输到远端的实例。 远端RPCRuntime 实例收到请求后交给 server-stub 进行解码后发起本地端调用，调用结果再返回给 user 端。 ①User ②User-stub ③RPCRuntime ④Server-stub ⑤Server

RPC如何实现？

• RPC 的主要功能目标是让构建分布式计算（应用）更容易，在提供强大的远程调用能力时不损失本地调用的语义简洁性。
• 为实现该目标，RPC 框架需提供一种透明调用机制让使用者不必显式的区分本地调用和远程调用， 在前文中给出了一种实现结构，基于 stub的结构来实现。
• 下面我们将具体细化 stub 结构的实现，RPC 调用分以下两种： ①同步调用：客户方等待调用执行完成并返回结果。 ②异步调用：客户方调用后不用等待执行结果返回，但依然可以通过回调通知等方式获取返回结果。 若客户方不关心调用返回结果，则变成单向异步调用，单向调用不用返回结果。 ③异步和同步的区分在于是否等待服务端执行完成并返回结果。

具体调用细节：

• RPC服务方通过 RpcServer 去导出（export）远程接口方法，而客户方通过RpcClient去引(import)远程接口方法。 客户方像调用本地方法一样去调用远程接口方法，RPC 框架提供接口的代理实现，实际的调用将委托给代理 RpcProxy 。代理封装调用信息并将调用转交给 RpcInvoker 去实际执行。 在客户端的 RpcInvoker 通过连接器RpcConnector 去维持与服务端的通道 RpcChannel， 并使用 RpcProtocol执行协议编码（encode）并将编码后的请求消息通过通道发送给服务方。
• RPC 服务端接收器 RpcAcceptor 接收客户端的调用请求，同样使用 RpcProtocol 执行协议解码(decode)。解码后的调用信息传递给 RpcProcessor 去控制处理调用过程，最后再委托调用给 RpcInvoker 去实际执行并返回调用结果。

总结所有角色：

1、RpcServer
负责导出（export）远程接口
2、RpcClient
负责导入（import）远程接口的代理实现
3、RpcProxy
远程接口的代理实现
4、RpcInvoker
客户方实现：负责编码调用信息和发送调用请求到服务方并等待调用结果返回
服务方实现：负责调用服务端接口的具体实现并返回调用结果
5、RpcProtocol
负责协议编/解码
6、RpcConnector
负责维持客户方和服务方的连接通道和发送数据到服务方
7、RpcAcceptor
负责接收客户方请求并返回请求结果
8、RpcProcessor
负责在服务方控制调用过程，包括管理调用线程池、超时时间等
9、RpcChannel
数据传输通道

RPC框架要做到的最基本的三件事：

• 服务端如何确定客户端要调用的函数； ①在远程调用中，客户端和服务端分别维护一个【ID->函数】的对应表， ID在所有进程中都是唯一确定的。客户端在做远程过程调用时，附上这个ID，服务端通过查表，来确定客户端需要调用的函数，然后执行相应函数的代码。
• 如何进行序列化和反序列化； ①客户端和服务端交互时将参数或结果转化为字节流在网络中传输，那么数据转化为字节流的或者将字节流转换成能读取的固定格式时就需要进行序列化和反序列化，序列化和反序列化的速度也会影响远程调用的效率。
• 如何进行网络传输（选择何种网络协议）； ①多数RPC框架选择TCP作为传输协议，也有部分选择HTTP。如gRPC使用HTTP2。不同的协议各有利弊。TCP更加高效，而HTTP在实际应用中更加的灵活。

webservice和soap

webservice简述：

• 准确的来说，webservice不是一种技术，而是一种规范。是一种跨平台，跨语言的规范，用于不同平台，不同语言开发的应用之间的交互。
• WebService是个很重型的规范，它的应用协议是SOAP（简单对象访问协议）。
• 例子： ①比如在Windows Server服务器上有个C#.Net开发的应用A，在Linux上有个Java语言开发的应用B，现在B应用要调用A应用，或者是互相调用，用于查看对方的业务数据，就需要webservice的规范。 ②天气预报接口。无数的应用需要获取天气预报信息，这些应用可能是各种平台，各种技术实现，而气象局的项目，估计也就一两种，要对外提供天气预报信息，这个时候，如何解决呢？webservice就是出于以上类似需求而定义出来的规范。
• 我们一般就是在具体平台开发webservice接口，以及调用webservice接口，每种开发语言都有自己的webservice实现框架。 ①比如Java就有 Apache Axis1、Apache Axis2、Codehaus XFire、Apache CXF、Apache Wink、Jboss RESTEasyd等等。其中Apache CXF用的比较多，它也可以和Spring整合。
• 链接：为什么现在流行resultful,webservice无人问津?

SOAP协议：

• SOAP (Simple Object Access Protocol) 顾名思义，是一个严格定义的信息交换协议，用于在WebService中把远程调用和返回封装成机器可读的格式化数据。
• 事实上SOAP数据使用XML数据格式，定义了一整套复杂的标签，以描述调用的远程过程、参数、返回值和出错信息等等。而且随着需要的增长，又不得增加协议以支持安全性，这使SOAP变得异常庞大，背离了简单的初衷。
• 另一方面，各个服务器都可以基于这个协议推出自己的API，即使它们提供的服务及其相似，定义的API也不尽相同，这又导致了WSDL的诞生。  
• WSDL (Web Service Description Language)也遵循XML格式，用来描述哪个服务器提供什么服务，怎样找到它，以及该服务使用怎样的接口规范，简言之，服务发现。现在，使用WebService的过程变成，获得该服务的WSDL描述，根据WSDL构造一条格式化的SOAP请求发送给服务器，然后接收一条同样SOAP格式的应答，最后根据先前的WSDL解码数据。绝大多数情况下，请求和应答使用HTTP协议传输，那么发送请求就使用HTTP的POST方法。

REST与RPC与SOAP

REST与RPC区别：

• REST与RPC都是网络交互的协议规范。通常用于多个微服务之间的通信协议。

协议规范	通信协议	性能	灵活度
REST	HTTP	低	高
RPC	一般使用TCP	高	低

• HTTP相对更规范，更标准，更通用，无论哪种语言都支持http协议。如果你是对外开放API，例如开放平台，外部的编程语言多种多样，你无法拒绝对每种语言的支持，现在开源中间件，基本最先支持的几个协议都包含RESTful。 ①我们通过浏览器访问网站，就是通过Http协议。只不过浏览器把请求封装，发起请求以及接收响应，解析响应的事情都帮我们做了。如果是不通过浏览器，那么这些事情都需要自己去完成。

• RPC框架作为架构微服务化的基础组件，它能大大降低架构微服务化的成本，提高调用方与服务提供方的研发效率，屏蔽跨进程调用函数（服务）的各类复杂细节。让调用方感觉就像调用本地函数一样调用远端函数、让服务提供方感觉就像实现一个本地函数一样来实现服务。 ①RPC调用流程图：

• 相同点：底层通讯都是基于socket，都可以实现远程调用，都可以实现服务调用服务

• 不同点：Http中还定义了资源定位的路径，RPC中并不需要

SOAP 和 REST：

• SOAP 和 REST 都是 HTTP 协议
• 请求协议： ①SOAP 主要是用 XML 格式开发送请求，服务器返回的数据也是 XML 格式的 ②REST 可以使用xml、json、html格式发送请求，服务器返回的数据也是多种格式的
• 请求方式： ①SOAP 只能使用 post 方式 ②REST 使用 get，post，put，delete 四种请求
• HTTP 是 SOAP 和 REST 的载体

如何实现远程通信：

• 远程通信方式：Webservice、restful、dubbo。
• Webservice：效率不高基于soap协议（http协议的soap形式），其主要的特点是跨语言、跨平台的。项目中不推荐使用，可用于不同公司间接口的调用。
• 使用restful形式的服务：http协议的rest形式+json。很多项目中应用。如果服务太多，服务之间调用关系混乱，需要治疗服务。
• 使用dubbo：使用rpc协议进行远程调用，直接使用socket通信。传输效率高，并且可以统计出系统之间的调用关系、调用次数。使用Java语言开发，只能用于Java语言开发的项目间的通信，不具备跨语言，跨平台的特点！

Spring Cloud与方案

Spring Cloud核心组件在微服务架构中分别扮演的角色：

• Eureka（服务注册）：各个服务启动时，Eureka Client都会将服务注册到Eureka Server，并且Eureka Client还可以反过来从Eureka Server拉取注册表，从而知道其他服务在哪里
• Ribbon（负载均衡）：服务间发起请求的时候，基于Ribbon做负载均衡，从一个服务的多台机器中选择一台
• Feign（服务调用）：基于Feign的动态代理机制，根据注解和选择的机器，拼接请求URL地址，发起请求
• Hystrix（服务熔断）：发起请求是通过Hystrix的线程池来走的，不同的服务走不同的线程池，实现了不同服务调用的隔离，避免了服务雪崩的问题
• Zuul（网关路由）：如果前端、移动端要调用后端系统，统一从Zuul网关进入，由Zuul网关转发请求给对应的服务
• 链接：Spring Cloud原理详解

电商网站支付订单业务场景举例：

• 流程： ①创建一个订单后，如果用户立刻支付了这个订单，我们需要将订单状态更新为“已支付” ②扣减相应的商品库存 ③通知仓储中心，进行发货 ④给用户的这次购物增加相应的积分
• 针对上述流程，我们需要有订单服务、库存服务、仓储服务、积分服务。整个流程的大体思路如下： ①用户针对一个订单完成支付之后，就会去找订单服务，更新订单状态 ②订单服务调用库存服务，完成相应功能 ③订单服务调用仓储服务，完成相应功能 ④订单服务调用积分服务，完成相应功能
• 下图这张图清晰表明了各服务间的调用过程：
• Spring Cloud的5个核心组件通过一张图串联起来，再来直观的感受一下其底层的架构原理：

Spring Cloud除了5大核心组件之外还有其他组件：

• 分布式事务： ①分布式事务用于在分布式系统中保证不同节点之间的数据一致性。分布式事务的实现有很多种，最具有代表性的是由Oracle Tuxedo系统提出的XA分布式事务协议。 ②XA协议包含两阶段提交（2PC）和三阶段提交（3PC）两种实现。 ③链接： <1>什么是分布式事务？ <2>分布式事务六种解决方案
• 分布式配置： ①微服务意味着要将单体应用中的业务拆分成一个个子服务，每个服务的粒度相对较小，因此系统中会出现大量的服务。 ②由于每个服务都需要必要的配置信息才能运行，所以一套集中式的，动态的配置管理设施是必不可少的。 ③链接：为什么需要分布式配置中心？
• 分布式消息：也就是消息中间件。
• 分布式追踪： ①分布式追踪系统能够从头到尾地追踪跨越了多个应用、服务、数据库以及像代理这样的中间件的分布式软件的请求。它能帮助你更深入地理解系统中到底发生了什么。追踪系统以图形化的方式，展示出每个已知步骤以及某个请求在每个步骤上的耗时。 ②常见的业界开源解决方案： <1>Dapper（谷歌） <2>Zikpin，与Spring Cloud Sleuth结合的比较好 <3>Eagleeye（阿里） <4>pinpoint <5>skywalking ③Zipkin 是一个开放源代码分布式的跟踪系统，由Twitter公司开源，它致力于收集服务的定时数据，以解决微服务架构中的延迟问题，包括数据的收集、存储、查找和展现。每个服务向zipkin报告计时数据，例如用户每次请求服务的处理时间等，可方便的监测系统中存在的瓶颈。zipkin会根据调用关系通过Zipkin UI生成依赖关系图。 ④Spring Cloud Sleuth 为服务之间调用提供链路追踪。通过Sleuth可以很清楚的了解到一个服务请求经过了哪些服务，每个服务处理花费了多长。从而让我们可以很方便的理清各微服务间的调用关系。此外Sleuth可以帮助我们： <1>「耗时分析」: 通过Sleuth可以很方便的了解到每个采样请求的耗时，从而分析出哪些服务调用比较耗时; <2>「可视化错误」: 对于程序未捕捉的异常，可以通过集成Zipkin服务界面上看到; <3>「链路优化」: 对于调用比较频繁的服务，可以针对这些服务实施一些优化措施。 ⑤Sleuth与Zipkin关系：Spring Cloud Sleuth可以结合Zipkin，将信息发送到Zipkin，利用Zipkin的存储来存储信息，利用Zipkin UI来展示数据。

方案详解： Spring Cloud alibaba 技术架构：

• 链接：Spring Cloud alibaba 技术架构详解

负载均衡和nginx

什么是负载均衡：

• Loadbalancing，即负载均衡，是一种计算机技术，用来在多个计算机（计算机集群）、网络连接、CPU、磁盘驱动器或其他资源中分配负载，以达到最优化资源使用、最大化吞吐率、最小化响应时间、同时避免过载的目的。

为什么需要负载均衡 ：

• 我们在日常生活中经常免不了要去一些比较拥挤的地方，比如地铁站、火车站、电影院、银行等。无论是买票，还是排队入场，这些场所一般都会设置多个服务点或者入口的。如果没有人引导的话，大多数情况下，最近的入口会挤满人。而那些距离较远的服务点或者入口就宽松很多。
• 这种情况下，就会大大浪费资源，因为如果可以把这些排队的人很好的分散到各个入口的话会大大缩短排队时间。其实，网站的建设也是一样的。为了提升网站的服务能力，很多网站采用集群部署，就像话剧院有多个入口一样。这时候，就需要一个协调者，来均衡的分配这些用户的请求，可以让用户的可以均匀的分派到不同的服务器上。

网络中的负载均衡：

• 负载均衡（Load Balance），意思是将负载（工作任务，访问请求）进行平衡、分摊到多个操作单元（服务器，组件）上进行执行。是解决高性能，单点故障（高可用），扩展性（水平伸缩）的终极解决方案。
• 

OSI系统互连参考模型：

• 我们可以很明确的一点是，负载均衡是要在网络传输中做文章的。而要在网络传输过程搞事情，那么这七层模型就势必躲不开。

• 常见的实现方式中，主要可以在应用层、传输层、网络层和数据传输层做文章。所以，工作在应用层的负载均衡，我们通常称之为七层负载均衡、工作在传输层的我们称之为四层负载均衡。
• 二层负载均衡 ①负载均衡服务器对外依然提供一个VIP（虚IP），集群中不同的机器采用相同IP地址，但是机器的MAC地址不一样。当负载均衡服务器接受到请求之后，通过改写报文的目标MAC地址的方式将请求转发到目标机器实现负载均衡。
• 三层负载均衡 ①和二层负载均衡类似，负载均衡服务器对外依然提供一个VIP（虚IP），但是集群中不同的机器采用不同的IP地址。当负载均衡服务器接受到请求之后，根据不同的负载均衡算法，通过IP将请求转发至不同的真实服务器。
• 四层负载均衡 ①四层负载均衡工作在OSI模型的传输层，由于在传输层，只有TCP/UDP协议，这两种协议中除了包含源IP、目标IP以外，还包含源端口号及目的端口号。四层负载均衡服务器在接受到客户端请求后，以后通过修改数据包的地址信息（IP+端口号）将流量转发到应用服务器。
• 七层负载均衡 ①七层负载均衡工作在OSI模型的应用层，应用层协议较多，常用http、radius、dns等。七层负载就可以基于这些协议来负载。这些应用层协议中会包含很多有意义的内容。比如同一个Web服务器的负载均衡，除了根据IP加端口进行负载外，还可根据七层的URL、浏览器类别、语言来决定是否要进行负载均衡。

负载均衡工具:

• 市面上有很多开源的负载均衡的工具或软件，基本都是基于前面提到的方案实现的，大多数是工作在第七层和第四层的。Nginx/LVS/HAProxy是目前使用最广泛的三种负载均衡软件。
• 负载均衡详解
• LVS ：LVS主要用来做四层负载均衡 ①LVS（Linux Virtual Server），也就是Linux虚拟服务器, 是一个由章文嵩博士发起的自由软件项目。使用LVS技术要达到的目标是：通过LVS提供的负载均衡技术和Linux操作系统实现一个高性能、高可用的服务器群集，它具有良好可靠性、可扩展性和可操作性。从而以低廉的成本实现最优的服务性能。
• Nginx ：Nginx主要用来做七层负载均衡 ①Nginx（发音同engine x）是一个网页服务器，它能反向代理HTTP, HTTPS, SMTP, POP3, IMAP的协议链接，以及一个负载均衡器和一个HTTP缓存。。
• HAProxy ：HAProxy主要用来做七层负载均衡 ①HAProxy是一个使用C语言编写的自由及开放源代码软件，其提供高可用性、负载均衡，以及基于TCP和HTTP的应用程序代理

jar文件和META-INF目录

jar文件简介：

• 开发中可以直接使用java class文件来运行程序，不过这样不太方便，所以出现了jar文件来提供发布和运行。
• jar文件实际上是class文件的zip压缩存档，有很多工具都可以操纵这种格式的文件，但是jar文件本身并不能表达应用程序的便签信息。
• 所以jar文件就使用了META-INF目录来提供存档的便签信息。 ①JAR包比普通zip文件多了一个META-INF文件夹，该文件夹下包含了一个MANFEST.MF文件。
• JAR包的结构如下图所示：

META-INF目录简介：

• META-INF相当于一个信息包，目录中的文件和目录获得Java2平台的认可与解释，用来配置应用程序、扩展程序、类加载器和服务manifest.mf文件，在用jar打包时自动生成。 ①META-INF目录只有一个文件就是manifest.mf文件。
• jar文件中有一个特定的目录来存放标签信息：META-INF目录，主要应关注其中一个名叫manifest.mf的文件，它包含了jar文件的内容描述，在应用程序运行时向JVM提供应用程序的信息。
• jar文件都有一个默认产生的META-INF目录和其中的manifest.mf文件。​使用jar命令可以直接产生META-INF目录和manifest.mf文件。

Manifest-Version: 1.0 
Built-By: Dxy
Created-By: IntelliJ IDEA
Build-Jdk: 1.8.0_144

• 上面这些信息就是jar文件的描述信息： ①Manifest-Version：生成的manifest.mf文件的版本 ​②Built-By：文件的创建用户命名，在IDEA的配置文件中可以设置 ​③Created-By：文件的生成者，一般由jar命令行工具生成，这里显示的时idea ​④Bulid-Jdk：所使用的JDK环境
• 其实manifest.mf文件中的配置信息除了上面的四个之外还有很多的信息。以下是几个常见的属性：

一、一般属性
 
1：Signature-Vresion：定义jar文件的签名版本
 
2：Class-Path：内部的类搜索路径，提供给应用程序或者类装载器
 //外来jar包的位置
二、应用程序的相关属性
 
1、Main-Class：定义jar文件的入口类，该类必须可执行！一旦定义了该属性就可以使用
 //如果你将Jar中的META-INF文件夹删除，那么jar文件里边就没有MANIFEST.MF文件。
 //那么，java -jar就找不到main class.
 //没有META-INF你仍然可以创建一个Jar文件。
 //但是，当你想要执行jar文件的时候，这个jar是需要具备 META-INF/MANIFEST.MF的。

java -jar 程序名.jar 来运行该jar文件

• manifest.mf文件的格式： ①manifest 文件中的每一行都是 key－value 对应的:属性名开头，接着是 ":" ，然后是属性值，每行最多72个字符，如果需要增加，可以在下一行续行，续行以空格开头，以空格开头的行都会被视为前一行的续行。
• 总结一下： ①META-INF目录实际上就是描述jar文件中的信息的一个目录，目录中除了manifest.mf文件之外其实还是可以配置很多信息文件的，这些文件都是在应用程序运行的过程中向其提供jar文件的内容描述的。

序列化：JSON和Serialize

序列化的定义：

• 序列化：把对象转化为可传输的字节序列过程称为序列化。
• 反序列化：把字节序列还原为对象的过程称为反序列化。

为什么要序列化？

• 其实序列化最终的目的是为了对象可以跨平台存储，和进行网络传输。而我们进行跨平台存储和网络传输的方式就是IO，而我们的IO支持的数据格式就是字节数组。 ①本质上存储和网络传输都需要经过 把一个对象状态保存成一种跨平台识别的字节格式，然后其他的平台才可以通过字节信息解析还原对象信息。
• 因为我们单方面的只把对象转成字节数组还不行，因为没有规则的字节数组我们是没办法把对象的本来面目还原回来的，所以我们必须在把对象转成字节数组的时候就制定一种规则（序列化），那么我们从IO流里面读出数据的时候再以这种规则把对象还原回来（反序列化）。
• 如果我们要把一栋房子从一个地方运输到另一个地方去，序列化就是我把房子拆成一个个的砖块放到车子里，然后留下一张房子原来结构的图纸，反序列化就是我们把房子运输到了目的地以后，根据图纸把一块块砖头还原成房子原来面目的过程。

序列化的方式:

• 序列化只是一种拆装组装对象的规则，那么这种规则肯定也可能有多种多样，比如现在常见的序列化方式有： ①JDK（不支持跨语言） ②JSON ②XML ③Hessian ④Kryo（不支持跨语言） ⑤Thrift ⑥Protostuff ⑦FST（不支持跨语言）

序列化技术选型的几个关键点：

• 序列化协议各有千秋，不能简单的说一种序列化协议是最好的，只能从你的当时环境下去选择最适合你们的序列化协议，如果你要为你的公司项目进行序列化技术的选型，那么主要从以下几个因素。 ①协议是否支持跨平台： 如果你们公司有好多种语言进行混合开发，那么就肯定不适合用有语言局限性的序列化协议，要不然你JDK序列化出来的格式，其他语言并没法支持。 ②序列化的速度： 如果序列化的频率非常高，那么选择序列化速度快的协议会为你的系统性能提升不少。 ③序列化出来的大小： 如果频繁的在网络中传输的数据那就需要数据越小越好，小的数据传输快，也不占带宽，也能整体提升系统的性能。

Java 是如何实现序列化的？

• java 实现序列化很简单，只需要实现Serializable 接口即可
• 其中： ①static 属性不能被序列化。原因：序列化保存的是对象的状态，静态变量属于类的状态，因此 序列化并不保存静态变量。 ②Transient 属性不会被序列化。 ③序列化版本号serialVersionUID <1>JDK工具生成的serialVersionUID 是根据对象的属性信息生成的一个编号，这就意味着只要对象的属性有一点变动那么他的序列化版本号就会同步进行改变。 <2>这种情况有时候就不太友好，就像我们的软件一样，使用JDK生成的serialVersionUID，只要对象有一丁点改变serialVersionUID就会随着变更，这样的话用户就得强制更新软件的版本，用户不更新就使用不了软件。 <3>而大多数友好的情况也许是这样的，用户可以选择不更新，不更新的话用户只是无法体验新加的功能而已。 <4>而这种方式就需要我们自定义的版本号了，这样我就可以在新增了属性后不修改serialVersionUID，反序列化的时候只是无法或许新加的属性，并不影响程序运行。 ④父类、子类序列化问题 <1>序列化是以正向递归的形式进行的，如果父类实现了序列化那么其子类都将被序列化； <2>子类实现了序列化而父类没实现序列化，那么只有子类的属性会进行序列化，而父类的属性是不会进行序列化的。

JSON序列化：

• JSON，JavaScript Object Notation，一种更轻、更友好的用于接口(AJAX、REST等)数据交换的格式。JSON是结构化数据串行化的文本格式，作为XML的一种替代品，用于表示客户端与服务器间数据交换有效负载的格式。 ①它是从ECMAScript语言标准衍生而来的。JSON的设计目标是使它成为小的、轻便的、文本的，而且是JavaScript的一个子集。

json序列化和jdk序列化（Serializable）的区别：

• json可以跨语言，而jdk序列化仅限于java。
• 在java进程内的io，或者两个进程之间调用（比如dubbo）使用jdk的序列化会很方便，都是对象直接转对象，而json会序列化成字符串，失去了对象的特性，使用的话没有jdk序列化方便。

关于method的序列化：

• 方法不需要序列化。
• 因为方法本身是数据处理操作（而非数据存储操作），而序列化操作是对数据进行操作的。
• 如果你的实体类被反序列化成为有方法的对象，那么这个方法一样可用。

J2EE的概念以及容器概念总结

J2EE的概念：

• 整体来说，J2EE是java技术不断适应和促进企业级应用过程中的产物，是使用Java技术开发企业级应用的一种事实上的工业标准。它包含了许多的组件，主要可以简化并且规范应用系统的开发和部署，进而提高可移植性、安全性以及再用价值。

容器的概念：

• 广义上讲容器是用来包装或装载物品的贮存器(如箱、罐、坛)或者成形或柔软不成形的包覆材料。在编程领域中，容器提供组件运行的环境，容器本身可以提供一组服务，让组件按标准方式利用。这里的容器容器比现实中的更为抽象，但思想是想通的。

容器的分类：

• J2EE规范定义了四种容器，分别是：小程序（Applet）容器、应用程序客户机（ApplicationClient）容器、Web应用程序容器、EJB应用程序容器。开发B/S系统的人员，经常接触到的是Web应用程序容器和EJB应用程序容器。

• EJB容器 EJB容器是服务器端容器，包含的组件是EJB(EnterpriseJavaBeans)，作为J2EE的核心之一，它的主要作用是用于服务器端的商业逻辑实现。在EJB的规范定义中，定义了一个开发和部署分布式商业逻辑的框架。用以简化企业级应用的开发，使EJB容器具备可伸缩性、可移植性、分布式事务处理以及多用户等。 企业 Bean 分为三种类型：会话 Bean、实体 Bean 和消息驱动 Bean。会话 Bean 表示瞬态对象和进程，并且通常由单个客户机使用。实体 Bean 表示持久性数据，通常保留在数据库中。消息驱动 Bean 用于将消息异步传送到应用程序模块和服务中。 EJB到底是什么？

• Web容器 Web容器是服务器端容器，管理所有J2EE应用程序中JSP页面和Servlet组件的执行，JSP和Servlet都是Web服务器的功能扩展，接受Web请求并返回动态的Web页面。它是一种服务程序，就是为应用服务器组提供一个运行环境，使JSP、Servlet直接跟容器中的环境变量 接口交互，不必关注其他系统的问题。

• Applet容器 Applet是客户端容器，包含的组件为Applet。它是嵌在浏览器中的一种轻量级客户端，在一般情况下，只有当使用Web页面无法充分表现 数据或者应用界面的时候才会使用它。Applet是代替Web的一种手段，而且Applet无法使用J2EE的各种服务和API，这时为了安全性的考虑。 要注意的是，我们只能通过J2SE开发Applet。

• Application Client容器 也是一个客户端容器。Application Client相对于Applet是一种重量级的客户端，因为它能够使用J2EE的大部分Service和API，而Applet不能。

• J2EE通过这四种容器能够灵活的实现企业级的架构。在这里要说一下的是：在J2EE的各种服务和API中，JDBC和JCA用于企业资源(各种企业信息系统和数据库等)的连接，JAX-RPC、JAXR和SAAJ则是实现WebServices和Web Services连接的基本支持

J2EE中容器与服务器的区别：

• web容器只能来进行静态网页之间的交往，但是当需要显示JSP和Servlet的时候要用到web服务器，即：一般的情况下web容器和web服务器在一个软件（Tomcat）上就能体现出来。

• web服务器（Tomcat）和应用服务器（JBoss）之间的区别：web服务器主要用在显示层（JSP和servet），而应用服务器是用在业务逻辑层的，从某种意义上web服务器属于应用服务器的子集。

• J2EE应用服务器要实现J2EE的十三种规范。比如：JBoss就实现了J2EE的所有规范，而Tomcat没有全部实现，所以JBoss是J2EE应用服务器，而Tomcat不算是J2EE应用服务器。

• servlet服务器属于web服务器，用来管理servlet的生命周期，而应用服务器（Jboss）是将业务层的bean在容器中管理。

• tomcat属于web服务器，jboss，weblogic，webspere属于应用服务类。

JNDI概念：

• JNDI全称 Java Naming and Directory Interface（Java命名和目录接口）
• JNDI是Java平台的一个标准扩展，提供了一组接口、类和关于命名空间的概念。如同其它非常多Java技术一样，JDNI是provider-based的技术，暴露了一个API和一个服务供应接口（SPI）。这意味着不论什么基于名字的技术都能通过JNDI而提供服务。仅仅要JNDI支持这项技术。
• JNDI眼下所支持的技术包含LDAP、CORBA Common ObjectService（COS）名字服务、RMI、NDS、DNS、Windows注冊表等等。非常多J2EE技术，包含EJB都依靠JNDI来组织和定位实体。
• JDNI通过绑定的概念将对象和名称联系起来。
• 在一个文件系统中。文件名称被绑定给文件。在DNS中，一个IP地址绑定一个URL。在文件夹服务中。一个对象名被绑定给一个对象实体。
• JNDI中的一组绑定作为上下文来引用。每一个上下文暴露的一组操作是一致的。比如，每一个上下文提供了一个查找操作。返回指定名字的对应对象。每一个上下文都提供了绑定和撤除绑定名字到某个对象的操作。
• 链接：JNDI 的理解

EJB

EJB 概念的剖析:

• EJB 的官方解释： ①商务软件的核心部分是它的业务逻辑。业务逻辑抽象了整个商务过程的流程，并使用计算机语言将他们实现。 ②J2EE 对于这个问题的处理方法是将业务逻辑从客户端软件中抽取出来，封装在一个组件中。这个组件运行在一个独立的服务器上，客户端软件通过网络调用组件提供的服务以实现业务逻辑，而客户端软件的功能单纯到只负责发送调用请求和显示处理结果。在J2EE 中，这个运行在一个独立的服务器上，并封装了业务逻辑的组件就是EJB（Enterprise JavaBean）组件。

• 这其中我们主要关注这么几点，我们来逐条剖析： ①所谓："业务逻辑" ：我们注意到在EJB 的概念中主要提到的就是"业务逻辑"的封装，而这个业务逻辑到底是什么？说的那么悬乎，其实这个所谓的"业务逻辑"我们完全可以理解成执行特定任务的"类"。 ②所谓："将业务逻辑从客户端软件中抽取出来，封装在组件中……运行在一个服务器上"既然我们知道了"业务逻辑"的概念就是执行特定任务的"类"。 ③那么什么叫"从客户端软件中抽取出来"？其实，这个就是把原来放到客户端的"类"，拿出来不放到客户端了，放到一个组件中，并将这个组件放到一个服务器上去运行。

• 变成大白话就是，"把你编写的软件中那些需要执行制定的任务的类，不放到客户端软件上了，而是给他打成包放到一个服务器上了"。

• 总结：EJB 就是将那些"类"放到一个服务器上，用C/S 形式的软件客户端对服务器上的"类"进行调用。

EJB 的实现技术:

• EJB 是运行在独立服务器上的组件，客户端是通过网络对EJB 对象进行调用的。在Java 中，能够实现远程对象调用的技术是RMI，而EJB技术基础正是RMI。通过RMI 技术，J2EE 将EJB 组件创建为远程对象，客户端就可以通过网络调用EJB 对象了。

RMI概念：

• ​ Java RMI，即 远程方法调用(Remote Method Invocation)，一种用于实现远程过程调用(RPC)(Remote procedure call)的Java API，能直接传输序列化后的Java对象和分布式垃圾收集。它的实现依赖于Java虚拟机(JVM)，因此它仅支持从一个JVM到另一个JVM的调用。

• 在说RMI 之前，需要理解两个名词： ①对象的序列化 ②分布式计算与RPC

• 名词1：对象的序列化 对象的序列化概念：对象的序列化过程就是将对象状态转换成字节流和从字节流恢复对象。将对象状态转换成字节流之后，可以用java.io 包中的各种字节流类将其保存到文件中，或者通过网络连接将对象数据发送到另一个主机。总结一下就是：对象的序列化就是将你程序中实例化的某个类的对象，比如，你自定一个类MyClass，或者任何一个类的对象，将它转换成字节数组，也就是说可以放到一个byte 数组中，这时候，你既然已经把一个对象放到了byte数组中，那么你当然就可以随便处置了它了，用得最多的就是把他发送到网络上远程的计算机上了。如图所示：

• 名词2：分布式计算与RPC RPC 并不是一个纯粹的Java 概念，因为在Java 诞生之前就已经有了RPC 的这个概念，RPC是"Remote Procedure Call"的缩写，也就是"远程过程调用"。在Java 之前的大多数编程语言，如，Fortran、C、COBOL 等等，都是过程性的语言，而不是面向对象的。所以，这些编程语言很自然地用过程表示工作，如，函数或子程序，让其在网络上另一台机器上执行。说白了，就是本地计算机调用远程计算机上的一个函数。如下图所示。

• 名词3：二者结合就是RMI RMI 英文全称是"Remote Method Invocation"，它的中文名称是"远程方法调用"，它就是利用Java 对象序列化的机制实现分布式计算，实现远程类对象的实例化以及调用的方法。说的更清楚些，就是利用对象序列化来实现远程调用，也就是上面两个概念的结合体，利用这个方法来调用远程的类的时候，就不需要编写Socket 程序了，也不需要把对象进行序列化操作，直接调用就行了非常方便。远程方法调用是一种计算机之间对象互相调用对方函数，启动对方进程的一种机制，使用这种机制，某一台计算机上的对象在调用另外一台计算机上的方法时，使用的程序语法规则和在本地机上对象间的方法调用的语法规则一样。如图所示。

• 优点: 这种机制给分布计算的系统设计、编程都带来了极大的方便。只要按照RMI 规则设计程序，可以不必再过问在RMI 之下的网络细节了，如：TCP 和Socket 等等。任意两台计算机之间的通讯完全由RMI 负责。调用远程计算机上的对象就像本地对象一样方便。RMI 可将完整的对象作为参数和返回值进行传递，而不仅仅是预定义的数据类型。也就是说，可以将类似Java 哈西表这样的复杂类型作为一个参数进行传递。

• 缺点: 如果是较为简单的方法调用，其执行效率也许会比本地执行慢很多，即使和远程Socket机制的简单数据返回的应用相比，也会慢一些，原因是，其在网络间需要传递的信息不仅仅包含该函数的返回值信息，还会包含该对象序列化后的字节内容。

EJB 是以RMI 为基础的:

• 通过RMI 技术，J2EE 将EJB 组件创建为远程对象，EJB 虽然用了RMI 技术，但是却只需要定义远程接口而无需生成他们的实现类，这样就将RMI 技术中的一些细节问题屏蔽了。

• 但不管怎么说，EJB 的基础仍然是RMI，所以，如果你想了解EJB 的原理，只要把RMI的原理搞清楚就行了。你也就弄清楚了什么时候用EJB 什么时候不需要用EJB 了。

EJB 中所谓的"服务群集":

• 既然已经知道了，RMI 是将各种任务与功能的类放到不同的服务器上，然后通过各个服 务器间建立的调用规则实现分布式的运算，也就明白EJB所谓的"服务群集"的概念。

• 就是将原来在一个计算机上运算的几个类，分别放到其他计算机上去运行，以便分担运 行这几个类所需要占用的CPU和内存资源。同时，也可以将不同的软件功能模块放到不同的 服务器上，当需要修改某些功能的时候直接修改这些服务器上的类就行了，修改以后所有客户端的软件都被修改了。如图所示。

• 这种部署难道是无懈可击,图所示的这个"服务群集"看似"无懈可击"，其实是它这个图没有画完整，我们来把这个图画完整，再来看看有什么问题没有。

• 仔细观察之后，发现这种配置是有瓶颈的，如图所示,瓶颈在数据库端 。

• 现在如果想实现各个服务器针对同一个数据库的查询，那 么，不管你部署多少个功能服务器，都需要针对一个数据库服务器进行查询操作。也就是说，不管你的"计算"有多么"分布"也同样需要从一台服务器中取得数据。虽然，看起来将各个功能模块分布在不同的服务器上从而分担了各个主计算机的CPU 资源，然而，真正的瓶颈并不在这里，而是，数据库服务器那里。数据库服务器都会非常忙的应付各个服务器的查询及操作请求。

• 因此，通过这个结构图使我们了解到了EJB 根本不能完全解决负载的问题，因为，瓶颈 并不在功能模块的所在位置，而是在数据库服务器这里。

• 假如分开数据库，数据共享怎么办？有的读者一定会想到下面的这个应用结构，如图所示。

• 就是把每一个功能服务器后面都部署一个数据库，这样不就解决了上节所说的问题了吗？是的解决了数据库查询负载的问题，然而又出现了新的问题，就是"数据共享"的问题就 又不容易解决了。

• 网络面临较大压力，让你的应用慢如老牛我们再向前翻看看如图所示的这种架构中存在两个网络，一个是"A 网"一个是"B网"，这两个网络是不同的。"B 网"往往是局域网，一般带宽是10M/100M，速度较快，因此到还好说，然而，"A 网"往往是互联网或者是利用电信网络互联VPN 网或称广域网。"A 网" 的特点是带宽一般较窄，如ADSL 的网络仅仅有512K-2M 的带宽，由于广域网互联的成本较 高，所以一般不会有较高的带宽。而在这个网络上恰恰跑的是功能模块和客户端软件之间交换的数据，而这部分数据恰恰优势非常占用带宽的。

• 因此，这个应用架构其运行速度可以想见是多么的慢了。说句不夸张的话，有点想老牛 拉破车一样的慢。

• 目前在中国互联网做运营商网络管理系统的一个大公司，它的一个早期的网管软件就是 采用了这种架构来做的C/S 结构的应用系统。有一次，我作为评估者来对其应用系统进行评估，将其部署到一个非运营商大型的网络中的时候，便出现了我们上述描述的情况，速度已经到了难以忍受的地步，打开一个流量图，有时候需要用15分钟的时间才能呈现完整。然而，该系统在开发阶段并没有发现这个问题，为什么呢？因为，他们没有考虑到应用的实际用户连接网络的复杂性，从而给该公司造成较 大损失，以至于，这个开发架构被最终遗弃。

• EJB 活学活用，J2EE 不是必须使用EJB 。

• 通过上面小节的讲解似乎好像EJB 和开发Web 应用的B/S 结构的系统关系并不大，其实倒也不然。我们如果把"客户端程序"理解成某一台服务器，这样也是可以被应用的，而且， 如果是服务器互相之间做EJB的调用的话，也就不存在广域网带宽限制的问题了。

• 但是，如下情况尽量就不要使用EJB 了： ①较为简单的纯Web 应用开发，不需要用EJB。 ②需要与其他服务程序配合使用的应用，但调用或返回的自定义的网络协议可以解决的应用程序,不需要使用EJB。 ③较多人并发访问的C/S 结构的应用程序，尽量不要使用EJB。

总结：

• EJB实现原理： 就是把原来放到客户端实现的代码放到服务器端，并依靠RMI进行通信。
• RMI实现原理 ：就是通过Java对象可序列化机制实现分布计算。
• 服务器集群： 就是通过RMI的通信，连接不同功能模块的服务器，以实现一个完整的功能。

Spring与EJB：

• SSM（SpringMVC，Spring，Mybatis）SpringMVC进行流程控制，Spring进行业务流转，Mybatis进行数据库操作的封装。
• EJB（企业级JavaBean）是一个用来构筑企业级应用的服务器端可被管理组件， 设计目标与核心应用是部署分布式应用程序。
• EJB最初的设计思想考虑的是为分布式的应用服务的，分布式是针对大型应用构造的跨平台的协作计算，EJB最初的目的就是为这种计算服务的。但是软件发展到目前为止，大多数应用不需要采用分布式的解决方案，因此用EJB显得太臃肿了。
• Spring的出现恰恰为了解决这个问题。举个例子来说，EJB就是导弹，专门设计为打高空飞机。但是现在发现飞机不多。于是将它用来对付步兵，这个实在太糟糕了。这个时候有人发明了狙击步枪（Spring），发现对付步兵太好用了。
• 这两个框架有着一个共同的核心设计理念：它们的目标是为松耦合的POJO类提供中间件服务。框架通过在运行时截取执行环境，或将服务对象注射给POJO类的方式，将应用服务和POJO类“连接”起来。POJO类本身并不关注如何“连接”，而且也很少依赖于框架。
• 区别： ①EJB来源于官方，一经通过，即成为了标准，Spring来源于开源社区，是由广大开发者共同参与开发的 ②EJB是重量级的，而Spring是轻量级的，倡导零侵入性。 ③分布式能力。EJB主要被用来做分布式开发，但是SSM不具备分布式能力，但现在普遍使用更加轻量级的SpringBoot，以及后续出现的SpringCloud也具备了分布式能力。
• 联系：二者都是容器类框架。
• 总结： ①Sun公司发布的文档中对 EJB 的定义是：EJB 是用于开发和部署多层结构的、分布式的、面向对象的 Java 应用系统的跨平台的构件体系结构。 ②简单来说，EJB就是部署分布式系统用的，就是把A程序放在服务器上，通过B客户端来调用，并且是跨平台的。 ③因为 EJB 过于复杂和笨重，调试非常麻烦，现在都被轻量级的 RPC 框架（Dubbo）及轻量级 Restful 形式的分布式框架 （Spring Cloud） 替代了。

javaee, javaweb和javase的区别

JavaSE：

• Java SE 以前称为 J2SE。它允许开发和部署在桌面、服务器、嵌入式环境和实时环境中使用的 Java 应用程序。Java SE包含了支持 Java Web 服务开发的类，并为 Java Platform，Enterprise Edition（JavaEE）提供基础。

JavaEE：

• 例如 : 人们常说的SSH=Spring+Struts+Hibernate架构应用整合开发，XML,EJB,WebService，UML/Rose,Ajax,Weblogic,OracleJava EE 是在 Java SE 的基础上构建的，它提供 Web 服务、组件模型、管理和通信API，可以用来实现企业级的面向服务体系结构（service-oriented architecture，SOA）和 Web 2.0应用程序。

JavaWeb ：

• 例如 :JDBC，JSP，Servlet，JavaBean，Html，JavaScript，Session/Cookie，MVC设计模式，Tomcat，Eclipse+MyEclipse是指使用Java体系开发网站类应用，JSP属于JavaWeb范畴，JSP可以简单看作是前端页面嵌入Java代码，会被容器编译成Servlet，然后Servlet会输出HTML代码，最终成为我们看到的页面。

javaWeb和javaEE的关系：

• 说起JavaWeb，就想到另一个词：JavaEE。很多时候，这两个词是混用的，两者的概念并不能精确描述，这里，我尝试做一下区分
• JavaEE：全称Java平台企业版（Java Platform Enterprise Edition），是Sun公司为企业级应用推出的标准平台。JavaEE是个大杂烩，包括Applet、EJB、JDBC、JNDI、Servlet、JSP等技术的标准，运行在一个完整的应用服务器上，用来开发大规模、分布式、健壮的网络应用。
• JavaWeb：主要指以Java语言为基础，利用JavaEE中的Servlet、JSP等技术开发动态页面，方便用户通过浏览器与服务器后台交互。Java Web应用程序可运行在一个轻量级的Web服务器中，比如Tomcat。可以粗略地认为JavaWeb就是JavaEE的一部分，是成为JavaEE大师过程中的第一站。

MVC、MVP、MVVM模式的概念与区别

MVC框架:

• MVC全名是Model View Controller，是模型(model)－视图(view)－控制器(controller)的缩写，一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码，将业务逻辑聚集到一个部件里面，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。MVC被独特的发展起来用于映射传统的输入、处理和输出功能在一个逻辑的图形化用户界面的结构中。
• MVC 是一种使用 MVC（Model View Controller 模型-视图-控制器）设计创建 Web 应用程序的模式： ①Model（模型）表示应用程序核心（如数据库）。 ②View（视图）显示效果（HTML页面）。 ③Controller（控制器）处理输入（业务逻辑）。
• MVC 模式同时提供了对 HTML、CSS 和 JavaScript 的完全控制。
• Model（模型）是应用程序中用于处理应用程序数据逻辑的部分。通常模型对象负责在数据库中存取数据。
• View（视图）是应用程序中处理数据显示的部分。通常视图是依据模型数据创建的。
• Controller（控制器）是应用程序中处理用户交互的部分。通常控制器负责从视图读取数据，控制用户输入，并向模型发送数据。

MVP模式：

• 全称：Model-View-Presenter ；MVP是从经典的模式MVC演变而来，它们的基本思想有相通的地方Controller/Presenter负责逻辑的处理，Model提供数据，View负责显示。

MVP与MVC区别：

• 作为一种新的模式，MVP与MVC有着一个重大的区别：在MVP中View并不直接使用Model，它们之间的通信是通过Presenter(MVC中的Controller)来进行的，所有的交互都发生在Presenter内部，而在MVC中View会直接从Model中读取数据而不是通过Controller。
• 在MVC里，View是可以直接访问Model的！从而，View里会包含Model信息，不可避免的还要包括一些业务逻辑。在MVC模型里，更关注的Model的改变，而同时有多个对Model的不同显示，即View。所以，在MVC模型里，Model不依赖于View，但是View是依赖于Model的。不仅如此，因为有一些业务逻辑在View里实现了，导致要更改View也是比较困难的，至少那些业务逻辑是无法重用的。
• 虽然 MVC 中的 View 的确“可以”访问 Model，但是我们不建议在 View 中依赖 Model，而是要求尽可能把所有业务逻辑都放在 Controller 中处理，而 View 只和 Controller 交互。

MVVM框架：

• MVVM是Model-View-ViewModel的简写。它本质上就是MVC 的改进版。MVVM 就是将其中的View的状态和行为抽象化，让我们将视图 UI 和业务逻辑分开。
• 当然这些事 ViewModel 已经帮我们做了，它可以取出 Model 的数据同时帮忙处理 View中由于需要展示内容而涉及的业务逻辑。微软的WPF带来了新的技术体验，如Silverlight、音频、视频、3D、动画……，这导致了软件UI层更加细节化、可定制化。同时，在技术层面，WPF也带来了诸如Binding、Dependency Property、RoutedEvents、Command、DataTemplate、ControlTemplate等新特性。
• MVVM（Model-View-ViewModel）框架的由来便是MVP（Model-View-Presenter）模式与WPF结合的应用方式时发展演变过来的一种新型架构框架。它立足于原有MVP框架并且把WPF的新特性糅合进去，以应对客户日益复杂的需求变化。
• MVVM模式的组成部分： ①模型：模型是指代表真实状态内容的领域模型（面向对象），或指代表内容的数据访问层（以数据为中心）。 ②视图：就像在MVC和MVP模式中一样，视图是用户在屏幕上看到的结构、布局和外观（UI）。 ③视图模型：视图模型是暴露公共属性和命令的视图的抽象。MVVM没有MVC模式的控制器，也没有MVP模式的presenter，有的是一个绑定器。在视图模型中，绑定器在视图和数据绑定器之间进行通信。 ④绑定器：声明性数据和命令绑定隐含在MVVM模式中。在Microsoft解决方案堆中，绑定器是一种名为XAML的标记语言。绑定器使开发人员免于被迫编写样板式逻辑来同步视图模型和视图。在微软的堆之外实现时，声明性数据绑定技术的出现是实现该模式的一个关键因素。

MVVM与MVP区别：

• mvvm模式将Presener改名为View Model，基本上与MVP模式完全一致，
• 唯一的区别是，它采用双向绑定(data-binding): View的 变动，自动反映在ViewModel，反之亦然。这样开发者就不用处理接收事件和View更新的工作，框架已经帮你做好了。

总结：

• 这些模式是依次进化而形成MVC/MVP—>MVVM。
• 在以前传统的开发模式当中即MVC模式，前端人员只负责Model（数据库） View（视图） Controller/Presenter/ViewModel（控制器） 当中的View（视图）部分，写好页面交由后端创建渲染模板并提供数据。
• 随着MVVM模式的出现前端已经可以自己写业务逻辑以及渲染模板，后端只负责提供数据即可，前端所能做的事情越来越多，并且在开发项目当中工作所占比重更大。
• MVC、MVP、MVVM模式的概念与区别