2015-07-31 13:10:38
一, web服务器
.负载均衡
.不做对URL的rewrite逻辑判断, 全部转发到代码服务器的单一入口文件, 由代码去全权处理
二, 代码服务器
.单一入口, 在入口处准备好基本数据(userinfo, 数据库配置, 缓存配置, 云服务配置, 当前URL, 请求参数(模块名, controller, action, view...), 登录URL, 退出URL...全局变量 ), 不再后续重复去查询
.服务化/微服务, 用户/会员管理系统, 支付系统, 论坛系统, 全文搜索服务等等, 都可单独部署
.数据库表名, 缓存前缀名, 全局变量参数等等在统一的文件里管理, 方便协同开发
三, 数据库服务器
.底层数据字段尽可能的分散, 因为整合容易, 拆分麻烦, 可以通过视图等方式合并显示给业务逻辑层
.门户型/垂直型的网站, 其各个子行业站如果不交叉关联就可以做成分散的
.例如, 医药和金融的数据会很不一样, 可以分开建库和表; 鞋子和衣服的数据(尺码, 适用季节等)有交叉, 但分类明确; 机械工具类垂直网站, 机床可以制造其他所有工具, 其他工具有可以组装成另外的工具, 其数据属性比较类似(尺寸, 口径, 功率.....), 分类比较模糊, 搜索时不宜通过关键词区分, 可以考虑整合到一个库中.... 具体的还得根据业务来
.主从到集群, 做成中间件, 对代码访问透明
.惰性事务, 代码层面处理, 失败了循环再尝试, 而不是回滚
.代码层面宁可select_in 多几次查询(每个结果集之间用某个id关联), 也不要去join查询, join语句肯定会根据业务场景的不通去if_else组装而成, 很难维护, 查询很慢
.不要用外键, 系统的运行100%的时间都是在不断维护升级, 添加外键是给自己找麻烦, 线下测试不方便, 后来的人不愿意去维护改善.....
.每个表有一个同一的自增的字段叫id, 设计数据库的时间久了就明白了
.最重要的, 也最容易忘记的, 索引!!!
四, 缓存服务器
.redis(sentinel)/memcache 做成对代码透明的中间件, PHP只管read/write, 不用区分是master/slave
.按照业务逻辑划分, 按照哈希结果(直接用户名hash, 如果userid可传递, 直接按照userid去hash到不同的机器上分担压力也可以)....每个单独的业务都必须有主从
五, 全文检索服务器
.sphinx/coreseek
.xunsearch
六, 自动化部署
.docker
.后端前端公用开发用代码测试机, 数据库测试机, 定期同步线上数据
.预发布机, 除了不被负载均衡找到外, 跟线上代码服务器无区别, 可以被开发人员访问, 保存最近几次正确的代码版本, 用于发错回退(非SVN回退)
.服务化/微服务, 单元部署不依赖
七, 压力测试
.Locust
八, 本地开发
.docker或虚拟机给开发人员创建模拟线上的开发环境, 本地通过ssh/samba去开发虚拟机上的代码: 避免过多线上线下差异, 开发者电脑很轻, 只用安装写代码的IDE
.配置文件里不要用IP指向数据库和缓存等服务器, 要用域名, 保证线上线下的配置文件不会差异太大, 方便代码部署, 由运维的同学在相应的服务器端做ip解析
.本地开发机的nginx根目录(单一入口)指向index_dev.php里边加载线下的配置文件, 线上的nginx/Apache指向index.php这个里边加载线上的配置
.框架支持前后端分离开发
九, SVN/GIT 版本控制服务器
.master版本库+slave版本库, 开发者提交合并到slave上, 由管理员再合并提交到master版本库中(大型开发)
十, VPN
.查资料, 在家办公
十一, 监控集群
.ganglia
十二, 人员配置
.不要跟下属争利
.不要耍权利制衡的小聪明
.不要过分拆分业务给不同的开发去做, 要每个人掌握一条业务的始终(前端数据提供, 数据逻辑处理, 后台管理), 有归属感, 有成就感, 各种更快更长久
.前后端开发分开, 在自己擅长的战场工作, 整体推进效率更高
. 运维人员, 开发人员, DBA, 测试, 架构......
十三, 业务
.引流业务: 资讯, 论坛, 活动...
.变现业务: 广告, 游戏, 彩票, 电子商务...
十四, 队列服务器
.异步记录日志
.统计
.缓解并发
十五, 及时通讯/聊天服务器
.推送系统
.客服系统
十六, 服务降级