首先很荣幸的被csdn邀请为sdcc2017深圳架构场的出品人参与此次topic。作为出品人，在演讲嘉宾的筛选上就已经动了脑筋。此次sdcc2017，演讲嘉宾的阵容是非常强大的，既有腾讯、阿里、百度传统3强的分享，又有唯品会、阅文集团、sina微博等公司的强势加入。各位演讲嘉宾也都是业界的“老司机”，不管是从技术还是演讲本身来说，都是“老”的可以啊！所以sdcc2017深圳架构场的技术topic水平当然不会低，是绝对值得期待的。
当出品人还有一个特权就是可以提前看到各位演讲嘉宾的PPT。此次架构topic的PPT在各位“老司机”动不动就“一言不合”加大马力“飙车”的情况下各个卓越超群，各显神通。这里我就先瞒过csdn的小编来报个料。
上午
首先登场是来自阿里的中间件架构师冯嘉，他为大家带来了来自阿里中间件团队自我研发的消息队列中间件“RocketMQ”。大家都知道阿里面临的访问、流量、正确性等一系列的压力；也明白在这些压力下程序员所要面对和承担的技术困境。RocketMQ在经过阿里内部多年的开发和使用后，顶住了压力（特别是“丧（疯）心（狂）病（数）狂（钱）”的双十一）。同时也因为出色的性能表现和卓越的稳定性，RocketMQ加入了Apache基金会。此次topic，冯嘉主要为大家带来了RocketMQ的什么呢？可以用下面几点来概括：
1. 首先是阿里使用RocketMQ的历程，从使用开源软件到自我研发RocketMQ的煎熬和解脱；
2. RocketMQ的实现。此次的topic可以说是毫无保留的全部拿出来了。包括mq的内部存储结构图都一清二楚的画出来贡献给大家看了，真是印证了那句话：是骡子是马拉出来溜溜；
3. 接着可能是大家最关心的RocketMQ具体的特性和性能。特性和性能可以让大家在选型和使用的时候更加的安心；
4. 最后是RocketMQ的监控与后续发展。这部分可以确保大家更加方便的使用RocketMQ；
紧接着登场的就是来自新浪微博的技术专家陈波，他为大家带来了“微博Feed的缓存架构及其演进之路”。微博的用户量亿级也是妥妥的、pv，并发更是不用讲了，大家心里都有数。所以他们在组织feed的确实也碰到了很大的困难和很多的现实问题。此次topic，陈波主要为大家带来了feed缓存的3个主要方面：
1. 首先是feed平台的总体架构，说明了feed在微博整体架构中所占的重要位置和实际碰到的问题；
2. 解决feed所使用的cached的架构极其实现；
3. 接下来是此次topic的亮点，对redis更好使用的案例。这部分应该会有很多人想一探究竟，毕竟redis几乎已经成为高性能网站的“威尔刚级” 产品了，现在还有谁敢说不用redis？
上午的最后一场topic来自于腾讯的架构平台部高级工程师陈杰，他为大家带来的是“基于空闲资源的弹性计算实践
”。弹性计算，虽然一直在说，但是对于目前的行情来说其实还算是一个比较新的领域，或者说是对普遍的大家一个比较陌生的领域。这是因为很多公司根本就没有这个精力也没有这个实力更是没有这个必要和动力去研究这个东西，但是它却是大企业或者说是云计算必须要面对的一个问题。如何更好的去利用空闲的机器已经是很多像腾讯、阿里等一样规模的大型互联网公司不得不也是必须要去面对和解决的一个问题。这次topic陈杰给大家主要从以下5个方面来讲解弹性计算：
1. 首先是弹性计算在企鹅内部的需求。从企鹅的实际需求出发，可以让各位清楚的知道什么情况下或者说什么状态下弹性计算是必要的；
2. 实现弹性计算的难点。这应该是业界的一个难题，可以看看企鹅是怎么去解决这个问题的；
3. “4步法”解决企鹅弹性计算在线业务的质量保障。你问我哪四步？我先卖个关子；
4. “3步法”解决企鹅弹性计算怎么使用好。又要问我哪三步？我是想说的，但是被csdn的小编给删除了！
5. 最后是企鹅弹性计算团队在实施弹性计算的过程中碰到的问题和其解决办法。这是企鹅弹性计算团队的知识结晶，大家不容错过啊！
大家可以先吃点饭，休息一下！下午更精彩哦！
下午
下午首先登场的是来自唯品会的架构师薛珂，他为大家带来了唯品会内部使用的“弹性调度平台Saturn的架构设计”。Saturn说白了就是一个Job系统，但是Saturn相比其它的Job系统有它独到的地方，而且也有更多的特性，主要的亮点在于以下4个方面：
1. job的无语言限制支持。可以支持目前常见的各种语言，甚至是shell脚本也可以无缝的运行；
2. 触发机制支持事件和时间。目前市面上更多的Job基本上都只支持时间触发机制，最复杂也就是用Cron表达式，所以Saturn支持事件是一个亮点；
3. 支持任务分片和根据机器负荷动态负载平衡。支持分片的Job很多，但是根据Job执行机器的系统运行指标来动态调整job执行的负载均衡是一个不错的想法和实现，也是Saturn的一大的亮点；
4.支持云部署。云是目前最火的一种架构模式，Saturn也不例外的支持了。从这点上也可以看出Saturn是走在技术架构时尚前沿的弄潮儿啊。
虽然这时候大家可能有点困了，但是千万不要瞌睡，错过了好戏我可不负责！
下面出场的是来自百度网页搜索部的资深研发工程师陶清乾，他为大家带来的是前端架构：“基于PWA的Web App前端架构探索与实践”。这是此次深圳架构场唯一一场前端架构topic的分享。他主要为大家从以下3个方面讲解百度在实际的工作中使用PWA架构移动Web App的经验：
1. 目前移动端web碰到的困境和百度所使用的解决方案；
2. PWA技术的价值与在百度使用过程中的效果。这部分大家应该可以从现在百度的部分app中就能感受出来吧？不过亲身听一下设计人员的讲解可能会更加的事半功倍！
3. 前端架构新思路。从离线化、视图框架、异步渲染和交换感4个方面来说明前端架构设计的新思路；
第三场来自于前卷皮网架构部技术总监陈秋余，他为大家带来的是“领域模型 + 内存计算 + 微服务的协奏曲：乾坤”。这场也是此次唯一一场分享目前比较流行的“微服务” 的技术topic。领域模型是一个架构中经常会碰到的问题，也是几乎目前的系统中主要的组成部分；内存计算大家也都耳熟能详；至于微服务嘛，最近火的不要不要的。那么这3个精兵强将组合在一起能碰撞出多少的火花呢？卷皮网给出的答案就是“乾坤”系统。这场topic将从4个方面对于“乾坤的火花”进行阐述：
1. 特卖类电商的微服务架构。这是很多传统电商都不会碰到的问题，偶有幸（也是不幸）碰到过。很早之前在5173任职，5173虽然不属于一个传统电商网站甚至都不属于特卖类网站，但是游戏交易，几乎有和特卖类电商有着一模一样的业务和架构痛点。其痛点就两个字：“比快”。不管是特卖还是抢购，其实比的就是一样：顾客“手快”的情况下网站不down机并且快速且正确的响应！
2. 目前主流分布式架构及其问题。这部分主要分析了特卖类网站和目前主流分布式网站架构的矛盾之处，笔者看过后满满的“惺（泪）惺（流）相（满）惜（面）”；
3. 解决高并发争抢的性能问题：无锁排队。这种解决方案现在越来越多的被提及。我们自己开发的很多中间件也都是使用了类似的解决方案来处理这个问题。到底怎么处理？还是来听听吧！说多了你就不买票了！（这不是偶的本意，csdn小编改的，你们可以去找他）
4. 分布式事务的一致性模型。其实大家从开始分布式架构系统开始就碰到了事务这个难题。虽然时间很长久，但是一直到现在为止，都没有一个统一的、标准的实现方案方法。基本上都是各家根据各家的实际业务模型和情况再结合2PC、3PC或者及其变种来实现解决。当然乾坤也不例外了；
最后一场是来自阅文集团。这里不得不多夸奖几句阅文集团。阅文集团这几年越来越多的参与各种技术开源和技术分享，阅文集团的技术也正在慢慢变的成熟。这里也希望阅文集团能够越来越多的帮助到各位在技术上碰到的问题。（哈哈！这个不得不说，是偶“不要脸”了。的确是“硬广”，纯粹不要脸的那种“铁硬广”）。PS：小编别删了啊，看在偶半夜写文档、也没有大尺度的上二维码的份上，留点面子。另:我们开源的二维码是…
言归正传，最后是来自阅文集团的架构师帅翔为大家带来的“PB级去内存化分布式缓存系统Lest的架构设计与实践”。对于帅翔偶还是比较了解的，因为天天被偶“虐”。Lest项目也是我们目前的重点项目，它主要的作用就是用来在生产环境替换掉目前阅文集团内容中心存在的大量主动缓存redis。对的，你没听错，我们准备下架一部分的redis。其实对于redis，大家也都心知肚明：随着redis的大量使用，基本上最后就是失去控制。病理表现：redis服务器或者redis内的缓存内存只加不减。那这是为啥呢？因为里面有点啥，有的时候你真的很难搞得清楚，哪怕你是一手做起来的，并且管理起来的，久而久之就这样了。这基本上也是现在很多公司共同碰到的难题之一。另外一个问题，也是一个很大的问题：redis是基于内存的，虽说现在内存白菜价，但是毕竟还是要成本。当你大量使用的时候，成本还是挺大；而且基于内存的一down或者重启，基本上就废了，有多少公司因为redis出了问题导致了站点down掉？所以用武侠来形容redis呢，我认为就是“离别钩”。不用吧不行，用吧闹不好自伤。那么我们解决这些问题的办法就是Lest！此次帅翔给大家从以下几个方面来讲述lest的前因后果：
1. 首先是Lest研发的原因和其总体架构。原因前面唠叨过了，这里说一下架构。相比redis，Lest增加了一层tracker来做一个统一的cached分配算法和存储的管理。这样的好处除了可以更好的管理cached内容，还能可以让业务系统和具体的分配算法隔离开，可以让业务系统更加的灵活；
2. 数据的存储。和上面阿里的RocketMQ一样，我们也是无所保留的贡献出来所有的设计思路和方案，包括具体的磁盘存储格式。其中Lest使用的二进制协议，来自于messagepack的“阅文DIY升级版hermas”更是亮点，它既可以用来做网络通讯，又可以满足磁盘存储，lest的成功实施很大程度上是hermas的功劳；
3. 数据的同步和性能测试。lest相比于redis就是“在尽可能少损失性能的基础上多了最后一致性和持久化”。众所周知，同步和持久化肯定会是性能的杀手，那么这部分就是讲述了lest用了什么技术和方案来去解决这个问题；
4. 最后是lest目前所存在优点与缺点。诚恳的分析lest的先进性和目前所存在的问题，以及以后可能的发展方向，为大家以后的选型扩展了思路。
总结
原本小编说只要1k字就够了，结果轻描淡写的就妥妥2k+了。这是因为参加此次技术topic分享的各位“老司机”飙车实在太厉害，偶也跟着“鸡血”了一把！对于这么多位高手云集的sdcc2017深圳架构场，你是不是已经手抖的都握不住鼠标拼命要去点击“购票”了呢？我们现场见吧！