有干货--魅族技术沙龙第三期广州站参会总结

周六(2016、4、9)有幸在广州参加了魅族发起的技术沙龙,期间有100+人参加。可见,广州Iter也是求知若渴的啊,同时也说明广州,技术氛围可能没有北京和和深圳强,希望以后土豪们多举办一下类似活动。
 
文章内容并不完全涵盖了沙龙所有内容,只记录了印象深刻,或者之前没接触过的知识(记忆能力有限哈)。
 
总结的内容,不一定和演讲者表达完全一致(理解能力有限哈)。写下此文,为总结与分享知识。
 
这次线下沙龙总共分为4个部分:
 

《魅族云同步的实践与演进》-魅族高级架构师沈辉煌

 

《唯品会适变业务的架构洞察》-唯品会资深业务架构师官华

 

《九游平台技术演进》-微服务中心运维平台的产品负责人梁文刚

 

《魅族广告业务HTTP接口的灰度方案》- 魅族高级开发工程师吴浩清

 

一、《魅族云同步的实践与演进》-魅族高级架构师沈辉煌
 
关于云同步,最大的感触是,要做一些比较复杂的软件,要有一些基础理论规则支撑,例如,做之前,要定好数据同步协议。
(1)同步协议
1、同步数据格式演进: Json ---> 精简Json(变量名用1一个字母代表) ---->顺序Json(直接把变量名省了掉,变量按照顺序排列) + Gzip压缩
这个变动可能很小,但是对于1天PV亿级的应用来说,优化的总量也是很客观的,传输数据少了,一方面节省了用户流量,更重要的是节省了服务器带宽,为此,我不禁感叹,优化真是无止尽。
最终理论优化成果: 传统Json * 50% * 60% = 30%,这就是Money。
2、传输协议划分。因为手机同步的数据类型、同步方式使用不同的同步协议,例如数据类型有短信、网址收藏夹这样的小而多的数据,也有照片、视频这样比较大的文件;同步方式,有实时的小操作增量同步,也有换新手机,第一次初始化的全量同步。数据同步协议,需要解决的难题有可靠和安全数据传输、断点续传、数据同步冲突、减少服务器等待时间。而解决这些问题,业界有一个标准的
SyncML协议,魅族在此基础上,进行了实现、几种方式的应用和改进。
 
(2)架构设计
1、不同业务系统分为不同的Unit部署。同步大文件的服务器,消耗IO比较大,用户可接受的等待时间比较长;同步小文件,应该是快速,高速的,不同的同步业务,用户要求,服务器要求不一样,所以,按照不同业务功能划分服务器,对于服务用户、运维、调优、监控有很大的意义
2、全国多地部署,就近访问。多地部署,一方面是提高用户访问速度,另外一方面也有异地容灾的功能。为此,魅族自主研发了GSLB框架来实现这个功能
3、存储方面采用了传统RDB和HBase结合的解决方案。RDB,根据Userid水平拆分数据库,底层架构实现了数据访问自动路由,对于业务系统开发无感知
 
 
二、《唯品会适变业务的架构洞察》-唯品会资深业务架构师官华
关于业务架构分享,官华老师有20年的IT经验,曾经是知微的CTO,因此分享的内容比较宏观,侃侃而谈,洋洋洒洒几十页PPT,在有限的时间内,讲的很广泛,不是很深入,所讲的知识太多,我印象比较深,和管理问题和几个之前从未听说过的概念,零散总结如下:
(1)软件开发协作,管理上面失控问题。意思就是说,从管理上面来说,管理几个人、管理几十人、管理几百人,不单单有数量的区别,还有本质的区别。人多了,人员结构太扁平,会累死上面的人;如果人员结构层级太多,从上到下、从下到上沟通和执行也会有问题,容易累死下面的人。但是如何解决这个问题,没深入讨论
(2)系统重构和转型,必须小步快跑,稳定向前,一下子颠覆性的改变,通常会失败
(3)CQRS模式:命令与查询分离。具体问百度君货谷歌君
(4)微服务:把小的服务开发成单一应用的形式,每个应用运行在单一的进程中,并使用如HTTP这样子的轻量级的API。这些服务满足某需求,并使用自动化部署工具进行独立发布。这些服务可以使用不同的开发语言以及不同数据存储技术,并保持最低限制的集中式管理(网上摘录)。 字面上面的理解,就是尽量把应用变得更小,让应用之间相互影响变小。
 
 
三、《九游平台技术演进》-微服务中心运维平台的产品负责人梁文刚
听梁文刚大哥的演讲,感觉和题目结合得很好,把演进说的很清楚,收获颇多。
九游系统演进过程主要分为三个阶段:复杂庞大一套大系统-------->分布式系统------->服务治理(目前很多公司处于第二阶段,例如博主所在公司)
 
一套复杂的系统------>分布式系统,这个我都有所了解(不管你知不知道),就不赘述了,关键总结一下,第三阶段,服务治理这一块。
 
大伙都知道,分布式系统架构,各个系统之间,肯定要数据互通互联、功能共享,不管你是采用reful api\wcf还是其他调用方式,系统之前有数据流动,肯定会存在依赖。
用九游来举例子,200+个子系统,相互调用,形成网状结构,没有一个人能够完全说得清,各个系统之间相互调用逻辑!
我个人理解,服务治理,本质上就是要把这些复杂的关系管理起来。服务信息化、流程化,起到业务梳理、服务资源分配、服务质量管控、服务监控的作用。
服务治理后,你可以想象一下,这样的美好场景:
1、系统会有一张图,可以直观看到几百个系统,接口之间是怎么调用的
2、某个WebAPI接口受到攻击,或者有故障,你可以在系统上面点点鼠标,就可以把这个API停用掉
3、某个服务调用比较频繁,在系统点点鼠标,你就可以为这个服务分配更多系统资源
4、在系统中,可以直观看到,哪个接口有故障,失败率是多少、调用时长的多少
 
对于系统演进,个人最大的感触就是,系统进化,总是为了解决遇到的某个问题而变化的。
 
四、《魅族广告业务HTTP接口的灰度方案》- 魅族高级开发工程师吴浩清
关于灰度的话,记得之前在网上看过腾讯分享的灰度发布策略,跟这个有点类似。分享者浩清提及了很多实现的细节,收获也蛮多的。
实现的原理,主要是在系统调用总入口开发多了一个网关层。这个网关层,根据用户来源和灰度规则,把相应的调用请求分发到各个子系统,核心解决了不同版本的解决发布比例问题。
 
最后附上一张现场照片:
 
 
 
 
以上总结,如有某些知识侵犯到了相应公司权力,请及时联系删除。不过相信既然是开了分享沙龙,也是抱着开放的心态分享技术,促进IT行业的发展,所以我也大胆发出来了。
 
 
最后,感谢主办方之一 msup的大力支持,我们才有可能,才会机会聚在一起学习、探讨!
 
 
 
 
 
posted @ 2016-04-10 13:36 windwos7 阅读(...) 评论(...) 编辑 收藏
点击留言