最近这段时间工作上的变动有点大,五月份也闲了下来一直在思考自己接下来的方向,并对这一年来的学习进行总结.
对于架构上的深入是这一年多来最主要的沉淀,从小公司到大公司,从小流量的站点的架构设计到大流量乃至超大流量的架构设计,记录下来,分享出来。
在分享自己的那点料之前,先来分享下大神Tim Yang的关于微博的架构设计：
这里主要从 存储和接口角度来讲
对于大流量系统的架构设计，对于写入方面是特别需要注意的，基本上现在遇到的系统都是对于主数据库的写入，然后对于从数据库实现流量的分发。
对于存储，记得公司老大说过，对于BD的项目的架构如果从设计上可以达到20PB的存储规模不出什么大的问题，就说明这个架构设计是合格的。
对于存储，新浪微博使用了redis的部分功能,主要用在用户信息方面的使用,现在只有单机设计,但是对于现在的单机完全可以提供大量的内存比如32G以上，完全可以达到存储数据的要求。
对于MYSQL这里所涉及到的就是设计规范和分库分表，最大的感触是大家为了便利就直接用自增的ID来进行，对于唯一ID的设计也是我一直注意的，因为唯一的设计是涉及到全局的。
将将自己最近总结的PHP和微博架构方面：
1.进行快速开发的过程中，订好规范，按照规范执行是非常的重要的，涉及到的沟通会比较少，其实和其他人联调是很费时间的。
2.对于性能跟踪方面使用使用xhprof来跟踪PHP的执行过程及性能问题，可以初略的估计出来。
3.对于核心代码的复用程度及核心的代码量的把握，核心要灵活可扩展而且保持小
4.技术选型比如对于使用memcache扩展和memcached的扩展还是很重要的
5.对于代码的目录结构和命名还是挺重要的,php的autoload不要搜索太多的目录会比较好
6.考虑下工具类的复用，一直在造轮子每次都重写一遍，这个不是很郁闷的事情，怎么样让这些类不要耦合的太紧？设计很重要
7.对于有些服务是PHP做起来不合适的,比如spam模块的高危词过滤还是用C/C++模块来处理比较好。
8.微博技术的应用Inbox/Outbox/Timeline/Following/Follows/Feed/MQS
9.推荐算法和消息推送的处理，各种高并发的处理