java服务器开发是做什么？和web端的区别是什么？

web开发，是开发服务端的，开发好的web程序，打包成war，然后放到web容器中运行，而web容器，是部署在服务器中的。

web的客户端就是浏览器，教你设计页面，学CSS/HTML之类的。

标准的web服务器只具有与客户端浏览器通讯的功能，不能处理业务逻辑请求。

需要编写程序来复制处理客户端的请求。通过组件来处理客户端的请求，这个组件就是实现特定规范的可以单独部署的软件模块。组件必须通过容器来实现。容器是实现特定规范的程序，负责组件的运行环境和管理组件的生命周期。tomcat，weblogic都提供了容器。

web端可以理解为tomcat，并且tomcat中运行着你编写的程序，这个程序称为web应用。

java服务器开发就是通过java语言来编写程序，组合成web应用，将来部署到tomcat中，

编写的这些程序就是组件，用来处理客户端请求的。为了高效还会使用一些框架和技术来配合java程序，比如SpringMVC，struts2，Servlet。

在进行服务器处理的过程中，需要保证数据的正确处理，那么最重要的就是使用不同的数据处理模式进行运算。

在整个过程中，可能很多人对服务器的知识并不了解，那么应该如何进行Java开发服务器的线程处理呢，关于线程处理有哪些知识？下面运城北大青鸟为大家介绍关键服务器线程处理的简单知识。

1、BIO线程模型在JDK1.4中引入JavaNIO之前，所有基于Java的Socket通信都使用了同步阻塞模式（BIO）。

这种请求-响应通信模型简化了上层的应用程序开发上，但在具有性能和可靠性的情况下，存在一个巨大的瓶颈。

在一段时间里面，大型应用程序服务器主要是用C或C++开发的，因为它们可以直接使用操作系统提供的异步I/O或AIO功能。

当流量增加且响应时间延迟增加时，JavaBIO开发的服务器软件只能通过硬件的不断扩展来满足并发性和低延迟的情况，这极大地增加了企业的成本和群集大小。

系统的不断扩展，系统的可维护性也面临着巨大的挑战，只能通过购买性能更高的硬件服务器来解决问题，这将导致恶性循环的产生。

2、异步非阻塞线程模型从JDK1.0到JDK1.3，Java的I/O类库非常原始。

UNIX网络编程中的许多概念或接口未反映在I/O类库中，例如Pipe、Channel、Buffer和Selector等。

在发布JDK1.4的时候，NIO正式发布JDK作为JSR-51。

并且它还添加了一个java.nio包，为异步I/O开发提供了许多API和库。

3、RPC性能三原则影响RPC的性能主要有三大元素，其中主要为I/O模型、协议及线程。

I/O模型：使用什么样的通道传递给另一方，BIO，NIO或AIO发送数据，IO模型在很大程度上能够决定框架的性能。

协议：应该使用什么样的通信协议，Rest+JSON或基于TCP的专用二进制协议。

参加电脑培训的过程中发现，协议的选择不同，性能模型也不同。

内部专用二进制协议的性能通常可以比公共协议更好地设计。

线程：如何读取数据报？在执行读取后的编解码器的哪个线程中，如何分发编码消息，通信线程模型是不同的，并且对性能的影响也非常大。

随着互联网技术的不断发展，我们在进行服务器开发方面也掌握了很多的开发部署技术。

今天，河北IT培训http://www.kmbdqn.cn/就给大家简单来介绍一下，都有哪些服务器开发部署方法是值得我们使用的。

停机部署停机部署其实是简单粗暴的方式，就是简单地把现有版本的服务停机，然后部署新的版本。

在一些时候，我们必需使用这样的方式来部署或升级多个服务。

比如，新版本中的服务使用到了和老版本完全不兼容的数据表的设计。

这个时候，我们对生产有两个变更，一个是数据库，另一个是服务，而且新老版本互不兼容，所以只能使用停机部署的方式。

这种方式的优势是，在部署过程中不会出现新老版本同时在线的情况，所有状态完全一致。

停机部署主要是为了新版本的一致性问题。

这种方式不好的问题就是会停机，对用户的影响会很大。

所以，一般来说，这种部署方式需要事前挂公告，选择一个用户访问少的时间段来做。

蓝绿部署蓝绿部署与停机部署大的不同是，其在生产线上部署相同数量的新的服务，然后当新的服务测试确认OK后，把流量切到新的服务这边来。

蓝绿部署比停机部署好的地方是，它无需停机。

我们可以看到这种部署方式，就是我们说的预发环境。

在我以前的金融公司里，也经常用这种方式，生产线上有两套相同的集群，一套是Prod是真实服务的，另一套是Stage是预发环境，发布发Stage，然后把流量切到Stage这边，于是Stage就成了Prod，而之前的Prod则成了Stage。

有点像换页似的。

这种方式的优点是没有停机，实时发布和升级，也避免有新旧版本同时在线的问题。

但这种部署的问题就是有点浪费，因为需要使用双倍的资源(不过，这只是在物理机时代，在云计算时代没事，因为虚拟机部署完就可以释放了)。

另外，如果我们的服务中有状态，比如一些缓存什么的，停机部署和蓝绿部署都会有问题。

滚动部署滚动部署策略是指通过逐个替换应用的所有实例，来缓慢发布应用的一个新版本。

通常过程如下：在负载调度后有个版本A的应用实例池，一个版本B的实例部署成功，可以响应请求时，该实例被加入到池中。

然后，版本A的一个实例从池中删除并下线。

这种部署方式直接对现有的服务进行升级，虽然便于操作，而且在缓慢地更新的过程中，对于有状态的服务也是比较友好的，状态可以在更新中慢慢重建起来。

但是，这种部署的问题也是比较多的。

在发布过程中，会出现新老两个版本同时在线的情况，同一用户的请求可能在新老版中切换而导致问题。