热门话题
-
近期文章
我的围脖
我的豆列
标签归档：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)
