Tag Archives: Architecture
服务管理框架
使大型分布式系统大型服务化之后足高可用及低运营成本，新的系统架构需要满足以下条件： 1. 服务管理框架需要具备的功能 1.1. 容错性 failover：客户端容错支持，并支持自动失效探测及恢复调用； failfast：快速失败。很多远程服务调用是在关键路径中，它可以容忍失败，但是不能容忍堵塞； failback：故障恢复。能够快速定位错误，进行reset来尝试恢复。 1.2. 中心化的运营管理 相关日志 我们能在SOA架构里添加哪些特性？ (2) SOA架构设计概要 (0) SaaS迁移模式 (0) QCon第三天见闻 (1) 网络应用系统设计的基本原则 (0)
淘宝技术沙龙后记
淘宝马震的分享 周六参加了aDev(注)淘宝技术嘉年华技术交流，淘宝马震分享的《消息中间件在大型分布式系统的应用》非常不错。他们目前自行研发了Notify和Meta Morphosis两款中间件。后者是用Scala写得开源MQ Kafka的Java版（注）。 对技术架构和使用场景都进行了介绍。 消息中间件应用场景 分布式事务最终一致性：能够保证SOA架构下全局数据的最终一致； 数据复制：Binlog和日志都可以进队列。同类产品可以参考Twitter的Storm； delay queue(定时器）：可靠的延迟队列，可以作为分布式环境下的定时器； 广播通知：避免广播风暴，可以为cache失效进行通知 注 感谢lazycai的分享和更正 ppt可以通过关注淘宝技术嘉年华： @taobaodeveloperclub 获得。 有关淘宝中间件的更多信息，参考 http://rdc.taobao.com/team/jm/archives/921 孙立的Fast Queue ppt在这里： http://www.slideshare.net/sunli1223/fqueue 特点就是非常快，不支持集群。 新浪微博的大管子php 非常感谢新阳给我讲了这个前端技术的实现方式和应用场景，我可以放心回家睡觉了。 注 aDev一个面向后端的技术品牌，主要关注的是后端技术。关注开发人员和架构师在完成不同系统中的问题解决和经验实战，以及相关的技术趋势。微博上可以关注@Tech-aDev 强烈建议热爱技术的少壮们有空参加！ 相关日志 淘宝技术沙龙 (2) 网络应用系统设计的基本原则 (0) 现有架构中数据存储面临的挑战与应对 (1) 服务管理框架 (2) 我们能在SOA架构里添加哪些特性？ (2)
淘宝技术沙龙
明天去参加淘宝组织的技术沙龙。 地点：京仪大酒店第一会议室 时间：11年11月26日14:00 – 18:00 技术主题：异步化技术在大型系统中的运用 相关日志 淘宝技术沙龙后记 (3) 网络应用系统设计的基本原则 (0) 现有架构中数据存储面临的挑战与应对 (1) 服务管理框架 (2) 我们能在SOA架构里添加哪些特性？ (2)
SOA架构设计概要
主要内容也是来自《SteveY对Amazon和Google平台的长篇大论》 1. 通过服务接口提供全部数据和操作 我们理解的SOA必然是通过接口的方式将数据与功能开放出来的，但要想要往平台方向发展，必须保证用且仅用服务接口的形式提供数据和服务： 团队间的程序模块的信息通信，都要通过这些接口； 除此之外没有其它的通信方式。其他形式一概不允许：不能直接读取其他团队的数据库、不能使用共享内存模式、不能使用别人模块的后门； 所有的程序都必须从骨子里到表面都要设计成能对外界开放的。也就是说，团队必须做好规划与设计，以便把接口开放给全世界的程序员，没有例外。 相关日志 服务管理框架 (2) 我们能在SOA架构里添加哪些特性？ (2) SaaS迁移模式 (0) QCon第三天见闻 (1) 网络应用系统设计的基本原则 (0)
我们能在SOA架构里添加哪些特性？
新阳写了一个很棒的Thrift技术演进方案，甚至包含了架构基础代码。这个SOA方案有以下几个闪亮的特性： 1. 可用性：消除单点故障隐患，提供水平扩容的基础； 2. 可维护性：提高服务监控的粒度、规范化程度、自动化程度 3. 可改进性：包括Client端调用方式和Server端实现方式 这个方案最大的亮点就是层次分明：虽然是为Thrift量身定做的技术架构，但这些特性对采取什么具体技术来说并没有强制性的要求。 那么还有没有其它需求可以在SOA框架中满足呢？判断标准又是什么呢？我给出我的思考，希望能看到大家的真知灼见。 首先先给出选择特性的基本原则，然后讨论要为需求提供的特性及实现思路。 相关日志 服务管理框架 (2) SOA架构设计概要 (0) SaaS迁移模式 (0) QCon第三天见闻 (1) 网络应用系统设计的基本原则 (0)
[推荐]一篇介绍数据挖掘系统架构的文章
云时代的企业应用数据挖掘：http://www.programmer.com.cn/7280/ 1. 三火点评 本文从概念和架构层面给出了异构数据源海量数据挖掘的工作思路。 在系统建设过程上，分为建模、挖掘和呈现三个阶段； 在系统架构上，包括支持海量数据的分布存储部分、支持高速并行运算的MapReduce部分和高效的BI呈现部分。 对从事相关工作的产品运营和技术实施人员都有参考价值。 相关日志 网络应用系统设计的基本原则 (0) 现有架构中数据存储面临的挑战与应对 (1) 淘宝技术沙龙后记 (3) 淘宝技术沙龙 (2) 服务管理框架 (2)
QCon第一天见闻
昨天回家就被感冒病毒和化脓的扁桃体给击倒了。不过经过一晚的充足睡眠和apple的精心照料，今天我又生龙活虎了。 简单回顾一下昨天的会议吧。BTW，ppt已经都提供下载了，会议主办者相当给力。 相关日志 网络应用系统设计的基本原则 (0) 【技术架构】豆瓣网技术架构变迁 (0) QCon第二天见闻 (0) QCon第三天见闻 (1) QCon第一天见闻 (0)
ThoughtWorks Technology Radar
ThoughtWorks在技术领域的前瞻性报告“技术雷达”，对IT公司的技术选型、开发人员在职业规划中选择技术路线都有借鉴意义。 http://www.thoughtworks.com/radar/ 相关日志 网络应用系统设计的基本原则 (0) 程序员职场生涯n次转型 (0) 程序员的使命、价值和工作思路 (0) 现有架构中数据存储面临的挑战与应对 (1) 淘宝技术沙龙后记 (3)
现有架构中数据存储面临的挑战与应对
传统数据库方案(Oracle)面临的挑战 High Performance: 高并发的读写 高并发读写造成的锁等待问题 Huge Storage: 海量数据的存储和访问 传统数据库对海量XML数据结构的存储解决方案不太友好，类似vCard的存储 High Scalability & High Available: 高扩展性和高可用性 传统数据库Scale Out的解决方案复杂性高（业务相关的）且代价高 现有架构中数据存储面临的挑战 OLTP到OLAP的数据同步，实时性要求越来越高 我们很早就做到了OLTP和OLAP系统分开的： OLTP（On-Line Transaction Processing）联机事务处理：OSS OLAP（On-Line Analytical Processing）联机分析处理：DA-Server， SBX 但越来越多的数据分析需求，要求能够获得实时性性更高的数据。而高实时性会增加同步的代价。 业务间对共有数据操作的竞争 相关日志 网络应用系统设计的基本原则 (0) 淘宝技术沙龙后记 (3) 淘宝技术沙龙 (2) 服务管理框架 (2) 我们能在SOA架构里添加哪些特性？ (2)
网络应用系统设计的基本原则
- 系统功能
KISS原则: keep it simple and stupid
主要是需求阶段，需要加强把控，开发人员要有意识，引导需求方。
- 系统实现
容错原则：Design with failure in mind
因为没有无故障的软件
也没有无故障的硬件
，所以，没有无故障的系统。
过犹不及原则：Just in time
. 设计够用就好
. 部分重构优于整体重构
和前面的KISS原则可以接合着一块用。另外8020原则也差不多是这个意思。
- 系统架构
数据拆分原则：Partition your data
. 负载均衡
. 容易继续拆
. 减少依赖
冗余原则：Redundancy
. 减少单点故障
. 系统能够自动恢复
监控原则：Monitor, monitor, monitor
. 业务透明
. 多角度：客户角度和系统角度
