开发者学堂课程【Tomcat 服务器入门详解：WEB 架构和 Java 网页技术】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/654/detail/10844
WEB 架构和 Java 网页技术
内容介绍
一、WEB 架构
二、Java
三、Java 动态网页技术
一、WEB 架构
1.后端资源分类:
分为静态资源和动态资源。静态即做好之后就不再改变。
（1）静态资源
图片:
图片有大有小，大图片占用的是存储空间，小图片占用的是源数据，同时小图片越多 I\O 访问越多，因而在分布式存储的处理时常常将小图片变为大图片，减少I\O。
而大图片直接存储即可，但同时在分布式存储系统中有多份冗余，即备份（副本），难以确定副本数量，所以需要较多的磁盘。
同时分布式存储的好处为分散存储，可以作出并发读取和写入，最主要的就是在存储时尽可能减少 I\O，包括磁盘I\O和网络 I\O。在创建图片之后一般不会任意改动，除非创建新图。因而图片被认为一旦创建好，图片文件不再改变。图片数目多，占用磁盘空间多，一般使用单独的图片服务器。
HTML、CSS、JavaScript:
这些文本是纯文本写的源代码，相对于图片创建好之后基本不改变，这三种文本文件是前端支持的，
特点：每隔几天常更新版本，即：每次更新后网站首页，html 首页，内容和样式表，以及 css 和都会改变。
但并不会天天改版，一般为好几个月即静态文件和图片的缓存策略应该不一样。所以应该分清静态资源的类型，然后确定是对其进行浏览器端缓存或是服务器端缓存。前端工程师可以修改这些文件，但修改次数较少，者三种文件为一段时间都不变。
（2）动态资源
动态资源可能每次查询的结果都不一样，但有时故意设置其在一段时间内查询结果都一样，即将结果事先缓存一段时间，然后将一天内的查询结果设置为一样的。
能够做到，因为作为提供数据者，所以想提供什么就提供什么。若数据是独一份，就只能向数据提供者提供。意为，在大多数公司的访问压力较小的晚间时间，将新一天的数据计算完成，往往因为数据量庞大使用弹性计算。
等待高峰时期，就将缓存的数据拿出使用。以上说明，动态资源并非不能够缓存，但每一次动态过程都从后台来查询组织，十分考验后台的 QPS，要考虑到它的压力如何，否则服务器可能会被压垮。所以才要使用大量的缓存系统。
内容由后台程序动态生成，比如查询数据库后，将查询结果生成为 HTML
在此可以看出动态资源和静态资源的特点完全不同，同时使用的缓存策略也不相同。两者结合，才能构建一个好的 web 架构，来应付不同的并发场景。
Web 架构示意图：
其中的业务服务器和数据库服务器部分，数据库服务器并非仅仅只有一台关系型数据库，还有非关系型数据库等等。包括搜索引擎也包含在数据库中，因为其含有索引库。
以上都是我们所见到的企业级服务。所以在此的数据库不止有 mysql，还可能有大数据要使用的 hive,Hbase 数据库都有可能。即红框内的结构十分复杂，其中包含一大堆业务服务。
同时对于处于互联网公司的用户，应该需要一个界面，在此不一定要使用 cs 架构，也可以使用 bs 架构。
使用 cs 架构时，就可以不止实现 pc 端，也可以是移动端：平板和手机的实现。在此将 pc 端和平板、手机端可统一称为端，这就是端的编程。
同时服务器端编程为另一端，核心都是服务器端编程和客户端编程，区别只是根据使用的技术，来确定是 window 端还是网页。
两者差异：
黑色的线表示连接到 PC 端，绿色线表示移动端。
图片服务器：
两者稍有区别，静态服务器中提取出的图片服务器较为复杂。要实现一个大量的图片服务器集群，说明图片已经过多，如：电商网站，其中就大量需要图片，如果仅仅以文字的形式描述，难以卖出。
可以看出图片服务器在写美食，游记的网站十分重要，只有看见了图片和激情的文字结合才会使得购买的人有下单欲望。
总结：
图片服务器的使用在许多时候都至关重要，对于不同的网站使用需求也不一样，需要自行调节图片服务器的差异，如：图片服务器的文件系统，如何访问，是否需要缓存，缓存多大，图片如何上传或临时文件如何清理，是否添加水印和 cpu 是否能够运行，图片是否需要压缩等等问题，同时图片服务器还有分布式文件系统。
因而在图片服务器的搭建中，根据自身的需要和能力进行搭建即可。最后注意浏览器端也需要缓存，否则浏览器每回都强制刷新下载图片，流量的使用也会过大。
静态服务器：
静态服务器中存放 HTML、CSS、JavaScript 三样，变化较少。都是纯文本的形式，意味着可以压缩，
如：日志为100兆压缩后就变为几兆，但此种压缩形式 cpu 难以负荷。
而在发送 http 报文时可以协商压缩的比例，可以在此稍微压缩减少流量，以免带宽不够。
但图片不可以压缩，因为没有压缩的量，一个 jpg 文件越压缩会出现越来越大的情况，因为其已经经历了有损压缩，变为了有损格式。这就是在网络中为何很少见到BMP 格式的图片，都为 png、jpg，因为其中含有大量的数据空洞，有许多浪费字节空间的东西，是可以被压缩。但 jpg 没有必要，而在电商网站看见的 jpg 更加没有压缩的必要，因为其图片中色彩丰富（记录的数据量很大），同时能够删减的数据极少。
所以已经做了压缩格式的图片和视频，无法再做二次压缩，若用 zip 再次压缩，可能会越压越大。
总结：
图片服务器没有可压缩的量，都已使用了有损压缩的格式。
而对于纯文本 HTML、CSS、JavaScript 此三种，可以做适当压缩。而服务器端做了压缩之后，客户端也要做解压缩。
同时不必担心客户端的解压缩太过繁琐，因为通常的 pc 端 cpu 使用率不到20%，所以可以使用 pc 端来帮助客户端进行解压缩。但对于移动端而言，cpu 解压缩的功能过于耗电，同时难以运作。cpu 的能力提高后，耗电量也会对应提升。
总而言之，移动端如今的计算能力被认为没有 pc 端强。移动端简便，但耗电，同时流量使用量大。
所以移动端需要更多考虑，在图片缺少一条绿线，而面对 app 安装需要内容空间几十兆几百兆的问题，与当前开发有关。
移动端称为 native 开发，又叫 app 开发，其中有一部分本地开发，在几百兆的安装包中包括本地的安卓和 ios 提供的接口，更多的是 webapp 网页其中使用js，在图中没有表示该条线，是因为已经被装在手机本地中，但并非所有都安装在本地，仅为一大部分。
因为在展示时并不是一个纯净的页面，相当于手机端访问网页时，在手机打压缩包时将所有能够压缩的都进行了压缩，因为所有的 html，js 需要下载的话，消耗的流量巨大。
如今的 js 开发，任意一个项目需要使用的 js 文件下载量就有几百兆，同时其中js文件少则几万，多则几百万。
所以打开一个手机 app, 其中的一个页面就需要发起 n 多个 HTTP 请求，放在移动端并不合适，因为流量耗费巨大。所以采取的解决方法为增加响应速度，将能提前放在移动端的打包压缩的内容放在安装包里，使得客户体验更加流畅，以此防止响应太慢不为大众接受。
而应用市场经常更新，是因为一旦对 js 做了改动后，与之前安装的 js 文件会不一致，所以就需要使用更新，将重新更改的 js 再次打包、下载。而静态文件并非所有都进行打包，是将能打包的进行打包。
之前的几万和几百万个 js 会被打包，这些应用所依赖的 js,css 会被打包成一个 js 文件，pc 访问时会将其进行下载，花费的几百兆在网页上不做影响，而在移动端则会跟随安装包提前预装在手机中。
手机端加上混合开发共有三种，第一种直接使用 ISO 和安卓平台的 api，如：要访问硬件部分，则直接使用其开发。
也可以将一个 app 伪装，理念实际为浏览器，调用的内容则为刚刚安装的 html 和js。
再发起 ajax 请求到后台只需要 json 组合，即已经将 js 和 html 安装到手机中，只需要发起 AJAX 请求，而数据只需使用 JSON 返回，其中减少了许多繁琐的事务，减少流量，提高响应速度。
可以视为手机安装后内嵌了一个 html 浏览器，因为打开浏览器和 app 没有关系，而在此相当于 pc 端的访问官网。
使用这种访问方式，提高了安全性，避免了偷用数据的情况，如：app 中总是需要允许访问通讯录，磁盘，相册和存储空间等等权限，使用浏览器访问则不会出现该种问题。到此互联网平台就搭建完成。
Pc 端和移动端
Pc 端和移动端的使用不一样，移动端在一开始就要考虑响应速度和流量的问题。
同时还要考虑不同使用端分辨率的问题，在移动端不同尺寸手机，图片大小不同。因而此时就需要自适应的响应式服务框架，使得能使用一套代码解决不同分辨率的情况。
在实际应用中还是采用 pc 端考虑传统的浏览器使用，移动端考虑不同分辨率的使用。以上就是在开发中要考虑的不同分辨率的情况。
在访问动态数据时，pc 端和移动端都需要到达业务服务器中，图中的业务服务器仅仅为一个代表，具体看是单体架构，面向服务的还是微服务的。
在实际中，业务服务器中为集群，集群中再分层次。根据不同的需求找到不同的服务，最后在组织数据。
因此不同的企业在业务服务器的架构都不同，十分重要。在服务提供时，并不关心服务器的部署，仅仅只需要将服务给提供即可。因而部署方式由开发方式决定。开发方式使用什么架构，则部署方式也使用什么架构。而之后的数据库在使用时也极少为单个，多为集群。
2.PC 端或移动端浏览器访问
从静态服务器请求 HTML、CSS、JS 等文件发送到浏览器端，浏览器端接收后渲染在浏览器上，这些文件都是文本，可压缩后传输
从图片服务器请求图片资源显示
从业务服务器访问动态内容，动态内容是请求后有后台服务访问数据库后得到的，最终返回到浏览器端。
3.WEB App 访问
内置了 HTML 和S文件，不需要从静态 WEB 服务器下载 JS 或 HTML。为的就是减少文件的发送，现代前端开发使用的 JS 文件太多或太大了，
有必要就从图片服务器请求图片，从业务服务器请求动态数据
客户需求多样，更多的内容还是需要由业务服务器提供，业务服务器往往都是由一组服务器组成。
其中还有 Native app 即 iOS 提供的编程平台，两者结合使用也可，如：新闻的聚合端，在安装 app 时也需要一部分本地资源 Native app，同时又结合了装载的浏览器，新闻其实就是网页，在编写时含有一套自适应，会根据当前的分辨率做自适应。
访问移动端时，会判断是否使用移动端，若使用移动端的部分则不会再发起新的请求，而 pc 端则会再次显示，发起异步请求去访问。总结，要么就同步发起，要么异步发起。仅仅是为了提高响应才将移动端和 pc 端分为两部分来考虑。
二、后台应用架构
主要有以下阶段。
1、单体架构
最为常见，简单好部署。首先不论项目大小，一股脑将所有业务代码全部写在一起，一同协作开发，然后用一个项目包部署即可。
但之后发现缺点是太过庞大，
如：门户网站业务繁多，每个业务都能够成立一个单独网站，相当于靠域名访问不同的网站太过复杂。
因而常见的将其按照业务进行拆分，依次部署 tomcat，为按横向拆。
JSP、Servlet
不管项目多么大，都打包成一个 jar、war 部署
服务器有开源的 tomcat、jetty。商用的有 Jboss、weblogic、websphere、glassfish 商用的
1. Dubbo
SOA（Service-Oriented Architecture）面向服务的架构
另一种为按照层次纵向拆，表面访问前端技术 jsp，称为可视化的 view 视图层，将访问的数据库叫做访问数据层，中间加上业务逻辑层，视图层、业务逻辑层和数据访问层构成典型的三层结构。
纵向一开始仍是单体结构，但在切层后可以慢慢将其分为不同的服务，
如：
负责提供 oracle 数据访问的就可以单独形成一个模块，将其变为一个 Oracle、mysql 的数据库访问图层。
View 视图层，负责他人查看的数据是否美观，组织为给他人查看的东西。
视图层访问业务逻辑层 logical，只需调用其中的业务方法，然后将结果返回视图层再结合成一个网页，最后将网页返回给浏览器端，然后如：查看新闻，就调用业务逻辑层的新闻版块中的 showout 方法就会将能展示的新闻全部展示出。
使得 service 端分层，而当业务逻辑层也没有数据时，就会访问数据层 pa，而数据访问层还会再通过 model 再去访问数据。
即，当视图层需要访问业务时，会来到业务逻辑层，调用对应版块的方法，而方法会再去调用数据访问层中表的操作得到数据，而数据访问层会通过 model 层去访问数据库中的数据。
而通过一层层的调用服务，就可以切分各层服务。数据访问层和业务逻辑层依次变为一个个服务，同时还可将其变为不同服务再进行细分，以此将其变为一个个功能单元。
同时其中的粒度较大，可以拆成多个服务，如需要业务数据，就可以去调用不同业务的服务接口。
即从业务的服务调用可视化端调用业务数据端，而业务数据端又去调用业务的数据库管理模块，而数据服务 DATEBASE 最后去真正调用各种各样 DB，再将数据返回到视图层，实现一层对一层负责，就变为了不同的服务，若服务不够则依次添加实现水平扩展，形成服务集群，服务一多为了识别哪个掉线，又需要网关。以上就使用 Dubbo 来实现。
分布式服务框架
将单体程序分解成多个功能服务模块，模块间使用 Dubbo 框架提供的高性能 RPC通信（RPC 框架效率极高）
阿里开源贡献给了 ASF，目前已经是 Apache 的顶级项目
内部协调使用 Zookeeper（分布式服务，协调服务，为树形结点的数据库结构是个目录树，但在每个目录结点上可以保存数据。
结点特性：其中当 tcp 连接一断，结点就会立即消失，解决了所说分布一致性问题，会达到最终一致性，往往说分布式应用应该达到 CAP，而非 ACID，是雅虎实现的，此为 Hadoop 生态圈中一大重要的服务，当自行编写的服务器都需要分布式就需要靠 zookeeper 协调，将服务变为分布式），实现服务注册（一大堆服务不需要扫描全网，到注册中心后使用的为 Dubbo 本质为 zookeeper, 在 zookeeper 上注册只需要在 zookeeper 树型结点上一扫就可以知道谁还存在。因而注册就是在zookeeper 的树状结构上上注册一个树型结点）、服务发现（当发现时直接在zookeeper 上读取，在结点上发现数据，告诉域名端口即可）。有服务治理。（Dubbo 还提供了服务的治理，当服务太多时需要管理）
2. Spring cloud 微服务
微服务相比于之前的服务，对其再进行细分，将其一个一个功能拆开变为单一功能，以前仍然是按照业务功能说的，如今拆分为只做单一服务，将其粒度变得更为小，粒度变小之后仍然是面向服务，但是变为了微服务，所谓微服务就是极小到只能完成单一功能。因为此时的服务小需要资源更少，就要将资源给隔离划分，即将一个操作系统的资源给隔离划分了。
著名的微服务框架有 springcloud，广泛使用它来做。总而言之，单一的服务器治理开发，使得粒度更小，但开发和运维的配合要求更大。
将单体应用拆分为粒度更小的单一功能服务
RPC 通信
需要更高的运维水平，服务太多了需要服务治理（当服务所划分的越来越细，就需要来管理大量的服务）
3. 总结：
在原本的单体框架中，部署简单同时通讯效率不错。但在使用了 DUbbo 也成，但对于网络通信也有要求，服务越多内部网络通信互相调用，变得过多，内耗越大。
性能不一定变好，但好处是当觉得单一功能不佳是可以做水平扩展，与弹性计算有关，当存储不足时把存储扩大，带宽不够将带宽扩展，不必再将资源收回，适合弹性的云生态。
但微服务的制作对于团队协作能力的要求极高，在此更多需要全栈人员，即开发又懂运维又懂数据库又懂的形式，并非各司其职，而是多面手的形式。
在企业中部署，要么就是单体架构，一个 jar 包直接部署。或是其中含有更小的功能就要和 Dubbo 通过 rpc 在服务中互相调用结合在一起。不同的应用架构，部署方式也有不同。
