巴厘岛会议感想

– 过程要有邮件总结与输出,定期向boss汇报
– KPI是手段,但更是入场券、分数线
相对于业务里的亮点,KPI是必要条件。
– boss的想法就像狐狸,是跟着狐狸尾巴跑,还是跟着脑袋,这是个问题
– 一味模仿、一味追随很忙很累,也容易被人远远甩在后面
– 管理boss预期
要相信你在业务上是专家,当然,最好要有依据支撑
– 我平常有些事情答应太快,同时也缺乏持续的目标

2009系统架构师大会听课笔记

周末参加了2009系统架构师大会,期间对自己感兴趣的话题做了部分笔记,现摘录如下:

大型可扩展系统架构-新浪网动态应用平台介绍

童剑 新浪高级系统架构师,研发中心平台部总监

 - 资源监控
 - HA Xen虚拟化
 - 数据库集群

 2006年点击量3亿/天
 实时访问统计,考虑恶意访问
 代码分发、数据库集群、软件仓库

 高可用、低成本、可扩展
 - 无单点故障
 - 基于开源软件
 - 各部门共享、对外透明
   统一运行环境
 - 统一配置
 简单映像体系
  (程序员看来)一个数据库、一个前台、一个缓存

 架构图
            |---> Cache ----->| 
 负载平衡 --|     \|/         | VFS
            |---> App ------->|

 用到的软件
 - LAMP
 - Memecached
 - Squid-Cache
 - Heartbeat + DRBD
 - Xen
 - Cfengine
 - Bind DNS + Mon
 - Haproxy

一些经验
 - 借鉴成功经验
   如LiveJournal(Memcached、MogileFS)、Yahoo、Google、FaceBook等
 - 使用成熟软件
   重复造的轮子维护困难、不便于交接
 - 底层封装和隔离
   可扩展
 - 简单 = 高效
   够用、分阶段完善、简单(结构设计+实现方法) = 高效(开发过程 + 故障排除)
标准化配置
 - 好处
   开发生产分离、配置文件
 - 运行环境配置
   软件包、版本、路径、用户等
   记录请求时长、MySQL慢日志
   常用配置统一
 - 其他...
约定和限制
 - 基本约定
   读写分离、缓存尽量使用Memcache、不用绝对路径、程序目录+x-w、数据库目录+w-x、不使用长连接、耗时查询小于1次/分钟
 - 必要配置
   涉及PHP安全方面的配置等
监控报警
 - 详细感知
 - 自动控制和修复
 - 日志统计分析
 - 数据监控
	* 可用性(ping/port/disk usage)
	* 容量(带宽、磁盘、CPU)
	* 质量(响应速度、成功率)
	* 异常(进程、访问量)
 - 主动处理尝试
	* 拒绝恶意IP
	* 暂停异常服务
	* kill异常进程
 - 报警
	* 仪表板
	* Email
	* SMS
	* IM
性能
 - 高可用
 - 开发语言的选择
   如果对CPU等资源占用不大,可选择解释性脚本语言(C虽然高效,但是从头再来毕竟耗费人力物力)
 - 选择合适的服务器软件
   高并发高IO时可选择Nginx/lighttpd
 - 软硬件因素
 - 网络性能
   应熟悉常见现象
 - 性能分析
   对症下药才能治本
容量规划
 - 负载 < CPU的核数
 - 平常占用资源的40%,峰值80%
 - 60%扩容
 - 20% 保留给系统管理和监控使用

 提问:如果多个机房中的某个机房的服务器出现问题,怎么做到切换服务器不影响访问?
 回到:在DNS里设置某个域名的相应时间,所有Name Server都应该遵循该规范

Facebook最佳实践:从百万访问到千万并发访问

吴静涛:F5中国技术总监,高级架构师

- 柔性可用
- 客户诊断
- 降级服务
故障梯度服务(以qzone为例)
 - 100% 最优
 - 80% 取消增值服务
 - 50% 基础功能
 - 20% 核心功能
 - 5% 公告
缓存、性能
 - 用户端Cache
 - CDN
 - 核心动态数据
 - 提升动态数据能力
   TTC : 腾讯内存Cache集群
   TTC1、TTC2 ----> DB
   TTC1、TTC2 --> TTC0 ---> DB
 - UGC内容放入存储平台
 - 按需加载
 - 检测平台、持续优化
其他
 - 产品削锋填谷
   以前一天只允许在0点开始买卖奴隶,造成该时段访问压力特别大,经产品策划协商,
   更改策略:一天内0 - 9点均可开始买卖努力,但早上6点前买卖奴隶收入减半。。从
   而通过策略将峰值下降很多
 - 集群、轻量、标准
  GSLB + LVS + Qzhttp
 - 轻量内存
  TTC + MySQL
 - 逻辑?
   S++ ?
 - 海量数据存储
   TFS、TDB
 - 削锋填谷
	* 明星 - 低
	* 金牛 - 合理
	* 瘦狗 - 高
其他:采集用户打开时间、多写少读(可在内存里积累一定的程度再去写)

电子支付系统的分布式服务架构与开放架构研究(PPT)

程立:支付宝(中国)网络技术有限公司 首席架构师

 - SOA
 性能、响应时间、指标
 Async异步调用、future异步调用
 - 容量
	* 估算新业务上线对容量的需求
	* 服务吞吐量优化
	 	- 服务吞吐量
		- 伸缩公式
		- 伸缩上限
		- 单个资源吞吐量上限(串行处理)
	* 解决
		- 充分扩容
		- 平衡扩容
		- 消除单点瓶颈
	* 资源使用分析、SQL执行次数
	* 单点故障
		- 并发请求
		- 重复请求
		- 超量请求
		- 请求挤压
 - 其他
	* 局部配额、令牌
	* 幂等控制、操作日志
	* 并发控制
	 	- 经典方法(事务)
		- 乐观方法(减少事务使用时间)
		- 分布锁(生命周期、防止死锁)
	* 请求丢弃
	  过期就丢弃相应的请求
	* 时间控制
	  整体服务期限
	* 分布事务
     	- TCC模式
		  Try - Confirm -Cancle
		- 补偿模式
		  Do - 补偿

探寻架构设计中的第六感(新浪网)

李晓栋:新浪网研发中心架构部 技术经理

- QOS
- TCP/IP协议先天不足
 - 管理心得
 	* 集中管理
	* 监控报警
	* 负载分析
	* 服务配置
 - 原则
 	* 高性能
	* 高可靠性
	* 高可管理性
 - 流量快速分析
 	* MRTG、ARTU
	* netflow、sflow、SNMP、Sniffer(pfring)
	* payload、wireshark
 - 平台使用方法
   * tcpdump抓包
   * 上传pcap包
   * 选择分析条件
   * 输出分析结果
 - misc
 	* 交换机(prot-channel)
	* LVS特殊单臂解决方案
	* PK麻烦且变更不便
	* 利用iptables获取TCP端口流量统计
	* 网页挂马的JS?

淘宝开放平台架构设计与实践

岑文初: 淘宝网开放平台架构师

 - 异步交互、通知
	* 保持会话、支持异步(短信)
	* 异步延时(大数据管理信息)
	* 订阅关系维护、支持通知服务(系统间数据同步)
 - 服务分流与隔离
 	二级域名(某API) --> 软负载(LVS、7层包、HA) --> 软负载 + 虚拟服务组(图)
	上下文缓存
 - 本地缓存、远程缓存
 - 商业方面
 	* 流量收费(调用接口)
	* 插件分成

高可用分布式数据库系统架构实践(Oracle\Mysql等数据库)

陈吉平:淘宝网技术总监、首席DBA、DBA Manager、Oracle ACE

 - 分布式
  分布式存储(TFS)、分布式Cache(Caire)
 - 高可用之双机房架构
  Data Guard + Redo mirror
 - V3.0垂直扩展
   用户、商品...
   非核心数据使用MySQL
 - V4.0 水平扩展 - 读写分离
 - V4.0 水平扩展 - 水平拆分
 	* Scale Out
	* 压力动态平衡
	* 支持任何数据库
 - Amazon、S3、EC2、Simple DB
 - C1 读写分离
 	* 主库集中,读库水平分割
	* 写操作、部分重要读操作回主库
	* 读库故障可回主库
	* APP -> TDDL
	* 数据路由、数据复制
 - C2 水平分割
 	* 16DB 1024张表,单表16亿条记录
	* 避免无限制分表
	* 没有主数据库
 - 监控
 	* DB、Host
	* SNMP ? => Agent??

Mysql数据库性能优化实战

叶金荣:搜狐游戏高级MySQL DBA

 - 常用命令
  	*  vmstats
	   vmstatus -s n 3
	*  iostats
	*  pidstat
	*  mpstats
	*  top
	*  sar
 - 诊断方法
	* mysql slow query
	* show engine innodbstatus
	* profiling
	* mysql report
 - 杂项
 	* 禁用swap
	* micro slow补丁 可显示详细执行计划
	* mysqlsla
	* 数据库擅长的事情:存储数据 + 事务
	* query cache可适当降低,可通过profiling查看,太大会引发新问题
	* sending data值的设置
	  只查询需要的字段即可
	* freeing items
	* 关闭binlogs
	* ssd 文件系统优化
	* xfs文件系统存储单个大文件有优势
	* 静态编译mysql速度也会提升
	* DNS管理系统
	* innodb buffer
	* 5.0.77 higerreat版本
 - 一些引擎
  	* MySIAM
	* InnoDB
	* TukoDB
	* XtraDB
	* Memcache for MySQL
	* waffle Grid Project
 - InnoDB Plugin 1.1
 	* 可快速创建索引
	* 数据压缩
	* 可在线设置是否单表使用空间
 - misc
 	* OLTP/OLAP 应用类型
	* COUNT(*)将进行全表扫描、InnoDB的表推荐使用COUNT(PK)

update:

按计划行事

随着时间的积累,以前大家的工作方式逐渐变得混乱,领导审时度势组织大家开了一次小会。本没有对这场中午的小会抱多大希望,但“develop with pleasure”的主题货真价实,听完之后犹如醍醐灌顶般恍然大悟,感觉以前没有头绪的事情一下子有了眉目。

对于维护上线的web项目,以往的做法是发现错误随时更正。这种松散的方式看起来很辛苦,但效率总是不高,而且还极易处于被动的地位。另外一种方式的好处就显而易见了,根据各种需求、计划、决策、反馈制定一个短期的版本计划,定期发布。根据该计划,线上的每次改动都将对应代码仓库里的一个版本,这样即便是某次发布时出现错误,也可以很容易恢复到稳定版本。除了版本发布操作,不再零散更新线上的文件。如果想灵活一些,还可以缩短计划中的开发周期。

以前没有仔细考虑过类似的问题,或许这只是项目管理中的冰山一角。其实很多事情都是相通的,就拿上文中的按计划发布版本来说,早在大学时班主任就曾多次向我们灌输计划、总结的重要性,当时可能也听了,只是没真正体会到它的重要性。

总之一句话:事前计划,事后总结。
就这。

btw,新增一个”快乐开发 | developer”分类,今后用于存放类似问题。