美食网站第二天

后台内容：
在父项目中导入依赖：

当前架构

common中主要存储公共的东西，manager是后台。
在manager中导入easyUI相关文件，并画一下目录结构

然后实现新增菜品功能：

通过fastDFS和Nginx实现图片的上传和回显功能，菜品描述采用的是kinddeditor富文本编辑器。
在此期间碰到问题：①：上传图片时，传回来的图片名称用了foodImg接收，应该用image接收，导致图片地址未能存入数据库中
②：在编写fastdfs_client.conf文件时，tracker_server的地址值写错，应该是多了个空格，所以导致图片回显时不能正确显示。
③：因长时间未着手写代码，所以在写代码过程中很不顺手，以此为戒。

在此整理一下关于fastDFS、Nginx、RPC框架、Dubbo相关的知识点：
RPC：RPC协议规定允许互联网中一台主机程序调用另一台主机程序，我们不用对这个交互过程进行编程。在RPC协议中强调：当A程序调用B程序中功能或者方法的时候，A不知道B中的方法时如何具体实现的。
RPC是上层协议，底层可以基于TCP协议，也可以基于HTTP协议。但是具体来说RPC协议要比HTTP协议更加高效，基于RPC的框架功能更多。
Dubbo（最开始是阿里内部使用的RPC框架，后来捐献给了Apache）：Apache Dubbo是一个高可用的基于Java的开源RPC框架。其不仅具备RPC访问功能，还包含服务治理功能。
Dubbo架构图

主要流程（仅代表个人理解）
1、提供者（provider）将自身相关信息注册到注册中心（registry）中
2、然后消费者（Consumer）从注册中心中订阅
3、注册中心接收到消费者的请求，然后通知消费者
4、消费者根据注册中心通知的信息进行调用提供者提供的方法
5、消费者和提供者把调用次数信息异步发送给监控中心
Monitor：监控中心，主要是监控provider的压力情况等。每个两分钟consumer和provider会把调用的次数发给监控中心，并由监控中心进行统计。
FastDFS：FastDFS是一个轻量级的开源分布式文件系统，主要解决了大容量的文件存储和高并发访问问题，文件存取时实现了负载均衡

CLient：客户端，使用java编写的项目属于客户端。
Tracker Server：跟踪服务器，主要做调度工作，在访问上起负载均衡的作用。在内存中记录集群中group和storage server的状态信息，是连接Client和Storage server的枢纽。
Storage Server：存储服务器，文件和文件属性（meta data）都保存到存储服务器上
不同组的storage server之间不会相互通信，由storage server主动向tracker server报告状态信息，tracker server之间也不会相互通信。

主要流程：
1、客户端访问Tracker
2、Tracker返回Storage的IP端口
3、客户端直接访问Storage，把文件内容和元数据发送出去
4、Storage返回文件存储id。包含组名和文件名
例：group1(组名)/M00(磁盘名)/00/00(目录)/xxxxxxxx.png(文件名)
Nginx：（FastDFS没有文件访问功能，需要借助其他工具实现图片的HTTP访问，Nginx具备代理虚拟机主机功能）
Nginx时一个特别强大的高性能Web和反向代理服务
具有正向代理和反向代理两种方式：
正向代理：一个位于客户端和原始服务器之间的服务器，为了从原始服务器取得内容，客户端向代理发送一个请求并指定目标（原始服务器），然后代理向原始服务器转交请求并将获得的内容返回给客户端，客户端才能使用正向代理
反向代理：以代理服务器来接受internet上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给internet上请求连接的客户端，此时代理服务器对外表现为一个反向代理服务器。