今天和运维同事讨论了下Q1的计划,我比较坚持80/20的原则,改造的最终目标应该是和用户直接有关的,边边角角的应该暂时放弃,说到“以后”这个词,都快麻木了，觉得缺少冲劲了，不过应该是冲动转换为成熟了。明天目标是将具体时间点列出来。
顺带看了几个ppt,主要是关于淘宝的.
1:基于java构建的淘宝.
1）汗颜的是淘宝的v1阶段是我们面前的阶段。主要几个问题和我们比较类似:
不利于团队开发/不利于长期持续发展/无技术积累
2) 对应淘宝的V2阶段是我们今年现实的目标:
支持高速业务发展/支持团队并行开发/支持系统的可伸缩
具体实现了一个MVC框架,有几个思想比较赞同:模块化/pipeline/支持多模版引擎。
另外对于一个大型系统,分布式文件系统和分布式缓存也是必须的.
3) 淘宝的V3阶段已经比较靠近ebay的思想,包括可重用性/可用性/透明的数据库伸缩性.
终极目标是开放平台.
具体的一些做法就是：数据和应用分离/消息系统/服务化的开发模式.
可用性包括同城分流和异地容灾,这也是我们将来的IDC自治的目标。
主要是一个ppt,无法了解更详细的一些信息。。
2:淘宝架构师岑文初写的关于应用架构设计“防火”经验
1)资源是有限的/依赖是未知的:解决的方法就是对于资源的监控和预警,排队.
对于非核心业务尽量异步操作.
2)原子操作/并发控制:尤其是在分布式系统中.
3)接口实现和松耦合/:模块间的交互一定要通过接口来实现,避免业务的修改直接影响业务调用方.这也是我们目前的问题，另外松耦合不代表框架僵硬,要尽量灵活.
4)灵活性/性能/可维护性的折中,对于我们这样的大系统,也许可维护性是第一位的.
5)要有分布式和并发的观念，但是不要本末倒置:不要为了分布式而分布式,这是我们这次设计的需要注意的点,我们好像是先有IDC自治这个目标,这是一个很不好的现象.
6)多级缓存和异步缓解异构系统的瓶颈:我们目前用到很多的外部接口，依赖他们是不正常的。需要通过异步和cache的概念去弱化
7)防止系统设计的完备性成为攻击或者压力的瓶颈:没想到如何描述比较好.
8)运行期白盒化，模块可重置:模块设计需要注意的点,不能完全不知道内部是如何实现的.
9)主流程和副流程隔离:完成核心功能为主,也方便优雅降级
10)模块间接口交互，控制资源直接操作入口.模块设计中绝对不允许直接操作资源，导致后续管理混乱。
11)站在用户角度设计接口，提升系统可用性:避免设计的东西无法使用,也避免设计的复杂度过高
12)不要迷信，要多学习其他的一些东西,比如我现在就要学习ria,系统的一些知识.
PS：很少用公司的产品,发现一个普通用户对于一些操作是很看重的,比如丢文章。
今天犯的几个错误:
1:还是有点冲动,还是要淡定.
2:一下子陷入分库/分表的误区
3:任何一个功能,就首先去想如何实现...
4:考虑事情不能受其他的一些因素影响.