今天和运维同事讨论了下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:考虑事情不能受其他的一些因素影响.

建议继续学习：

1. 淘宝图片存储架构    (阅读：9934)
2. 淘宝和阿里巴巴去Oracle化事件 引发数据库技术人员大讨论    (阅读：4006)
3. 产品设计之QQ邮箱登录页与淘宝登录页    (阅读：3511)
4. 淘宝图片服务的学习    (阅读：3316)
5. 产品设计之QQ邮箱登录页与淘宝登录页    (阅读：2861)
6. 常见的几种淘宝店主营销手段    (阅读：2315)
7. 给小姑讲淘宝开店    (阅读：2226)
8. 在淘宝大半年的零散体会    (阅读：2203)
9. 技术文化和惨淡命运 ―― 怀念中国雅虎    (阅读：2092)
10. When we`re only No.2, we try harder之淘宝节日LOGO互动设计小探讨    (阅读：1934)