周六（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行业的发展，所以我也大胆发出来了。