在网页中的应用，基本上是由tomcat来实现的
B/S架构好还是C/S架构好？（CS是要通过客户端去访问服务器，但是BS是直接通过网页去访问服务器）
选B/S，节省磁盘空间
HTML、CSS、JavaScript三大WEB核心技术
JavaScript
动态的弱类型脚本解释性语言
同步
要提交，必须要一次性提交。假如注册时，输错了，所有的填写项目重新填写
异步
可以使网页实现异步更新。这意味着可以在不重新加载整个网页的情况下，对网页的某部分进行更新
前面说的这些都是web应用，它们需要通过html翻译之后，才能被使用
单体架构
一台主机中配置了什么，另一台中也要配置一样的内容
微服务
彼此之间是相互独立的
缺点：适用于复杂的大环境，进行过度拆分反而会造成负担
- 每个服务足够内聚，足够小，代码容易理解。这样能聚焦一个只当的业务功能或业务需求。
- 开发简单、开发效率提高，一个服务可能就是专业的只干一件事，微服务能够被小团队单独开发， 这个小团队可以是2到5人的开发人员组成
- 微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的。
- 微服务能使用不同的语言开发
- 易于和第三方集成，微服务运行容易且灵活的方式集成自动部署，通过持续集成工具，如:
- Jenkins、Hudson、Bamboo微服务易于被一个开发人员理解、修改和维护，这样小团队能够更关注自己的工作成果，无需通过合作才能体现价值
- 微服务允许你利用融合最新技术。微服务只是业务逻辑的代码，不会和HTML/CSS或其他界面组件混合，即前后端分离
- 每个微服务都有自己的存储能力，可以有自己的数据库，也可以有统一数据库
缺点：
- 微服务把原有的一个项目拆分成多个独立工程，增加了开发、测试、运维、监控等的复杂度
- 微服务架构需要保证不同服务之间的数据一致性，引入了分布式事务和异步补偿机制，为设计和开发带来一定挑战
- 开发人员和运维需要处理分布式系统的复杂性，需要更强的技术能力
- 微服务适用于复杂的大系统，对于小型应用使用微服务，进行盲目的拆分只会增加其维护和开发成本
常见的微服务框架
Duboo
- 阿里开源贡献给了ASF，目前已经是Apache的顶级项目
- 一款高性能的Java RPC服务框架，微服务生态体系中的一个重要组件
- 将单体程序分解成多个功能服务模块，模块间使用Dubbo框架提供的高性能RPC通信
- 内部协调使用Zookeeper，实现服务注册、服务发现和服务治理
Spring cloud
- 一个完整的微服务解决方案，相当于Dubbo的超集
- 微服务框架，将单体应用拆分为粒度更小的单一功能服务
- 基于HTTP协议的REST(Representational State Transfer 表述性状态转移）风格实现模块间通信
三、tomcat的功能介绍
用户发过来的jsp nginx识别不了，它会把jsp交给中间键，中间键再把它们转换成html页面，返回给nginx，nginx再发送出去
tomcat就是中间键
实验环境
一台nginx(IP100)，一台tomcata（IP10），一台tomcatb（IP20）
web服务器 web应用服务器
安装Tomcat
安装JAVA环境
java版本查看
查看java真正的环境目录
jre真正的运行环境
要把java的运行环境指定给Tomcat
安装tomcat：
解压并重命名
进入目录并启动它
启动成功后查看端口
测试：
在另一台主机上也要做
简单一点就直接复制了
编写启动程序
内容中制定用户了，所以这里要建立用户
要给tomcat指定java的运行环境
报错情况：
此时是没有运行这个文件的权限
查看权限
加权限
测试：
四、结合反向代理实现tomcat部署
单机
现在需要一个测试页面
测试页面不能直接在root里要放到默认发布目录里
直接下载nginx
在配置文件里写下子配置命令 include
错误情况：
访问超时
直接访问没问题
域名解析有误，之前实验的影响
测试：
之前的信息也会保留
这个代码，nginx不能写，是tomcat来写的
tomcat挂了，这个实验就不能用了
单机情况下，tomcat挂了，就不能用了
要解决这个问题，用多机来做
多机
测试：
会话绑定
缺点：如果同一个路由器过来的路由都会跑向一个路由器上了
cookie客户端生成的会话 session服务器生成的会话
会话：以用户的身份与服务器对话
此时的情况时，来一个服务器就重新对话
所以解决办法是生成sessionIP要与cookieIP一致，cookie值变了，就访问不同服务器
写cookie哈希
对键值进行哈希
测试：
ID是一样的就会访问同一个服务器上
只有挂了浏览器才会改变，此时ID也变了
前端还在做数据存储，但是后端的tomcat却挂了，前端是不知道的，该怎么办？
无论是10还是20，之前的数据该怎么保存？
五、Memcached
它本身不支持持久化，只支持能序列化的数据类型
没有客户端，是个键值
实验：
修改接口，打开全部
再次查看端口信息
要把接口都打开
测试（长连接实验也用过）：
这里的2是字长 ：规定后面输入的字数只能是两个
查看刚刚储存的内容
修改储存的内容
删除并退出
企业一般不用
使用插件，让tomcat往memcached里存储，实际上，两者是没有关系的。
六、msm
查看memcached的版本
要去找合适版本的插件
安装
要把插件放进tomcat库里
查看tomcat的插件存储位置
服务重启成功后IP会发生变化
failoverNodes：当一个服务器的tomcat出故障时，另一台会要找自己的memcached的，因为自己的里面也是有对端的数据的
重启服务
测试：
20tomcat挂了
这里会有之前数据的原因是，20往10的memcached里存的数据，20挂了，10会在memcached里读取数据
