自己用过的框架

Java之SSH

SSH不是一个框架，而是多个框架的集成，是目前较流行的一种Web应用程序开源集成框架，用于构建灵活、易于扩展的多层Web应用程序。

系统从职责上分为四层：表示层、业务逻辑层、数据持久层和域模块层。

Spring+Struts+Hibernate（SSH）

其中使用Struts作为系统的整体基础架构，负责MVC的分离，在Struts框架的模型部分，利用hibernate框架对持久层提供支持，业务层用spring支持。

系统的基本业务流程是：

在表示层中，首先通过JSP页面实现交互界面，负责传送请求(Request)和接收响应(Response)，然后Struts根据配置文件(struts-config.xml)将ActionServlet接收到的Request委派给相应的Action处理。

在业务层中，管理服务组件的 Spring IoC容器负责向Action提供业务模型(Model)组件和该组件的协作对象数据处理(DAO)组件完成业务逻辑，并提供事务处理、缓冲池等容器组件以提升系统性能和保证数据的完整性。

在持久层中，则依赖于Hibernate的对象化映射和数据库交互，处理DAO组件请求的数据，并返回处理结果。

SSH配置流程：

1. 创建web项目
2. 配置struts：
   • 添加Struts2所需要的基本jar包到 lib目录
   • 在web.xml 文件里添加struts的过滤器配置
   • 在src目录下创建struts配置文件struts.xml
3. 配置spring：
   • 在lib目录下导入spring相关的jar包（2个spring跟struts结合的jar包）
   • 在web.xml文件下配置监听器
4. 配置hibernate:
   • 在lib目录里导入hibernate相关的jar包
   • 创建实体类
   • 创建实体类对应的xxx..hbm.xml映射文件
   • 应用IOC实现DAO接口
5. 编写Action类
6. 编写Service(接口类)和ServiceImpl(实现类)

Spring是一个轻量级的控制反转（IoC）和面向切面（AOP）的容器框架。

Struts它通过采用 Java Servlet/JSP 技术，实现了基于JavaEE Web应用的MVC设计模式的应用框架，是MVC经典设计模式中的一个经典产品。

Struts 2以WebWork为核心，采用拦截器的机制来处理用户的请求，这样的设计也使得业务逻辑控制器能够与ServletAPI完全脱离开，所以Struts 2可以理解为WebWork的更新产品。

Hibernate是一个开放源代码的对象关系映射框架，它对JDBC进行了非常轻量级的对象封装，使得Java程序员可以随心所欲的使用对象编程思维来操纵数据库。

Spring+SpringMVC+Mybatis（SSM）

SpringMVC 做控制器(controller)，Spring 管理各层的组件，MyBatis 负责持久化层。

Struts2与SpringMVC

avatar

avatar

MyBatis与Hibernate

• MyBatis可以进行更为细致的SQL优化，可以减少查询字段。
• MyBatis容易掌握，而Hibernate门槛较高。
• Hibernate的DAO层开发比MyBatis简单，Mybatis需要维护SQL和结果映射。
• Hibernate对对象的维护和缓存要比MyBatis好，对增删改查的对象的维护要方便。
• Hibernate数据库移植性很好，MyBatis的数据库移植性不好，不同的数据库需要写不同SQL。
• Hibernate有更好的二级缓存机制，可以使用第三方缓存。MyBatis本身提供的缓存机制不佳，更新操作不能指定刷新指定记录，会清空整个表，但是也可以使用第三方缓存。
• Hibernate 封装性好，屏蔽了数据库差异，自动生成SQL语句，应对数据库变化能力较弱，SQL语句优化困难。
• MyBatis仅实现了SQL语句和对象的映射，需要针对具体的数据库写SQL语句，应对数据库变化能力较强，SQL语句优化较为方便。

SSM配置流程：

1. 创建web项目
2. 在WEB-INF/lib导入jar包（亦可以根目录下用maven配置文件poom.xml进行配置管理jar包）
3. 配置MyBatis:dao层编写dao类以及对应的mapper和xml（为dao接口方法提供sql语句配置）
4. 配置spring：在applicationContext.xml.xml文件下配置
5. 配置springmvc：配置springMVC.xml
6. 编写Service以及ServiceImpl
7. 编写Controller（相当于struts中的action）

SSM和SSH不同主要在MVC实现方式，以及ORM持久化方面不同（Hiibernate与Mybatis）。SSM越来越轻量级配置，将注解开发发挥到极致，且ORM实现更加灵活，SQL优化更简便；而SSH较注重配置开发，其中的Hiibernate对JDBC的完整封装更面向对象，对增删改查的数据维护更自动化，但SQL优化方面较弱，且入门门槛稍高。

参考文章

1. SSH框架的底层机制及原理
2. SSH的框架整合
3. SSH框架总结（框架分析+环境搭建+实例源码下载）
4. SSH和SSM对比总结
5. 手把手教你整合最优雅SSM框架：SpringMVC + Spring + MyBatis
6. SSM SPRING+SPING MVC + MYBATIS 三大框架整合详细步骤

PHP之ODP

ODP是公司发布的在线业务开发平台，面向全百度的在线业务支撑平台，专注于总结大社区类业务模式，其提供了标准的webserver环境、标准php环境、AP框架、SAF社区业务框架、基础库、RAL资源访问层、KSARCH通用服务等组件，统一业务的逻辑和部署结构，为测试、运维等提供一致的视图。

这也是自己实习时候一直在用的框架。

Online Develop Platform = Linux+Lightted/nginx+mysql+PHP

ODP核心包含了ODP的核心功能组件，包括运行环境、核心基础库、数据交互层、框架等。

横向看，ODP核心通过库、框架、工具等集成支持了各类规范和模式，也为全流程支持提供接口。

向上看，ODP核心直接为产品线业务提供运行环境和研发支持。

向下看，ODP核心通过数据交互层将底层的通用服务提供给业务。

AP框架目录：

模板层： odp/template/appname/

Actiono: odp/app/appname/actions/

PageService: odp/app/appname/models/service/page/

DataService: odp/app/appname/models/service/data/

Dao: odp/app/appname/models/dao/

Controller:  odp/app/appname/controller/

ODP应用程序结构：

newapp          // 应用名称
+--action       // 动作类目录
|  +--api       // 子系统交互api目录
|  |  --Sample.php  // 示例api服务端action
|  --Sample.php // 示例普通action
+--api          // saf api接口和服务类
|  --Interface.php  // 接口类
|  --Service.php    // 实现类
+--conf         // 配置目录
|  +--newapp        // 配置目录，配置文件可以拆分
|     --global.conf // app全局配置文件
|     --log.conf    // log示例配置文件
+--controllers      // 控制类目录
|  --Main.php       // 主控制类
|  --Api.php        // api控制类
+--doc          // 文档目录
+--library      // 本地类根目录
|  +--newapp        // app本地类目录
|     --Util.php    // 示例本地类
+--models       // 数据目录
|  +--dao       // 数据获取目录
|  |  --Sample.php  // 示例
|  +--service       // 页面数据服务目录
|     +--data       // 主题数据服务目录
|     |  --Sample.php   // 示例
|     +--page       // 页面数据服务目录
|        --Sample.php   // 示例
|        --SampleApi.php // api示例
+--script       // 脚本目录
|  --sampleScript.php   // 示例脚本
+--test         // 测试目录
+--Bootstrap.php    // ap框架的引导文件
+--build.sh     // 打包脚本
+--index.php        // 入口文件
+--Makefile     // 自动部署脚本
--readme.txt        // readme文件，告诉你如何部署和运行

DB，通过对应参数的不同，实现自动拼接不同的SQL语句。

$tables 数据表列表，可以是数组或者字符串
$fields 字段列表，可以是数组或者字符串
$conds 条件列表，可以是数组或者字符串
$options 选项列表，可以是数组或者字符串
$appends 结尾操作列表，可以是数组或者字符串

例如：
$table = ‘student’;
$fields = array(‘number’, ‘class’);
$conds = array(‘grade =‘ =>‘three’, ‘school =‘ => ‘希望小学’);
调用select($table, $fields, $conds); 
就会生成 
select number, class from student where grade = ‘three’ and school = ‘希望小学’   
的sql语句并执行之。

逻辑分层之间的调用关系，只能向后依赖，不能向前依赖或者跨层之间依赖。此次逻辑分层从前到后，依次为：Action、PageService、DataService、Dao。具体来说便是指，Dao不能依赖于DataService,PageService,Action；DataService不能依赖于PageService和Action；PageService不能依赖于Action。Action不能直接调用DataService，也不能直接调用Dao；PageService不能直接调用Dao。

SAF是ODP环境提供的业务层框架，SAF框架建立的目的是为了把业务逻辑开发过程中一些共性的问题抽取出来，并提供统一的解决方案。SAF框架包含控制器组件，通用业务组件（参数处理，session处理，日志打印等）以及通用配置组件。可以将SAF框架理解为一个工具库，SAF为我们提供了很多的通用功能例如验证用户的登录信息，接收用户提交的数据，更改用户的信息，记录用户的操作行为等。

SAF框架提供了一个很重要的功能就是钩子（Hook）机制，通过在钩子函数中覆写对应的钩子函数,可以实现对cgi(GET POST等)数据的特殊处理，对登陆信息的校验/修改以及对输出到log日志文件的内容的修改等功能。

RAL是一个支持多种交互协议和打包格式的php扩展。RAL规定了一套高度抽象的交互过程规范，将整个后端交互过程分成了交互协议和数据打包/解包两大块，可以支持一些常用的后端交互协议，标准化协议扩充的开发过程，促进代码复用。RAL集成了负载均衡、健康检查等功能，让上游端不需要再关注这些繁琐的通用逻辑，同时实现版本可以在性能方面有更优的表现。

参考文章：

1. ODP教程 | 百度外卖手册

Python之Tornado

自己做Sug平台展示时候选择的Python Web框架

Tornado 和现在的主流 Web 服务器框架（包括大多数 Python 的框架）有着明显的区别：它是非阻塞式服务器，而且速度相当快。得利于其 非阻塞的方式和对 epoll 的运用，Tornado 每秒可以处理数以千计的连接，这意味着对于实时 Web 服务来说，Tornado 是一个理想的 Web 框架。我们开发这个 Web 服务器的主要目的就是为了处理 FriendFeed 的实时功能 ——在 FriendFeed 的应用里每一个活动用户都会保持着一个服务器连接。

参考文章：

1. Tornado

Nginx

无论做什么框架，很多时候都离不开nginx

NGINX 有一个主进程（它执行特权操作，如读取配置和绑定端口）和一些工作进程与辅助进程。

反向代理

反向代理应该是Nginx做的最多的一件事了。反向代理（Reverse Proxy）方式是指以代理服务器来接受internet上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给internet上请求连接的客户端，此时代理服务器对外就表现为一个反向代理服务器。

server {  
        listen       80;                                                         
        server_name  localhost;                                               
        client_max_body_size 1024M;

        location / {
            proxy_pass http://localhost:8080;
            proxy_set_header Host $host:$server_port;
        }
    }

负载均衡

负载均衡也是Nginx常用的一个功能，负载均衡其意思就是分摊到多个操作单元上进行执行从而共同完成工作任务。简单而言就是当有2台或以上服务器时，根据规则随机的将请求分发到指定的服务器上处理，负载均衡配置一般都需要同时配置反向代理，通过反向代理跳转到负载均衡。而Nginx目前支持自带3种负载均衡策略，还有2种常用的第三方策略。

RR

每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。

    upstream test {
        server localhost:8080;
        server localhost:8081;
    }
    server {
        listen       81;                                                         
        server_name  localhost;                                               
        client_max_body_size 1024M;

        location / {
            proxy_pass http://test;
            proxy_set_header Host $host:$server_port;
        }
    }

权重

指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况。

    upstream test {
        server localhost:8080 weight=9;
        server localhost:8081 weight=1;
    }

ip_hash

iphash的每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题。

    upstream test {
        ip_hash;
        server localhost:8080;
        server localhost:8081;
    }

fair

按后端服务器的响应时间来分配请求，响应时间短的优先分配。

    upstream backend { 
        fair; 
        server localhost:8080;
        server localhost:8081;
    } 

url_hash

按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，后端服务器为缓存时比较有效。

    upstream backend { 
        hash $request_uri; 
        hash_method crc32; 
        server localhost:8080;
        server localhost:8081;
    } 

动静分离

upstream test{  
       server localhost:8080;  
       server localhost:8081;  
    }   

    server {  
        listen       80;  
        server_name  localhost;  

        location / {  
            root   e:wwwroot;  
            index  index.html;  
        }  

        # 所有静态请求都由nginx处理，存放目录为html  
        location ~ .(gif|jpg|jpeg|png|bmp|swf|css|js)$ {  
            root    e:wwwroot;  
        }  

        # 所有动态请求都转发给tomcat处理  
        location ~ .(jsp|do)$ {  
            proxy_pass  http://test;  
        }  

        error_page   500 502 503 504  /50x.html;  
        location = /50x.html {  
            root   e:wwwroot;  
        }  
    }  

参考文章：

1. 全面了解 Nginx 主要应用场景