❶ 一个web项目,需要频繁的操作sql server 里的一个表A，然而A表里有了大量的数据后会导致操作反应时间过慢
对数据库进行集群，提高数据库的处理能力；
将A表进行拆分，分为多个表
❷ Web应用程序与网站之间的区别
Web应用程序是指运行时多数为了实现某个功能，就像网站的后台，web网站更侧重于前台的美观展示。
❸ 为什么JavaWeb项目要分层
首先让我们坐着时光机回到n年前的web开发。
那个时候最早都是静态的html页面，后来有了数据库，有了所谓的动态页面，
然后程序猿在编码的时候，会把所有的代码都写在页面上，包括数据库连接，包括事务控制，接收参数，各种校验，各种逻辑，各种html/js/css代码等等
怎么样？够乱吧？像一坨那什么一样，这个页面可能有成千上万行？
那么好，问题来了，回头需要修改的时候，你怎么办？
你找个东西找半天，好不容易找到了，还不敢改，怕被其他地方用了，改出连带问题。
页面一出错，定位不准到底是哪里的问题，从头到尾的挨个排查。
等等等等。
这就是大家常说的什么叫可维护性，这也是为什么越来越多的公司的规范要求不能写复杂sql。
还记得之前在东软的时候，一哥们写了一个80多行的大sql来完成一个核心的查询。
试问这个大sql天天在数据库里run，还有性能可言？
再试问谁敢改？
后来项目要改需求还是出现bug了，那个sql要改动，写sql的哥们改了好久才改好，因为时间长他也忘了，
再后来他离职了。。。
有人问，那简单sql实现不了我的功能呀，怎么办？
从数据库设计层面开始下手，要允许适当的冗余，把表弄好，就迎刃而解了，这也是数据库层面的一种解耦吧。
后来。。。
进入第二阶段，大家痛定思痛，决定要把页面和逻辑拆开，页面只是负责显示，逻辑都在后台。
这就出现了短暂的，在jsp里使用标签调用bean的用法。bean里耦合了除了页面之外的所有东西。
再后来。。。
进入了第三阶段，大家又痛定思痛，决定要拆成三部分，就是大名鼎鼎的MVC。
再再后来。。。
衍生出来了类似于struts/springmvc等等的mvc框架
---------------
JavaWeb项目的层有2个维度。
第一个维度是MVC的三层：
M：model，模型层，包括了你的业务逻辑和数据库操作，封装好给视图层使用的。
V：view，视图层，仅仅做的是展示数据，不包含业务逻辑，主要是jsp/html等等
C：controller，控制层，负责接收请求，调用模型层处理业务逻辑并返回给视图层。
第二个维度是java代码里的三层：
controller：控制层，负责接收参数/解析参数/封装参数，调用serivce，将service方法的返回值进行封装（如果需要），返回数据/返回页面，路由。
service：负责业务逻辑，事务控制在这层里做，被controller调用，以及调用。
：持久层，负责数据库交互，被service调用。
这2个维度别弄混了哟。我今天主要说的是第二个维度的层哟。
我认为，第二个维度是第一个维度的延伸，其实第二个维度再加上一个表现层就完美了，这就为什么有人说是4层架构。
---------------
前戏结束，步入正题：
有些学生朋友可能会问为什么要分层呢？我本来可以在一个地方写完的东西，非要散落在各个层中，都在一起不是挺好的吗？
开发效率高呀~
跳来跳去的我脑子都晕啦。。。
这就是为什么有人会把所有的东西都扔在一个层里，比如controller层。。。
其实我们可以在jsp上把所有的逻辑以及数据库操作,数据展示全部写在一起，耦合在一起，这样开发起来貌似更快，
但是维护性非常差，有朝一日想改一个小地方，牵一发而动全一身，隐患很高，无法快速定位问题。
因此我们需要分层。
分层了之后，你理论上改了持久层的东西，逻辑层是不用变动的。
每个Dao类是跟每个表走，Dao的每个方法里就一个个的简单sql，不包含任何业务逻辑，可以被不同的service复用和调用。
经过抽象后基本上都是通用的，因而我们在定义DAO层的时候可以将相关的方法定义完毕，
这样的好处是在对Service进行扩展的时候不需要再对DAO层进行修改，提高了程序的可扩展性。
提高了程序的可扩展性。具体什么时候做这些操作，怎么做这些操作都由Service来处理。
（就像郭德纲的相声里的一句话：“行了，你甭管了”）
而Service则不是，一个Service里可以会调用多个不同的，完成特定的业务逻辑，事务控制，
封装Service层的业务逻辑有利于通用的业务逻辑的独立性和重复利用性
同时，一个Service的方法也有可能被多个Controller的方法来调用。
逻辑出问题就在Service找问题，数据库，sql有问题就在Dao层找问题，
参数解析错误，跳转错误，就在Controller上找问题。
这样快速定位问题，互不干扰。
---------------
分层架构（这里会延伸到更广阔的架构）：
回头项目玩大了，怎么办？拆！！！
具体可以搜一下：maven分模块开发，怎么玩代码依赖，怎么玩微服务，怎么玩SOA，怎么玩RPC，怎么玩bbo。
web项目发展有几个阶段啊
第一个阶段（单一应用架构）：
所有代码都耦合在一个项目里，放在一台服务器上，这种all in one的方式是有好处的。
创业初期，不用什么架构，走敏捷开发，最快速的实现需求才是王道。
你甭管我有多烂，我至少能跑起来，我至少能在外网上让你访问，让你使用。
当然了，初期的访问量很少，节省部署和运维成本才是王道呀。
听阿里的讲座，说淘宝的前期的版本用的就是一台PC机作为服务器，所有的功能耦合在一个项目里，
每次往生产环境上发版本，要上传一个600mb的包，呵呵。
第二个阶段（垂直应用架构）：
哎哟，不错哦。自己的儿子被越来越多的人访问，访问量激增，一台服务器扛不住了，
没事，我们可以玩负载均衡，玩集群。
但是！这种性能加速度其实会变得越来越小，因为你的项目是耦合在一起的。
这时，我们需要拆分项目，这里又有2个维度，按层拆，按模块拆。
将拆好的不同项目分别部署在不同的服务器上，并且再分不同的小集群。
第三个阶段（分布式服务架构）：
唉呀妈呀，访问量陡增，到这步你创业应该算成功了，开始烧投资人的钱了吧。
经过上面拆成了越来越多的模块，模块与模块交互越来越多，怎么办？
这个时候我们需要把核心的业务抽出来，作为独立的服务，慢慢发展成稳定的服务中心，
用来提升业务复用和整合。
就像阿里的大牛说过，没有淘宝的积累，天猫能那么快的出来吗？
这个时候，你的缓存，数据库，消息队列等服务都应该是分布式的。
第四个阶段（流动计算架构）
哎呀妈呀，访问量又上了一个台阶，翻了好几百倍吖，肿么办？
这个时候服务越来越多，一些容量和资源的浪费问题凸显出来，
这时我们需要一个调度中心来基于访问压力动态的管理集群容量，
提高利用率。
第五个阶段（云计算架构）
抱歉，作者正在学习中，未完待续。
❹ 微服务架构下，进行前后端分离，前端怎么写
分离后的前端，不再是一个简单的HTML文件，已经是一个独立的应用系统。除了要考虑页面的数据渲染展示，还要用工程化的思想来考虑前端的架构，前后端的交互和数据安全等事情。
RESTful接口交互
前后端分离之后，更多的是采用RESTful风格的接口与后端进行数据交互。
REST是“呈现状态转移（REpresentational State Transfer）”的缩写，一种API的架构风格，在客户端和服务端之间通过呈现状态的转移来驱动应用状态的演进。
在 REST 样式的 Web 服务中，每个资源都有一个地址。资源本身都是方法调用的目标，方法列表对所有资源都是一样的。这些方法都是标准方法，包括 HTTP GET、POST、PUT、DELETE，还可能包括 HEADER 和 OPTIONS。
RESTful的API设计，使得后端通过接口向前端传递数据，数据的格式通常是JSON这种通用的格式。对前端来说，只要后端返回过来的是RESTful的数据就行，不管后端是用Java写，还是用python或PHP，拜托对后端的依赖，做到前端系统的独立。
工程化构建
Nodejs不止可以用来做前端服务器，在开发阶段，它也能发挥很大的作用。
前端生态的发展，是围绕着Nodejs进行的。用npm来管理项目依赖，可以很好的维护和运行在Nodejs环境上。
打包工具grunt、gulp、webpack和rollup等，都是运行在nodejs上，再结合语法编译、打包部署等插件，将应用输入成一个完整的应用。
如果你使用了Angular、React或Vue框架，或者你使用浏览器暂时还不兼容的ES6语法，还需要在应用打包前用babel将语法编译成浏览器可识别的ES5的语法。
SPA
SPA是单页Web应用（single page web application，SPA）的简写，就是只有一张Web页面的应用，是加载单个HTML 页面并在用户与应用程序交互时动态更新该页面的Web应用程序。
像Angular、React或Vue就是为了SPA而设计的，结合前端路由库（react-router、vue-router）和状态热存储（rex、vuex）等，可以开发出一个媲美Native APP的Web APP，用户体验得到了很大的提升。
当然，SPA也不是完美的，也不是适合所有的web应用，需要结合项目和场景来选择。
SPA有如下缺点：
初次加载耗时增加。可以通过代码拆分、懒加载来提升性能，减少初次加载耗时。
SEO不友好，现在可以通过Prerender或Server render来解决一部分。
页面的前进和后端需要开发者自己写，不过现在一些路由库已经帮助我们基本解决了。
对开发者要求高，由于做SPA需要了解一整套技术栈，所以，要考虑后期是否有合适的人选进行维护。
❺ 公司的Java web 项目拆分好多个，一个主项目，包含好几个项目
你的意思是“一个项目下分多个模块”吧，如果是不存在关联性的项目肯定可以独立部署的。
一个项目下的多个模块由于存在关联性，比如相互调用，流程顺序等，需要整体发布。
模块一般是根据功能划分出来的子集，便于并行开发、单元测试及代码管理，也就是说，划分模块为了好管理。
❻ net中Web应用程序和web网站的区别
net中Web应用程序和web网站的区别：
1、WebSite：生成随机的程序集名，需要通过插件WebDeployment才可以生成单一程序集
WebApplication：可以指定网站项目生成单一程序集，因为是独立的程序集，所以和其他项目一样可以指定应用程序集的名字、版本、输出位置等信息
2、新建网站与新建Asp.net Web应用程序的区别，VS2010 SP1内置了转换程序，可以非常方便的从WebSite转换到WebApplication，只需要复制文件，右键执行“转换为Web应用程序”即可。
总结：
VS2010打sp1后，在要新做一个网站项目的时候，有两个选择：新建网站和新建 Asp.net Web应用程序。WebSite模式也就是“新建网站”，比较适合中小型企业网站。
❼ java web项目部署，是不是数据库和服务器要分开部署的啊
肯定是分开部署的（更加安全），并且一般采用的是虚拟化，将资源整合成一个资源池，根据每个应用的需要进行分配资源，当某个应用的虚拟机不能运行，立即有预留的虚拟机启动接管应用。你可以去服务器厂商（正睿）的网上找找虚拟化相关图文教程参考一下，很快就清楚了！
❽ vue项目打包，路由在数据库里，怎么进行分割
一、使用工具：webpack、react
二、方法步骤：
1、修改你的路由
三、注意事项：[name].js这一点很重要，要是不这样写，就不能打包成对应的路由js。
❾ 请教什么情况下应该把web服务器和应用服务器分开
简单的说
客户发送请求，请求到你的web服务器
Web服务器专门处理HTTP请求（比如IIS）
Tomcat是应用服务器
Web服务器把HTTP请求交给应用服务器
项目部署在tomcat上
这个项目里有你的逻辑关系
然后处理完之后 返回一个响应 应用服务器交给web服务器
web服务器交给客户
文件服务器 就是专门用来上传文件 和 下载文件的 单独独立出来，比如视频网站 他们的网站页面与视频文件所在服务器绝不是同一个 因为视频服务器的负载会很高