java 应用程序在linux 上怎么部署 运行

java 应用程序在linux部署方法：
1，将项目达成war包（用eclipse，项目右键--Export--选择war file）
2,将tomcat（用winSCP当然也可以用secureCRT,用securCRT需要建立sftp(即上传文件的目录)，用put tomcat命令）考到ilunx对应的目录下
3，然后将项目的war包放到tomcat的webapps目录下
4，启动tomcat(命令：/startupsh(linux下启动tomcat是sh文件而非bat文件))
遇到问题如下：
运行/startupsh 是报错
-bash: /startupsh: Permission denied
原因：没有运行sh的权限
解决：chmod 777 sh
755 代表用户对该文件拥有读，写，执行的权限，同组其他人员拥有执行和读的权限，没有写的权限，其他用户的权限和同组人员权限一样。
777代表，user,group ,others ,都有读写和可执行权限。
获得权限后再运行/startupsh命令时报错：
This file is needed to run this program
原因：该文件需要一个运行环境（即配置jdk环境变量）
解决：JAVA_HOME=/usr/java/jdk160_25/（当然这个目录根据自己的jdk安装目录）
然后在运行/startupsh 提示：
Using CATALINA_BASE: /usr/local/sarft/apache/apache-tomcat-6029
Using CATALINA_HOME: /usr/local/sarft/apache/apache-tomcat-6029
Using CATALINA_TMPDIR: /usr/local/sarft/apache/apache-tomcat-6029/temp
Using JRE_HOME: /usr/java/jdk160_25/
Using CLASSPATH: /usr/local/sarft/apache/apache-tomcat-6029/bin/bootstrapjar
如果提示以上信息表明 tomcat启动成功，可以正常run了。

一、用来放网站
网站服务器的应用通常是最常见的，按规模可以根据网站的日均PV区分，按类型可以区分为门户类网站、企业类网站、个人网站、交易型网站、论坛、博客等。
网站应用服务器的部署流程如下：在云服务器上部署网站前，首先必须确保您有云服务器的管理权限，或者是云服务器的空间和接口程序。
二、办公系统应用云服务器
随着电脑在办公中的需求越来越重要，办公软件也成为了企业必须具备的基本软件应用。办公软件的种类非常多，应用最多的主要是OA、ERP、CRM、企业邮箱等，这些办公软件在云服务器上的部署是大致相同的。
三、数据库应用云服务器
随着IT行业应用部署规模的日益增大，越来越多的企业使用云服务器作为单独的数据库应用服务器，用云服务器安装数据库服务。
四、 渲染和视频转码
渲染是非常费时间的，渲染的时间越长，越能保证画面的真实感，而云服务器正好适用于渲染，据了解，《哪吒》需要渲染的总帧数高达289077帧，一台云服务器每次只能渲染一帧，而一帧完成渲染的时间可能要十几二十小时，这种大工程，肯定不会只有一台云服务器来渲染，而是同时有几千台的云服务器不眠不休的高效工作。而小工程的渲染，比如设计师在作图的时候，3D建模的图，也会需要渲染，如果嫌自己电脑太慢，不妨开一台云服务器帮你完成，即开即用，用完就删除资源，很方便的。

分布式架构的演进
系统架构演化历程-初始阶段架构
初始阶段 的小型系统 应用程序、数据库、文件等所有的资源都在一台服务器上通俗称为LAMP
特征：
应用程序、数据库、文件等所有的资源都在一台服务器上。
描述：
通常服务器 *** 作系统使用Linux，应用程序使用PHP开发，然后部署在Apache上，数据库使用MySQL，汇集各种免费开源软件以及一台廉价服务器就可以开始系统的发展之路了。
系统架构演化历程-应用服务和数据服务分离
好景不长，发现随着系统访问量的再度增加，webserver机器的压力在高峰期会上升到比较高，这个时候开始考虑增加一台webserver
特征：
应用程序、数据库、文件分别部署在独立的资源上。
描述：
数据量增加，单台服务器性能及存储空间不足，需要将应用和数据分离，并发处理能力和数据存储空间得到了很大改善。
系统架构演化历程-使用缓存改善性能
特征：
数据库中访问较集中的一小部分数据存储在缓存服务器中，减少数据库的访问次数，降低数据库的访问压力。
描述：
系统访问特点遵循二八定律，即80%的业务访问集中在20%的数据上。
缓存分为本地缓存和远程分布式缓存，本地缓存访问速度更快但缓存数据量有限，同时存在与应用程序争用内存的情况。
系统架构演化历程-使用应用服务器集群
在做完分库分表这些工作后，数据库上的压力已经降到比较低了，又开始过着每天看着访问量暴增的幸福生活了，突然有一天，发现系统的访问又开始有变慢的趋势了，这个时候首先查看数据库，压力一切正常，之后查看webserver，发现apache阻塞了很多的请求，而应用服务器对每个请求也是比较快的，看来 是请求数太高导致需要排队等待，响应速度变慢
特征：
多台服务器通过负载均衡同时向外部提供服务，解决单台服务器处理能力和存储空间上限的问题。
描述：
使用集群是系统解决高并发、海量数据问题的常用手段。通过向集群中追加资源，提升系统的并发处理能力，使得服务器的负载压力不再成为整个系统的瓶颈。
系统架构演化历程-数据库读写分离
享受了一段时间的系统访问量高速增长的幸福后，发现系统又开始变慢了，这次又是什么状况呢，经过查找，发现数据库写入、更新的这些 *** 作的部分数据库连接的资源竞争非常激烈，导致了系统变慢
特征：
多台服务器通过负载均衡同时向外部提供服务，解决单台服务器处理能力和存储空间上限的问题。
描述：
使用集群是系统解决高并发、海量数据问题的常用手段。通过向集群中追加资源，使得服务器的负载压力不在成为整个系统的瓶颈。
系统架构演化历程-反向代理和CDN加速
特征：
采用CDN和反向代理加快系统的 访问速度。
描述：
为了应付复杂的网络环境和不同地区用户的访问，通过CDN和反向代理加快用户访问的速度，同时减轻后端服务器的负载压力。CDN与反向代理的基本原理都是缓存。
系统架构演化历程-分布式文件系统和分布式数据库
随着系统的不断运行，数据量开始大幅度增长，这个时候发现分库后查询仍然会有些慢，于是按照分库的思想开始做分表的工作
特征：
数据库采用分布式数据库，文件系统采用分布式文件系统。
描述：
任何强大的单一服务器都满足不了大型系统持续增长的业务需求，数据库读写分离随着业务的发展最终也将无法满足需求，需要使用分布式数据库及分布式文件系统来支撑。
分布式数据库是系统数据库拆分的最后方法，只有在单表数据规模非常庞大的时候才使用，更常用的数据库拆分手段是业务分库，将不同的业务数据库部署在不同的物理服务器上。
系统架构演化历程-使用NoSQL和搜索引擎
特征：
系统引入NoSQL数据库及搜索引擎。
描述：
随着业务越来越复杂，对数据存储和检索的需求也越来越复杂，系统需要采用一些非关系型数据库如NoSQL和分数据库查询技术如搜索引擎。应用服务器通过统一数据访问模块访问各种数据，减轻应用程序管理诸多数据源的麻烦。
系统架构演化历程-业务拆分
特征：
系统上按照业务进行拆分改造，应用服务器按照业务区分进行分别部署。
描述：
为了应对日益复杂的业务场景，通常使用分而治之的手段将整个系统业务分成不同的产品线，应用之间通过超链接建立关系，也可以通过消息队列进行数据分发，当然更多的还是通过访问同一个数据存储系统来构成一个关联的完整系统。
纵向拆分：
将一个大应用拆分为多个小应用，如果新业务较为独立，那么就直接将其设计部署为一个独立的Web应用系统
纵向拆分相对较为简单，通过梳理业务，将较少相关的业务剥离即可。
横向拆分：将复用的业务拆分出来，独立部署为分布式服务，新增业务只需要调用这些分布式服务
横向拆分需要识别可复用的业务，设计服务接口，规范服务依赖关系。
系统架构演化历程-分布式服务
特征：
公共的应用模块被提取出来，部署在分布式服务器上供应用服务器调用。
描述：
随着业务越拆越小，应用系统整体复杂程度呈指数级上升，由于所有应用要和所有数据库系统连接，最终导致数据库连接资源不足，拒绝服务。
Q：分布式服务应用会面临哪些问题？
A：
(1) 当服务越来越多时，服务URL配置管理变得非常困难，F5硬件负载均衡器的单点压力也越来越大。
(2) 当进一步发展，服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系。
(3) 接着，服务的调用量越来越大，服务的容量问题就暴露出来，这个服务需要多少机器支撑？什么时候该加机器？
(4) 服务多了，沟通成本也开始上升，调某个服务失败该找谁？服务的参数都有什么约定？
(5) 一个服务有多个业务消费者，如何确保服务质量？
(6) 随着服务的不停升级，总有些意想不到的事发生，比如cache写错了导致内存溢出，故障不可避免，每次核心服务一挂，影响一大片，人心慌慌，如何控制故障的影响面？服务是否可以功能降级？或者资源劣化？
Java分布式应用技术基础
分布式服务下的关键技术：消息队列架构
消息对列通过消息对象分解系统耦合性，不同子系统处理同一个消息
分布式服务下的关键技术：消息队列原理
分布式服务下的关键技术：服务框架架构
服务框架通过接口分解系统耦合性，不同子系统通过相同的接口描述进行服务启用
服务框架是一个点对点模型
服务框架面向同构系统
适合：移动应用、互联网应用、外部系统
分布式服务下的关键技术：服务框架原理
分布式服务下的关键技术：服务总线架构
服务总线同服务框架一样，均是通过接口分解系统耦合性，不同子系统通过相同的接口描述进行服务启用
服务总线是一个总线式的模型
服务总线面向同构、异构系统
适合：内部系统
分布式服务下的关键技术：服务总线原理
分布式架构下系统间交互的5种通信模式
request/response模式（同步模式）：客户端发起请求一直阻塞到服务端返回请求为止。
Callback（异步模式）：客户端发送一个RPC请求给服务器，服务端处理后再发送一个消息给消息发送端提供的callback端点，此类情况非常合适以下场景：A组件发送RPC请求给B，B处理完成后，需要通知A组件做后续处理。
Future模式：客户端发送完请求后，继续做自己的事情，返回一个包含消息结果的Future对象。客户端需要使用返回结果时，使用Future对象的get(),如果此时没有结果返回的话，会一直阻塞到有结果返回为止。
Oneway模式：客户端调用完继续执行，不管接收端是否成功。
Reliable模式：为保证通信可靠，将借助于消息中心来实现消息的可靠送达，请求将做持久化存储，在接收方在线时做送达，并由消息中心保证异常重试。
五种通信模式的实现方式-同步点对点服务模式
五种通信模式的实现方式-异步点对点消息模式1
五种通信模式的实现方式-异步点对点消息模式2
五种通信模式的实现方式-异步广播消息模式
分布式架构下的服务治理
服务治理是服务框架/服务总线的核心功能。所谓服务治理，是指服务的提供方和消费方达成一致的约定，保证服务的高质量。服务治理功能可以解决将某些特定流量引入某一批机器，以及限制某些非法消费者的恶意访问，并在提供者处理量达到一定程度是，拒绝接受新的访问。
基于服务框架Dubbo的服务治理-服务管理
可以知道你的系统，对外提供了多少服务，可以对服务进行升级、降级、停用、权重调整等 *** 作
可以知道你提供的服务，谁在使用，因业务需求，可以对该消费者实施屏蔽、停用等 *** 作
基于服务框架Dubbo的服务治理-服务监控
可以统计服务的每秒请求数、平均响应时间、调用量、峰值时间等，作为服务集群规划、性能调优的参考指标。
基于服务框架Dubbo的服务治理-服务路由
基于服务框架Dubbo的服务治理-服务保护
基于服务总线OSB的服务治理-功能介绍
基于服务总线OSB的服务治理
Q：Dubbo到底是神马？
A：
淘宝开源的高性能和透明化的RPC远程调用服务框架
SOA服务治理方案
Q：Dubbo原理是？
A：
-结束-

（1）Apache Apache是世界使用排名第一的Web服务器软件。它可以运行在几乎所有广泛使用的计算机平台上。Apache源于NCSA>通俗点说，就是安装OA软件的那台电脑，是OA系统运行的硬件基础，目前OA系统一般采用集中式部署、B/S模式结构，即OA程序和数据集中存放在OA服务器上，使用者的客户机无需安装专用软件，通过浏览器访问OA服务器的部署应用即可，这种模式方便系统的维护和管理，也方便系统的升级。
企业实施OA一般不需要配备专门的服务器，当然有条件的配备专门的服务器更好，因为专用的服务器性能更好，可以承受更多的并发访问；运行更可靠，速度、数据量方面也会有更好的表现。如果用普通的PC做服务器，PC机必须满足软件运行要求的最低配置，而且机器本身的性能要满足实际需要（OA使用用户数增多对性能要求更高），不然会影响正常的使用效果。
OA服务器除了安装OA软件外，同时还需安装运行OA系统所需的系统软件，如，应用服务器（如Tomcat、IIS、Apache等，一般是其中的一种）、数据库服务器（如mysql、sql server、oracle等，一般是其中的一种）等等；有的还有可能安装其他的软件，如：邮件服务器、FTP服务，基于IBM的Domino服务器等。
因此OA服务器包括，服务器硬件、OA软件、运行OA软件所需的系统软件及可能使用到的其他软件。
一般OA应用只需要一台服务器硬件就足够了，运行OA所需的所有软件都安装在这台机器上；对于高并发（几千到上万以上的并发用户数）的OA应用，OA服务器硬件可能不止一台，多台服务器实现集群，同时需要对应的OA软件支持集群，如，几台服务器集群做应用服务器，另外几台服务器集群做数据库服务器。
OA服务器对数据库没什么要求， 一些主流的数据库都支持
本文转自承元OA官方网站

一，什么是C / S结构。 C / S（客户端/服务器）结构，是著名的客户端和服务器架构。它是软件系统的体系结构，它可以充分利用两端硬件环境的优势，合理的任务分配到客户端和服务器端，降低了通信开销。大多数应用软件系统的Client / Server形式的两层结构，由于分布式Web应用程序开发，Web和客户机/服务器应用程序是相同的业务流程，应用不同的模块共享逻辑组件的软件应用程序，因此，内部和外部的用户都可以访问新的和现有的应用程序，通过新的系统可以扩展现有应用系统的逻辑。这是本应用系统的发展方向。

传统的C / S架构是开放模式，但这仅仅是一个开放的发展，无论是客户端和服务器端的具体应用需要特定的软件支持。用户真正期望的开放的环境中没有提供的C / S结构的软件需要开发不同的 *** 作系统，不同版本的软件，结合了产品的升级换代速度非常快，已经很难适应局域网用户在100多台电脑在同一时间。昂贵和低效。我院在上海超蓝的情况下的统计管理软件，是一个典型的C / S架构管理软件。

二，什么是B / S结构。 B / S（浏览器/服务器）结构，即浏览器和服务器结构。随着互联网技术的兴起，C / S结构，改善结构的变化。在这种结构中，在用户界面是通过>

与传统的软件开发方式相比，基于构件的软件开发方法有什么突破呢？一、体系结构软件体系结构代表了系统公共的高层次的抽象，它是系统设计成败的关键

其设计的核心是能否使用重复的体系模式

传统的应用系统体系结构从基于主机的集中式框架，到在网络的客户端上通过网络访问服务器的框架，都不能适应目前企业所处的商业环境，原因是：企业过分地依赖于某个供应商的软件和硬件产品

这种单一供应商使得企业难以利用计算供应商的免费市场，将计算基础设施的重要决定交给第三方处理，这显然不利于企业在合作伙伴之间共享信息

不能适应远程访问的分布式、多层次异构系统

封装的应用系统在出现某种组织需要时，难以用定制来维护系统，从而难以满足多变的需求

不能实现分析、设计核心功能重用，最多只能实现代码重用

如今，应用系统已经发展成为在Intranet和Internet上的各种客户端可远程访问的分布式、多层次异构系统

CBSD为开发这样的应用系统提供了新的系统体系结构

它是标准定义的、分布式、模块化结构，使应用系统可分成几个独立部分开发，可用增量方式开发

这样的体系结构实现了CBSD的以下几点目标:能够通过内部开发的、第三方提供的或市场上购买的现有构件，来集成和定制应用软件系统

鼓励在各种应用系统中重用核心功能,努力实现分析、设计的重用

系统都应具有灵活方便的升级和系统模块的更新维护能力

封装最好的实践案例，并使其在商业条件改变的情况下，还能够被采用，并能保留已有资源

由此看出,CDSD从系统高层次的抽象上解决了复用性与异构互 *** 作性，这正是分布式网络系统所希望解决的难题

二、开发过程传统的软件开发过程在重用元素、开发方法上都与CBSD有很大的不同

虽然面向对象技术促进了软件重用，但是，只实现了类和类继承的重用

在整个系统和类之间还存在很大的缺口

为填补这个缺口，人们曾想了许多方法，如系统体系结构、框架、设计模式等

自从构件出现以来，软件的重用才得到了根本改变

CBSD实现了分析、设计、类等多层次上的重用

图1显示了它的重用元素分层实现

在分析抽象层上，重用元素有子系统、类；在设计层上重用元素有系统体系结构、子系统体系结构、设计模式、框架、容器、构件、类库、模板、抽象类等

在软件开发方法上，CBSD引导软件开发从应用系统开发转变为应用系统集成

建立一个应用系统需要重用很多已有的构件模块，这些构件模块可能是在不同的时间、由不同的人员开发的，并有各种不同的用途

在这种情况下，应用系统的开发过程就变成对构件接口、构件上下文以及框架环境一致性的逐渐探索过程

例如，在J2EE平台上，用EJB框架开发应用系统，主要工作是将应用逻辑,按sessionBean、entityBean设计开发,并利用JTS事务处理的服务实现应用系统

其主要难点是事务划分、构件的部署与开发环境配置

概括地说，传统的软件开发过程是串行瀑布式、流水线的过程;而CBSD是并发进化式，不断升级完善的过程

图2显示了它们的不同

三、软件方法学软件方法学是从各种不同角度、不同思路去认识软件的本质

传统的软件方法学是从面向机器、面向数据、面向过程、面向功能、面向数据流、面向对象等不断创新的观点反映问题的本质

整个软件的发展历程使人们越来越认识到应按客观世界规律去解决软件方法学问题

直到面向对象方法的出现，才使软件方法学迈进了一大步

但是，高层次上的重用、分布式异构互 *** 作的难点还没有解决

CBSD发展到今天，才在软件方法学上为解决这个难题提供了机会

它把应用业务和实现分离，即逻辑与数据的分离，提供标准接口和框架，使软件开发方法变成构件的组合

因此，软件方法学是以接口为中心，面向行为的设计

图3是其开发过程

归纳起来，CBSD的软件开发方法学应包括下面几方面：对构件有明确的定义

基于构件的概念需要有构件的描述技术和规范，如UML、JavaBean、EJB、Servlet规范等

开发应用系统必须按构件裁剪划分组织，包括分配不同的角色

有支持检验构件特性和生成文档的工具，确保构件规范的实现和质量测试

总之，传统的软件方法学从草稿自顶向下进行，对重用没有提供更多的辅助

CBSD的软件方法学要丰富得多，它是即插即用，基于体系结构，以接口为中心，将构件有机组合，它把自顶向下和自底向上方法结合起来进行开发

四、开发组织机构传统软件的开发组织一般由分析员、设计员、程序员和测试员组成

对一个小的应用系统来说，一个熟练的开发人员，可能兼顾以上多个角色

但对CBSD来说,因为构件开发与应用系统集成往往是分开进行的，因此整个开发过程由六个角色来完成，他们是:构件开发者也是构件供货商，这些大多数是中间件构件提供(续致信网上一页内容)者

应用构件集成者针对某应用领域将已有构件组合成更大的构件模块或容器，作为系统部署的基本单元

应用系统部署者将系统部署基本单元放入选定的平台环境或基本框架中，完成软件定制的要求

开发平台服务器供应商提供服务器、 *** 作系统和数据库等基本软件

应用系统开发工具供应商提供构件公共设施服务

系统管理员配置硬件、网络和 *** 作系统，监督和维护应用系统者

这六个角色的工作专业性很强，要兼顾成为多面手很不容易

目前已形成构件开放市场，而且还很火红

这也是当今软件人才大战所遇的一个困惑

因此，在CBSD中，如何组织好开发队伍尤为重要，必须按本企业所具备人才来组织

特别重要的是:开发初期必须选好标准框架，以及统一的开发指导方针，保证在整个开发过程中,各角色能随时互相沟通

一般来说，CBSD的人员素质决定了构件的重用率

五、构造方法传统应用软件的构造是用白盒子方法，应用系统的实现全在代码中，应用逻辑和数据粘结在一起

而CBSD的构造是用白盒子和黑盒子相结合的方法

基于构件的框架是用两个概念来支持演变：第一个概念是构件有很强的性能接口，使构件逻辑功能和构件模型的实现都隐藏起来

这样，只要接口相同，构件就可以被替换

第二个概念是隐式调用，即在基于构件的框架中，从来不直接给构件的接口分配地址，只在识别构件用户后才分配地址

因此，构件用户只要了解接口要求和为构件接口提供的引用后的返回信息(该引用可能是一个构件，也可能是一个构件代理

对构件用户来说，构件代理就是构件，不用区分)

构件接口的信息并不存入构件内，而是存入构件仓库或注册处

这样才能保证构件替换灵活，并很容易利用隐式调用去重新部署构件

由于构件的实现对用户透明，因此也使构件能适应各种不同的个性化要求

为此，构件提供自检和规范化两个机制

自检保证在不了解构件的具体实现时，就能获得构件接口信息

例如，JavaBean提供的自检机制是Reflection和BeanInfo，通过Reflection可直接获得Bean构件的全部方法，通过BeanInfo可直接获得构件的许多复杂信息

规范化允许不访问构件就可以修改它，如JavaBean提供的规范化是propertysheet和customizer(定制器)

通过propertysheet提供一组简单参数，修改Bean的属性

复杂的修改由用户通过定制器设置参数完成

---