淘宝的一些架构
今天和运维同事讨论了下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:考虑事情不能受其他的一些因素影响.
建议继续学习:
- 淘宝图片存储架构 (阅读:9810)
- 淘宝和阿里巴巴去Oracle化事件 引发数据库技术人员大讨论 (阅读:3987)
- 产品设计之QQ邮箱登录页与淘宝登录页 (阅读:3422)
- 淘宝图片服务的学习 (阅读:3234)
- 产品设计之QQ邮箱登录页与淘宝登录页 (阅读:2841)
- 常见的几种淘宝店主营销手段 (阅读:2294)
- 给小姑讲淘宝开店 (阅读:2200)
- 在淘宝大半年的零散体会 (阅读:2133)
- 技术文化和惨淡命运 ―― 怀念中国雅虎 (阅读:2027)
- When we`re only No.2, we try harder之淘宝节日LOGO互动设计小探讨 (阅读:1916)
扫一扫订阅我的微信号:IT技术博客大学习
- 作者:ywdblog 来源: 技术 总结 记录 生活 工作
- 标签: 以后 淘宝
- 发布时间:2010-04-19 12:43:59
- [66] Go Reflect 性能
- [65] Oracle MTS模式下 进程地址与会话信
- [64] 如何拿下简短的域名
- [59] android 开发入门
- [59] IOS安全–浅谈关于IOS加固的几种方法
- [58] 图书馆的世界纪录
- [58] 【社会化设计】自我(self)部分――欢迎区
- [53] 视觉调整-设计师 vs. 逻辑
- [47] 界面设计速成
- [46] 读书笔记-壹百度:百度十年千倍的29条法则