web开发架构设计

发布时间：2024-04-03 22:12:45 来源：互联网

.

2015-07-31 13:10:38 一, web服务器负载均衡不做对URL的rewrite逻辑判断, 全部转发到代码服务器的单一入口文件, 由代码去全

2015-07-31 13:10:38

一, web服务器

　　.负载均衡

　　.不做对URL的rewrite逻辑判断, 全部转发到代码服务器的单一入口文件, 由代码去全权处理

二, 代码服务器(常跟web服务器在一台机器上)

　　.单一入口, 在入口处准备好基本数据(userinfo, 数据库配置, 缓存配置, 云服务配置, 当前URL, 请求参数(模块名, controller, action, view...), 登录URL, 退出URL...全局变量 ), 不再后续重复去查询

　　.服务化/微服务, 用户/会员管理系统, 支付系统, 论坛系统, 全文搜索服务等等, 都可单独部署

　　.数据库表名, 缓存前缀名, 全局变量参数等等在统一的文件里管理, 方便协同开发

　　.每台机器启用多个实例(PHP用php-fpm去管理, 或者启用多个PHP-fpm, 通过监听不同的端口,或者, 使用不通的配置文件来启动多个实例)

三, 数据库服务器

　　.底层数据字段尽可能的分散, 因为整合容易, 拆分麻烦, 可以通过视图等方式合并显示给业务逻辑层

　　.门户型/垂直型的网站, 其各个子行业站如果不交叉关联就可以做成分散的

　　.例如, 医药和金融的数据会很不一样, 可以分开建库和表; 鞋子和衣服的数据(尺码, 适用季节等)有交叉, 但分类明确; 机械工具类垂直网站, 机床可以制造其他所有工具, 其他工具有可以组装成另外的工具, 其数据属性比较类似(尺寸, 口径, 功率.....), 分类比较模糊, 搜索时不宜通过关键词区分, 可以考虑整合到一个库中.... 具体的还得根据业务来

　　.主从到集群, 做成中间件, 对代码访问透明

　　.惰性事务, 代码层面处理, 失败了循环再尝试, 而不是回滚

　　.代码层面宁可select_in 多几次查询(每个结果集之间用某个id关联), 也不要去join查询, join语句肯定会根据业务场景的不通去if_else组装而成, 很难维护, 查询很慢

　　.不要用外键, 系统的运行100%的时间都是在不断维护升级, 添加外键是给自己找麻烦, 线下测试不方便, 后来的人不愿意去维护改善.....

　　.每个表有一个同一的自增的字段叫id, 设计数据库的时间久了就明白了

　　.SQL语句中不要使用MySQL函数, 主要是为了效率和可读, 这样可以将逻辑计算分摊给PHP甚至js, 给系统减压

　　.最重要的, 也最容易忘记的, 索引!!!

四, 缓存服务器

　　.redis(sentinel)/memcache 做成对代码透明的中间件, PHP只管read/write, 不用区分是master/slave

　　.按照业务逻辑划分, 按照哈希结果(直接用户名hash, 如果userid可传递, 直接按照userid去hash到不同的机器上分担压力也可以)....每个单独的业务都必须有主从

五, 全文检索服务器

　　.sphinx/coreseek