SDCC 2015架构专场:一线互联网公司论道架构实践(PPT全回顾)

2016年3月18日-19日,由CSDN重磅打造的数据库核心技术与实战应用峰会、互联网应用架构实战峰会将在上海举行。作为SDCC 2016(中国软件开发者大会)系列技术峰会的一部分,活动继续秉承干货实料(案例)为主的内容原则,这两场峰会将邀请业内顶尖的架构师和技术专家,共同探讨高可用/高并发系统架构设计、新技术应用、移动应用架构、微服务、智能硬件架构、云数据库实战、新一代数据库平台、产品选型、性能调优、大数据应用实战等领域的热点话题与技术。

2月29日24点前仍处于最低六折优惠票价阶段,单场峰会(含餐)门票只需799元,5人以上团购或者购买两场峰会通票更有特惠,限量供应,预购从速。(票务详情链接)。

始建于2007年的SDCC已经成功举办七届、历届技术讲师超过550位、参会人数超过7500人,SDCC也已成为技术圈口碑卓越的技术会议品牌。现在,让我们一起来回顾下,SDCC 2015架构专场的那些精彩,再一次的超干干货。

图片描述

SDCC 2015架构专场讲师合影。

航天信息系统架构师 范钢:互联网+时代下的架构转型(PPT下载

航天信息系统架构师 范钢带来《互联网+时代下的架构转型》主题演讲。范钢表示,好的架构源于不停地衍变。从购物(商城→双11)、订票(购票大厅→网络购票)到打车(街上叫车→打车神器),“互联网+”为我们带来了巨大的变革。但是,作为架构师,在“互联网+”之下,其实承受着诸多压力,面对着瞬时峰值和业务量增长等,架构师需要不断地进行技术升级和改造。

然而,技术升级与改造并非一帆风顺,范钢以自身的实践经验分享了架构师的“八年抗战”,详解为何技术改造会失败及其面临的风险与挑战。首先,原系统积累了大量细微而繁复的逻辑,如果新系统没能正确识别将会让用户对新系统丧失信心。而重做虽然可以快速而有效地摆脱原有系统的技术债务,却也为技术改造带来了极大的项目风险。

图片描述

图:像更换零件一样更新系统

范钢建议,应采取渐进式的技术改造,让系统适于技术改造,平滑地移植代码,通过对内部结构的优化,使得业务代码逐渐与各个层次、各种技术解耦,最终像更换零件一样更新系统。

搜狗架构师 刘建:搜狗商业平台基础架构演化实践(PPT下载

搜狗架构师刘建基于“搜狗商业平台基础架构演化史”详解了快速迭代下基础架构的演化实践。一个好的基础架构应提供高性能、高可用、高可扩展性的业务支撑平台,支持敏捷业务开发,提升研发效率,并降低运维成本。

从初期的技术服务于业务、优先功能的快速构建、基于数据库交互、团队相对独立,选择合适/熟悉的技术到业务高速发展时期,基础架构面临着性能、可维护性、协作、成本与收益降低等挑战。刘建现场分享了搜狗基础架构探索出来的“四步走”:

  1. 初始阶段——All-In-One、快速原型、基于开源/经验、团队独立;
  2. 水平化——分布式会话、数据库访问框架、MongoDB访问框架;
  3. 服务化——统一通讯框架、服务注册中心、服务监控管理、服务追踪框架;
  4. 流式计算——实时日志发布订阅框架。

图片描述

图:搜狗商业广告平台基础架构图

总结下来,在基础架构构建方面应注意以下四个方面:

  1. 接口兼容性

    • 基础架构演化虽是一个长期行为,但最好尽早统一;
    • 接口兼容为一段时间内同类框架共存提供了基础。
  2. 控制风险

    • 尽量避免一刀切;
    • 双路和灰度方案;
    • 监控优先。
  3. 易用性

    • 提升开发效率,降低出错几率。
  4. 开源软件

    • 关注开源社区及主流开源组件;
    • 基于业务需求选择和优化开源组件,关注成本和收益。

饿了么创新产品研发部副总监 程军:饿了么的整体架构(PPT下载

饿了么创新产品研发部副总监 程军现场分享了饿了么的整体架构。2015年,饿了么相比去年实现了10倍的增长速度,日单280万,峰值约300单/秒,在这背后,饿了么的架构发生了怎样的变化?

从单机时代的NGINX-PHP、HAProxy负载均衡到SOA、Gateway、Service等各个方面,程军详解了饿了么架构的演进,以及所采取的技术方案,按领域拆分数据库,异步消息通知,在MySQL Proxy方面连接重用、限流、读写分离、分库分表,将前后台分离。最终,饿了么的架构进化如下:

图片描述

下午

图片描述

图:架构实践论坛现场座无虚席

小米网研发部负责人、架构师 张涛:小米网架构变迁实践(PPT下载

张涛详解小米网架构如何解决秒杀、拦截黄牛、库存等用户硬需问题。第一代小米网快速、简单、能用,包括官网、订单处理、仓储物流、售后等所有系统都共同一个Database,随着系统间调用的增多形成了网状结构,耦合也越来越严重,由此演变成星状结构,到调度层、业务层、数据层的三层结构。

技术和业务膨胀为小米网的架构构建带来了双重挑战,如何管理才能达到成本最优效率最高?小米网以“业务纵切,平台横切”采用Go、MCC、Nginx、PHP、LVS开发。其通用缓存采用Twemproxy+redis构建,速度快(单节点14万QPS)、可扩展(自动分片)、稳定,异步消息服务支持大量消息通信、分钟级消息投递、自定义消息索引和协议、允许无限消息堆积。同时,通过虚拟化技术降低成本,提高计算资源利用率,同时促使业务系统设计更具伸缩性。

途牛旅游网研发总监 高建:途牛网站无线架构的变迁(PPT下载

途牛旅游网研发总监 高建从服务化推进、南北京机房之痛、性能提升实践、App客户端技术演进四个方面详解了途牛网站无线架构的变迁。

以价格计算服务为例,四种架构对比如下:

  1. 同步——通过接口进行交互:其他系统通过调用接口通知价格中心发起运算,价格中心通过接口获取其他系统价格依赖的所有资源;
  2. 异步——通过MQ交互,价格中心通过依赖数据库获取其他系统的数据,将计算价格变成两段:先算资源成本价(一个资源多供应商),再算产品最低价;
  3. 并发——价库自身的数据(资源的成本价,产品团期起价)进行分库分表,根据产品的访问频度区分冷热数据的计算频率,三维(产品+团期,行程,资源);
  4. 分布式——计算过度依赖数据(检索数据量过大),变成内存数据库,使用Sharding MQ(本地访问,本地计算),Unix域通信(本地通信,提升通信效率)。

图片描述

图:途牛旅游App插件式开发框架

从最初的主项目包含所有模块,同属一个仓库,代码之间耦合性较高,无公共库的抽象,不利于多个团队协同开发,到不同插件属于不同团队的独立模块,并最终都集成到主工程中,途牛App客户端经历了插件式开发的演变,并引入阿里巴巴开源的AndFix框架,解决在线热补丁修复问题。

快的资深架构师 王小雪:快的打车架构实践(PPT下载

快的资深架构师 王小雪详细剖析了快的从2012年上线到今年与滴滴合并前后的架构实践与演变。从V1的作坊式研发、基本功能可用,V2对核心链路进行优化,确保业务主流程正常进行,到V3阶段的体系化架构改造,在业务量快速增长的背景下,快的建立了研发流程、代码规范、故障问责机制,执行严格的Code Review,梳理链路上的单点、性能瓶颈,建立服务降级机制,并进行小规模的迭代重构,对工程架构进行了分布式改造。

以RPC选型为例,在大规模服务化之前,应用可能通过RPC工具简单暴露和引用远程服务,通过配置服务的地址进行调用,然而只是简单的RPC还不够,除了网络通信和数据序列化,大型分布式RPC还应具备服务注册与发现、降级与容量管理、资源管理等其他要素。对此,基于实际应用场景,快的引入了开源的分布式RPC框架——Dubbo,并现场分享了快的使用Dubbo踩过的一些坑:

  • 链式调用的超时雪崩

client->A(timeout:3s),A->B(timeout:3s),A->C(timeout:3s)。B是非关键服务,C是关键服务。B不可用时,A傻等3s最终超时,业务不可用;B变慢,高峰时期A线程耗光,业务不可用。

  • 线程优先级隔离

Provider A提供了关键服务A1,非关键服务A2,高峰时A2耗时高导致线程池满,导致A1不能提供服务。

图片描述

图:Dubbo架构

  • 服务不停的上线下线

Provider内存使用不当导致频繁fullgc,触发了Zookeeper的超时被下线,Provider fullgc完成后又向zk注册自己,过一会又fullgc。

  • 服务无法注册

用zookeeper做注册中心,配置的注册中心地址只写ip和端口,没有配置注册中心协议,导致用默认的Dubbo协议。

  • forbid consumer异常

调用某服务时出现该异常,原因是该服务的所有实例都下线了。

  • Zookeeper输出大量的debug日志

配置的log4j不是debug级别,但应用大量出现debug日志,zookeeper 3.4.3的日志系统是slf4j,应用里还依赖聊logback。StaticLoggerBinder.getSingleton()加载了logback配置,默认是debug级别,log4j没有生效。

图片描述

图:快的实时数据中心架构

同时,快的对数据层进行了改造,以分库分表解决了前台应用的性能问题,以数据同步解决了多库多表归一的问题。但随着时间的推移,后台单库的问题越来越严重。为此,快的基于HBase和数据同步设计了实时数据中心,支持二级索引,并设计一个SQL解析模块,减少后台应用层的改动。

58赶集集团系统架构师、技术负责人 孙玄:58同城高性能移动PUSH推送平台架构演进之路(PPT下载

58赶集集团系统架构师、技术负责人 孙玄以“为什么需要移动PUSH推送”、“单平台、多平台、公司级统一高性能三个阶段架构如何设计优化”等系列问题,开启了《58同城高性能移动PUSH推送平台架构演进之路》的主题分享。移动环境下的弱网络问题、App消息无法触达让PUSH成为硬需,但iOS的平台特殊性不允许Service后台常驻,统一下发APSN(Apple Push Notification Service),而Android平台方案有着开源、自主研发、第三方推送等特性,综合考量下,58同城研发出以基于第三方PUSH推送平台、自主研发高性能Provider相结合的移动PUSH推送方案。

在经过单平台、多平台的演进,移动PUSH推送第三阶段架构和协议应如何设计和优化?孙玄以58同城的移动PUSH系统架构为例进行了深度讲解,包含分层架构体系、push entry/transfer、Android/iOS Provider等。

图片描述

图:58同城移动PUSH系统架构

那么,如何解决移动PUSH推送的性能问题?孙玄以Android Provider并发低为例,其原因是HTTPS线程不安全,采用每个HTTPS请求加锁,需对线上问题快速临时解决,然后对问题定位分析,找到最终解决方案,并借助libcurl HTTPS,降低锁粒度。

腾讯SNG增值产品部高级工程师、QQ会员AMS运营平台技术负责人 徐汉彬:QQ会员活动运营平台的架构设计演变(PPT下载

徐汉彬表示,活动运营存在上线周期短、个性化强、功能需求复杂、后端接口众多等特征,通过对不同业务活动模式的分析和抽象,绝大部分活动都可以一一组条件和动作的方式进行抽象和封装,进而形成通用的条件和动作活动组件,另外更重要的是通过平台化和框架驱动开发的方式,为通用活动组件的运行提供了高可靠、高性能,具备过载保护和水平扩展能力的框架支撑环境,活动组件只需要封装自身业务逻辑,核心功能框架自动支持,从而实现了高可靠高可用活动开发的彻底自动化。

但是,这是一个美丽的愿景,而实现这个目标就是最大的挑战。在此之下,AMS需要解决的问题就是高效活动开发模式、高可靠性和高可用性、保证活动运营业务的安全。AMS平台服务架构对外部提供不同维度的服务入口,TGW、手Q的SSO、内网通信等,AMS集群仍然属于同一入口。但做了物理隔离的集群部署,减少集群之间的相互影响。


更多详细内容参见官网网址:SDCC系列之数据库核心技术与应用&互联网应用架构实战峰会

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值