凡人多烦事01

这个屌丝很懒，什么也没留下！

热门标签

Saas项目技能点总结~~~~_saas项目的要点

作者：凡人多烦事01 | 2024-03-27 17:06:16

踩

saas项目的要点

1、Redis

特点：

速度快[存储在内存中]
支持丰富数据类型
丰富的特性
- 订阅发布 Pub / Sub 功能
- Key 过期策略
- 事务
- 支持多个 DB
- 计数
持久化存储
- Redis 提供 RDB 和 AOF 两种数据的持久化存储方案，解决内存数据库最担心的万一 Redis 挂掉，数据会消失掉。

redis的应用场景

• 缓存（数据查询、短连接、新闻内容、商品内容等等）
　　　　　　　　• 聊天室的在线好友列表
　　　　　　　　• 任务队列。（秒杀、抢购、12306等等）
　　　　　　　　• 应用排行榜
　　　　　　　　• 网站访问统计
　　　　　　　　• 数据过期处理（可以精确到毫秒
　　　　　　　　• 分布式集群架构中的session分离

常用数据结构

基础：

字符串 String
哈希Hash
列表List【有序】
集合Set【唯一无序】
有序集合 SortedSet【zset】

概念：

ridis:全称 Remote Dictionary Server ，是一个基于内存的高性能 Key-Value 数据库。

非关系型数据库：作为关系型数据库的良好补充。

分类	特点	代表产品
键值存储	数据一般存在内存中，读写速度快(10w/s)，适合作为缓存服务当成map即可	redis
文档型数据库	数据结构要求不严格，适合存储结构不确定或者价值较低的数据	mongodb
列存储数据库	查找速度快，更容易进行分布式扩展，适合作为文件存储服务	Hbase
图形数据库	使用“图结构”进行存储，适合做社交网络计算等等	Neo4j

* redis持久化【RDB、AOF】

Redis的高性能是由于其将所有数据都存储在了内存中，为了使Redis在重启之后仍能保证数据不丢失，需要将数据从内存中同步到硬盘中，这一过程就是持久化。Redis支持两种方式的持久化（RDB和AOF），可以同时使用。

RDB(快照方式)【默认方式】

在一定的间隔时间中，检测key的变化情况，然后持久化数据

.文件名称:dump.rdb

rdb默认的快照规则:在redis.windwos.conf文件

save 900 1 当15分钟之内有1个key发生变化就拍照

save 300 10 当300秒之内有10个key发生变化就拍照

save 60 10000 当60秒之内有1w个key发生变化就拍照

重启服务器后,默认是从rdb文件中恢复数据到内存中
AOF(追加命令到文件中),需要手动开启的,文件名称:appendonly.aof

以日志的形式记录服务器所处理的每一个写、删除操作，查询操作不会记录，以文本的方式记录，可以打开文件看到详细的操作记录。

可以每一次命令操作后，持久化数据

appendfsync always 每执行一个命令,就会把命令追加到文件中,和关系型数据库相似

appendfsync everysec 每一秒钟,把所有的操作命令追加到文件中

appendfsync no 不同步,等同于rdb

启动的时候需要指定配置文件启动，修改配置文件redis.windows.conf中 appendonly no 将他的值改成yes,重启服务器就生效,

虽然开启了aof,但是rdb依然能用.只不过是,当服务器重启的时候,从aof文件将数据恢复到内存中.

当我们正常关闭redis服务器的时候,他会通过不同的方式将内存中的数据保存到硬盘文件中.再次启动的时候,会去文件中把数据恢复到内存中.

若我们把redis作为缓存使用,建议使用rdb方式,高效; 若数据需要不时的持久化,建议使用aof方式.

缓存是允许有数据丢失.

bg save 做镜像全量持久化，AOF 做增量持久化。因为 bgsave 会耗费较长时间，不够实时，在停机的时候会导致大量丢失数据，所以需要 AOF 来配合使用。
在 Redis 实例重启时，会使用 bgsave 持久化文件重新构建内存，再使用 AOF 重放近期的操作指令来实现完整恢复重启之前的状态。
对方追问那如果突然机器掉电会怎样？
取决于 AOF 日志的属性的配置，如果不要求性能，在每条写指令时都 sync 一下磁盘文件，就不会丢失数据。但是在高性能的要求下每次都 sync 是不现实的，一般都使用定时sync ，比如 1 秒 1 次，这个时候最多就会丢失 1 秒的数据。
对方追问 bgsave 的原理是什么？
你给出两个词汇就可以了，fork 和 cow 。
fork 是指 Redis 通过创建子进程来进行 bgsave 操作。
cow 指的是 copy on write ，子进程创建后，父子进程共享数据段，父进程继续提供读写服务，写脏的页面数据。

Redis 单线程模型也能效率这么高

纯内存操作。
核心是基于非阻塞的 IO 多路复用机制。
- IO多路复用就是只有单个线程，通过跟踪每个IO流的状态，来管理多个IO流
单线程反而避免了多线程的频繁上下文切换问题。
- Redis 利用队列技术，将并发访问变为串行访问，消除了传统数据库串行控制的开销
Redis 全程使用 hash 结构，读取速度快，还有一些特殊的数据结构，对数据存储进行了优化，如压缩
表，对短数据进行压缩存储，再如，跳表，使用有序的数据结构加快读取的速度。

如何使用 Redis 实现分布式锁？

方案一：set 指令

先拿 setnx 来争抢锁，抢到之后，再用 expire 给锁加一个过期时间防止锁忘记了释放。
对于意外 crash 或者要重启维护：可以同时把 setnx 和 expire 合成一条指令来用的！

方案二：redlock

set 指令的方案，适合用于在单机 Redis 节点的场景下，在多 Redis 节点的场景下，会存在分布式锁丢失的问题。
所以，Redis 作者 Antirez 基于分布式环境下提出了一种更高级的分布式锁的实现方式：Redlock 。

对比 Zookeeper 分布式锁

从可靠性上来说，Zookeeper 分布式锁好于 Redis 分布式锁。
从性能上来说，Redis 分布式锁好于 Zookeeper 分布式锁。

集群

主从复制
哨兵模式

jedis

jedis就是集成了redis的一些命令操作，封装了redis的java客户端。提供了连接池管理【jedis连接资源的创建与销毁是很消耗程序性能】。一般不直接使用jedis，而是在其上在封装一层，作为业务的使用。如果用spring的话，可以看看spring 封装的 redis [Spring Data Redis]

在官方网站里列一些Java的客户端，有Jedis、Redisson、Jredis、JDBC-Redis、等其中官方推荐使用Jedis和Redisson。在企业中用的最多的就是Jedis

jedis对redis 相当于 jdbc对关系型数据库

2、ES；

3、dubbo

SOA:即面向服务的架构。有如下几个特点：分布式、可重用、扩展灵活、松耦合。

RPC:远程调用 ,是一个过程,不是一种技术.例如a服务器调用b服务器的过程. 例如比较出名的RPC框架有:dubbo和spring cloud(项目二中应用)

dubbo的工作流程是

使用zookeeper做注册中心
提供者启动之后,就会向注册中心注册服务,服务是通过dubbo的注解@Service暴露出去的
消费者启动之后,就会向注册中心订阅自己需要那些服务,这个是通过duobbo的注解@Reference体现的
注册中心会将这些服务提供者的信息返回给消费者
当消费者需要调用提供者的时候,默认会随机从这些提供者拿出来一个（）,然后远程调用它的方法即可.

在dubbo中还有一个监控中心,可以记录下消费者和提供者的一些信息,也可以设置权重和负载均衡的策略

监控中心dubbo-admin

查看有哪些提供者和消费者,查看调用的次数(需要配置),调节提供者的权重(负载均衡)

SOA和微服务得区别

SSM传统项目：并发压力有限 tomcat8.0 （1000）

Dubbo：基于RPC远程调用的长连接，不是Http协议的（每次发送内容没有head头信息），效率高

1.基于长连接

2.效率高

3.必须是Java的

zookeeper注册中心一般是奇数，因为有选举机制（偶数效率低）

SpringCloud的注册中心

SpringCloud：基于Http远程调用的短链接，效率低，兼容性

1.基于http短链接

2.相比dubbo效率低

3.兼容性好

Http协议：head（请求方式，json/text） body，http协议是基于TCP协议的

TCP调用：三次握手，四次挥手

Socket：套接字是指通过ip地址+端口号，在流中发送和接收数据的这种交互方式

长连接：握手后不断开，服务器可以找到客户端

短链接：客户端发起请求，服务器响应后，断开本次请求，服务器无法再次找到客户端

SpringCloud 和Dubbo 的区别（必会）

SpringCloud：Spring 公司开源的微服务框架，SpirngCloud 定位为微服务架构下的一站式解决方案（微服务生态）。
Dubbo：阿里巴巴开源的 RPC框架，Dubbo 是 SOA 时代的产物，它的关注点主要在于服务的调用，流量分发、流量监控和熔断。

4、echarts

我们只需要找到想要的图形,将它的option复制过来,然后让后台组织对应的数据即可.

对于基本图形来说,需要的数据就是json数组,每个json对象只需要name和value两个属性即可

要求我们的controller只需要返回List,使用@ResponseBody将list转成json数组即可.

再次我使用ajax方式去查询页面上需要的数据.

5、POI报表注意事项

1.POI 的介绍

POI是用JAVA语言编写的免费的开源的跨平台API，可以对微软的word、Excel、PPT进行操作。

2.Excel 报表导出流程：

创建工作簿Workbook(HSSFWorkbook)<工作簿这块我们需要注意一个问题，普通处理Excel 我们分为 Excel03(HSSF)版和 07(XSSF)版本以上，对于大数据处理我们使用SXSSF，比如一个Excel有 40 多列>
创建工作表sheet(createSheet())
设置一些参数(sheet.set***)设置列宽
要设置标题、标题行、设置行高(setHeightInPoints())，设置单元格对象，设置对象里边的内容。还有就是合并单元格，横向合并单元格
数据填充
实现文件下载，导出到制定路径

3.百万级数据导出

涉及的数据量比较大，我们这里采用 POI 给我们提供的支持07 版本的 SXSSFWork 对象实现导入导出，但是不能使用模板打印，不能使用太多的样式

POI里边提供了两种模式，用户模式(系统默认)和事件模式。

这两个的区别是：用户模式:相当于xml中dom解析,一次性将所有的数据读取到内存中,再处理

事件模式:相当于xml中sax解析,逐行扫描解析,大量数据的话不会造成oom异常【内存溢出】【用于这种百万数据导出导入】

使用事件模式解析的步骤:

创建一个公用的解析器【Excel 解析器】[公司提供]
创建一个行解析器(自己创建)【sheet解析器】【是基于 SAX 解析】

6、MQ的使用模式、选型、消息一致性、消息丢失等问题的处理。

常见的消息中间件

RabbitMQ :阿里使用广泛
RocketMQ :阿里(上一代)
ActiveMQ : apache (特点:爱丢数据 java,使用较少)
kafka : apache 属于大数据生态圈特点:高吞吐

规范:

JMS:java的消息服务规范 javaee规范之一代表作:ActiveMQ
AMQP: 不区分语言消息中间件的协议代表作:RabbitMQ

RabbitMQ有什么缺点？

降低了系统的稳定性：本来系统运行好好的，现在你非要加入个消息队列进去，那消息队列挂了，你的系统不是呵呵了。因此，系统可用性会降低。
增加了系统的复杂性：加入了消息队列，要多考虑很多方面的问题，比如：一致性问题、如何保证消息不被重复消费、如何保证消息可靠性传输等。因此，需要考虑的东西更多，复杂性增大。

如何保证RabbitMQ 高可用？

搭建 RabbitMQ 集群。一般小型，中型项目搭建3 台够用了。数据量在500万内。

如何保证RabbitMQ 消息可靠传输？

消息不可靠的情况可能是消息丢失，劫持等原因。丢失又分为：生产者丢失消息、消息列表丢失消息、消费者丢失消息。

生产者丢失消息
从生产者弄丢数据这个角度来看，RabbitMQ提供 transaction和 confirm模式来确保生产者不丢消息。
- transaction模式：发送消息前，开启事务（channel.txSelect()）,然后发送消息，如果发送过程中出现什么异常，事务就会回滚（channel.txRollback()）,如果发送成功则提交事务（channel.txCommit()）。然而，这种方式有个缺点，吞吐量下降。
- confirm模式：一旦 channel 进入 confirm 模式，所有在该信道上发布的消息都将会被指派一个唯一的 ID（从 1 开始），一旦消息被投递到所有匹配的队列之后。RabbitMQ 就会发送一个ACK 给生产者（包含消息的唯一 ID），这就使得生产者知道消息已经正确到达目的队列了.如果rabbitMQ没能处理该消息，则会发送一个 Nack消息给你，你可以进行重试操作。
消息队列丢数据【项目中使用的】
``消息持久化`。处理消息队列丢数据的情况，一般是开启持久化磁盘的配置。这个持久化配置可以和 confirm 机制配合使用，你可以在消息持久化磁盘后，再给生产者发送一个 Ack信号。这样，如果消息持久化磁盘之前，rabbitMQ 阵亡了，那么生产者收不到 Ack 信号，生产者会自动重发。那么如何持久化呢？

这里顺便说一下吧，其实也很容易，就下面两步：

1.将 queue 的持久化标识 durable 设置为 true,则代表是一个持久的队列。

2.发送消息的时候将 deliveryMode=2。这样设置以后，即使rabbitMQ 挂了，重启后也能恢复数据。

消费者丢失消息【改为手动回执】
消费者丢数据一般是因为采用了自动确认消息模式，改为手动确认消息即可！消费者在收到消息之后，处理消息之前，会自动回复 RabbitMQ 已收到消息。如果这时处理消息失败，就会丢失该消息。
解决方案：处理消息成功后，手动回复确认消息。

RabbitMQ消息丢失解决方案

消息持久化、设置为自动回执

消息持久化
Exchange 设置持久化：durable:true。
queue 设置持久化；Message 持久化发送。
ACK 确认机制
消息发送确认。消息接收手动确认 ACK

RabbitMQ宕机了怎么处理

持久化还怕宕机⁼

RabbitMQ提供了持久化的机制，将内存中的消息持久化到硬盘上，即使重启 RabbitMQ，消息也不会丢失。
持久化队列和非持久化队列的区别是:

持久化队列会被保存在磁盘中，固定并持久的存储，当 Rabbit 服务重启后，该队列会保持原来的状态在 RabbitMQ
中被管理，

而非持久化队列不会被保存在磁盘中，Rabbit 服务重启后队列就会消失。非持久化比持久化的优势就是，由于非持久化不需要保存在磁盘中，所以使用速度就比持久化队列快。即是非持久化的性能要高于持久化。
而持久化的优点就是会一直存在，不会随服务的重启或服务器的宕机而消失。

如何解决分布式事务问题

2PC：两阶段提交【性能差】

执行阶段：
当创建订单时，向所有微服务发送消息,可以开始执行了,执行成功后，不直接提交,而是返回一个消息告诉我,执行成功还是执行失败。
第二阶段：
如果所有人都执行成功,再发一个消息,你们可以提交了；如果第一阶段有人执行失败,你就告诉所有人都回滚。
缺点：当锁定的表很多时,性能差。

TCC：补偿性事务(一般采用) try-confirm-concel
每个服务执行完后都提交,集中返回给自己,如果都执行成功了那就不管如果提交失败,就采用失败服务的补偿方法去补偿,但若补偿方法也失败,那你还需要进行重试写重试方法或者人工介入。
优缺：解决了性能问题,但是业务复杂,写一个事务还需要写补偿方法
异步确保：利用 mq 实现分布式事务。

**消息的两种模式

队列模式(点对点)
- 数据不丢失
- 同一条数据只能有一个消费者消费
订阅模式(广播)
- 数据可能丢失
- 同一条数据可以有多个消费者消费

rabbitmq基于以上两种模式进行扩展:

队列模式(点对点)
- 一般基本模式【一个生产者，一个消费者】
  - 生产者：向队列发送消息
  - 消费者：从队列中获取消息
- 工作(work)模式【一个生产者，多个消费者】[Work发送后，可以多个消费者处理生产出来的消息，消息被消费后消失]
  - 生产者：向队列发送消息
  - 消费者：多个消费者轮询的方式获取消息
    - 默认是平分的，设置basicQos(1)实现能者多劳
    - 设置每个消费者同时只能处理一条消息channel.basicQos(1);

角色功能:

生产者：向队列发送消息
消费者：需要绑定队列
队列：存储生产者的消息

订阅模式(广播)【一个生产者，多个消费者】
- 一般广播模式-fanout【Fanout发送后，全部消费者收到消息】
  - 生产者：确定交换机已声明后，向交换机发送消息
  - 消费者：确定队列已绑定交换机后，从队列获取消息
    - channel.queueBind(QUEUE_NAME, EXCHANGE_NAME, “”);
- 路由【定向】模式-direct【Direct发送后，路由相同的消费者收到消息】
  - 生产者：确定交换机已声明后，向交换机发送消息，发送时指定路由
    - 放信息的时候就需要指定key
  - 消费者：确定队列已绑定交换机并在绑定时指定路由，从队列获取消息
    - channel.queueBind(QUEUE_NAME, EXCHANGE_NAME, “insert”);
    - 例：队列1key:buy，对应的消费者只能接受buy信息
      
      队列2key:back 对应的消费者接受back信息
- 主题模式-topic【Topic发送后，路由相同的消费者收到消息，不过可以采用通配符的方式】
  - 生产者：确定交换机已声明后，向交换机发送消息，发送时指定路由
    - 放信息的时候就需要指定key buy.a
  - 消费者：确定队列已绑定交换机并在绑定时指定路由，从队列获取消息
    - channel.queueBind(QUEUE_NAME, EXCHANGE_NAME, “item.*”);
    - 例：队列1key: buy.*，对应的消费者1可以收到buy信息，不能接受back信息
```
队列2key：back.* buy.*，对应的消费者2可以接受back信息，能接受back信息 
1
```
key的匹配操作,一般使用.隔开key
支持两种通配符
①buy.* :一层目录任意字符匹配 buy.a buy.b; 但是buy.a.a 匹配不到
②buy.# :任意层目录任意字符匹配 buy.a buy.b buy.a.a

角色功能:

生产者：向交换机发送消息
消费者：需要绑定队列
交换机：发给绑定过的所有队列
队列：需要绑定到交换机

消息回执

简称ACK

有两种方式:

自动回执:一旦消费者收到信息,马上发送回执.
手动回执:需要在代码中通过api发送回执,对消息要求比较高的时候建议使用手动回执

问题：

解决消息丢失：：

①开启持久化

交换机定义消息队列,durable:是否持久化，如果想在RabbitMQ退出或崩溃的时候，不会失去所有的queue和消息，需要同时标志队列(queue)和交换机(exchange)是持久化的，即rabbit:queue标签和rabbit:direct-exchange中durable=true

②消费者手动确认消息【设置消息回执为手动】
避免消息堆积：：可以设置多消费者监听，实现消息争抢
消息有序性：：要顺序就要放弃效率，确定队列只有单一消费者
消息重复：：在消费端通过业务判断是否已执行，比如将处理过的消息在数据库做标识处理

6.定时任务调度框架Quartz

①Quartz框架

基于给定的时间点、给定的时间间隔、给定的执行次数自动执行的任务

除此之外:

spring task
jdk中timer

②核心组件

job:任务

detail:任务详情,具体的描述任务信息

trigger:触发器,包含任务详情和触发的时间【七子表达式】

schdule:调度器,调度所有的触发器

7.Jasper Report（PDF文件导出技术）

如果使用Jasper Report技术进行pdf文件导出，可以使用Jaspersoft Studio工具（软件）设计pdf文件的模板

其他PDF技术：

iText PDF
Openoffice

JasperReport 的生命周期

设计（Design）阶段、执行（Execution）阶段以及输出（Export）阶段。

设计阶段就是使用Jaspersoft Studio工具创建模板，模板创建完成我们保存为 JRXML 文件（JR 代表JasperReports）,其实就是一个 XML 文件。
执行阶段编译成可执行的二进制文件(即.Jasper 文件)结合数据进行执行，进行数据填充。
输出阶段（Export）：数据填充结束，可以指定输出为多种形式的报表。

如何使用

导入坐标，
引入模板，把编译好的模板引入到当前工程中。
配置控制器方法(1.加载模板文件， 2.构建文件输入流； 3.创建 JasperPrint 对象；4.写入 pdf 文档输出 )【按照笔记搞】

8.Zookeeper

ZooKeeper是一种为分布式应用所设计的高可用.高性能且一致的开源协调服务，它提供了一项基本服务：分布式锁服务。由于 ZooKeeper 的开源特性，后来我们的开发者在分布式锁的基础上，摸索了出了其他的使用方法：配置维护.组服务.分布式消息队列.分布式通知/协调等。

Zookeeper的核心是什么？

Zookeeper的核心是**原子广播**，这个机制保证了各个 Server 之间的同步。

实现这个机制的协议叫做Zab 协议。Zab 协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）。

当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数 Server 完成了和 leader 的状态同步以后，恢复模式就结束了。状态同步保证了 leader 和 Server 具有相同的系统状态。

Zookeeper中的每个 Server有几种状态？

每个 Server 在工作过程中有三种状态：
LOOKING：当前 Server 不知道 leader 是谁，正在搜寻
LEADING：当前 Server 即为选举出来的 leader
FOLLOWING：leader 已经选举出来，当前 Server 与之同步

为什么zookeeper 集群的数目，一般为奇数个？

容错
由于在增删改操作中需要半数以上服务器通过。

n(奇数) 台服务器和 n+1台服务器都最多允许相同的（n-1）/2 台服务器挂掉，才能维持半数以上服务器通过。那多一台服务器不是钱？？？

防脑裂【放至有多个leader 服务器】

Zookeeper 分布式锁的应用场景

在分布式锁服务中，有一种最典型应用场景，就是通过对集群进行Master选举，来解决分布式系统中的单点故障。什么是分布式系统中的单点故障：通常分布式系统采用主从模式，就是一个主控机连接多个处理节点。主节点负责分发任务，从节点负责处理任务，当我们的主节点发生故障时，那么整个系统就都瘫痪了，那么我们把这种故障叫作单点故障。

传统解决方案

  传统方式是采用一个备用节点，这个备用节点定期给当前主节点发送 ping包，主节点收到 ping 包以后向备用节点发送回复 Ack，当备用节点收到回复的时候就会认为当前主节点还活着，让他继续提供服务。
	当主节点挂了，这时候备用节点收不到回复了，然后他就认为主节点挂了接替他成为主节点但是这种方式就是有一个隐患，也就是说我们的主节点的并没有挂，只是在回复的时候网络发生故障，这样我们的备用节点同样收不到回复，就会认为主节点挂了，然后备用节点将他的Master实例启动起来，这样我们的分布式系统当中就有了两个主节点也就是-双 Master，出现 Master以后我们的从节点就会将它所做的事一部分汇报给了主节点，一部分汇报给了从节点，这样服务就全乱了。
1
2

Zookeeper解决方案：
Master启动：
在引入了 Zookeeper以后我们启动了两个主节点，“主节点-A"和"主节点-B"他们启动以后，都向 ZooKeeper 去注册一个节点。我们假设"主节点-A"所注册地节点是"master-00001”， “主节点-B"所注册的节点是"master-00002”，注册完以后进行选举，编号最小的节点将在选举中获胜获得“锁”并且成为主节点，也就是我们的"主节点-A"将会获得“锁”成为主节点，然后"主节点-B"将被阻塞成为一个备用节点。那么，通过这种方式就完成了对两个 Master 进程的调度。

⑴ Master故障
如果"主节点-A"挂了，这时候他所注册的节点将被自动删除，ZooKeeper 会自动感知节点的变化，然后再次发出选举，这时候"主节点-B"将在选举中获胜，替代"主节点-A"成为主节点。

⑵ Master恢复
如果“主节点-A”恢复了，他会再次向 ZooKeeper注册一个节点，这时候他注册的节点将会是"master-00003"，ZooKeeper会感知节点的变化再次发动选举，由于编号最小的节点将在选举中获胜获得“锁”并且成为主节点，这时候"主节点-B"在选举中会再次获胜继续担任"主节点"，"主节点-A"会担任备用节点。

9.WebService 技术

项目开发中使用的是基于 webService 的一套框架CXF，Cxf 是基于 SOA 总线结构，依靠 spring 完成模块的集成，实现 SOA 方式。底层就是基于servlet开发的

灵活的部署: 可以运行在 Tomcat,Jboss,Jetty(内置),weblogic 上面。

webService的三大规范是什么？

分别指的是 JAX-RS，JAX-WS，JAX-WS&SAAJ(废弃)

JAX-RS:

http发送符合restful风格请求,服务器处理.返回内容可以是xml或者json

jax-ws:(了解)

http请求发送的纯xml数据,服务器响应的回来的数据也是xml.xml是有约束(soap)
也有人称之为soap协议

webService的三要素是什么？

SOAP，WSDL，UDDI

SOAP: 基于 HTTP 协议，采用 XML 格式，用来传递信息的格式。【基于XML的协议.规范】
WSDL: 用来描述如何访问具体的服务。【对webservice的应用一个描述信息】
UDDI: 用户自己可以按 UDDI 标准搭建 UDDI 服务器，用来管理，分发，查询 WebService 。其他用户可以自己注册发布 WebService 调用。

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/凡人多烦事01/article/detail/325706