在高速上，yy 开着车，沉默，
路旁的灯连绵不断，一根一根
创业的路上，遇到的问题也如这路灯，一根一根，不到达终点，不会停止

晚上11点，到了公司，娃娃机过了不多久，也到了
兄弟们合力搬到 13 楼
插电，连上显示器，连上摄相头，一切就绪，就等调通 

”谁的江山，马蹄声狂乱，我一身的戎装，呼啸沧桑“——《菊花台》

梦想远不远？
不远！
你已在梦想中，怎么会远？ 

明月是什么颜色？
是黄色，如路灯一样的黄，一样明亮。
明月在那？
就在他的心，他的心就是明月。 

代码呢？ 代码就在他手！
那是怎样的代码？
他的代码如天涯般辽阔寂寞，如明月般皎洁忧郁，有时又彷佛是空的！ 空的？ 

空空蒙蒙，缥缈虚幻，彷佛根本不存在，又彷佛到处都在。
可是他的手看来并不快。
不快的手，什么能无敌于天下？   因为他的手已超越了速度的极限！ 

凌晨 3 点，13楼的灯光依旧亮着，和 yy 老师一起从广州拉回了三台机器的 Carson 正在用手机拍摄 Randy 老师操作娃娃机的视频
左，右，上，下……
运气不错，技术娴熟，娃娃成功的抓了出来 

阳台上
烟头的亮光
忽明忽暗 

夜已深，夜未眠
已经是早高峰，深南大道已经人来人往，车水马龙
伴随着座位旁边娃娃机吱吱的天车运行的声音，即构第一版网络娃娃机 Demo 正式上线了，正式宣告国内第一家提供完整的软硬一体网络娃娃机解决方案正式落地，虽然 yy 老师 对各种细节，时延速度还是不太满意，但是从Mark 奋斗 24 小时后依旧精光闪闪的眼中看到了一些满意的笑意。 

是谁在敲打我窗
是谁在撩动琴弦
那一段被遗忘的时光
渐渐地回升出我心坎

《被遗忘的时光》 － 蔡琴

也许若干年后，我们会回想这段全力拼搏的时光
也许功成酒醉，朦胧中想起这段艰苦的岁月
不管此后如何，就此役，我们是一支能拼，能打硬仗的队伍 

前路漫漫，不敢回头，一战之后，我们会再次起航，又会是新的征程
我们的目标是星辰大海

这里可以下到最新免费体验版：
iOS版本：https://www.pgyer.com/ZhuaWaWa-iOS

即构iOS娃娃机Demo

安卓版本：https://www.pgyer.com/ZhuaWaWa-Android

即构安卓娃娃机Demo

]]> https://www.phppan.com/2017/11/zego-wawaji/feed/ 0 https://www.phppan.com/2014/08/big-flow-activity/ https://www.phppan.com/2014/08/big-flow-activity/#comments Tue, 19 Aug 2014 01:44:30 +0000 http://www.phppan.com/?p=1918

大流量活动的应对

大流量活动的特性是生命周期短，推广资源集中，突增流量多，对系统负载有较大的挑战，可能会对现有业务产生冲击。 在有大流量活动上线之前我们一定要做好提前准备，提前预估容量，做好扩容准备，做好应急预案。

容量预估

在确认为大流量的活动上线前需要对活动做容量预估，预估总用户量有多少，用户同时参与的可能峰值是多少？确认后评估系统能力是否能够支撑，如果不能，进行优化或扩容。评估系统时需要考虑系统本身以及支撑系统的服务的承载量。

控制节奏

控制节奏是指控制资源投放量的节奏，要有层次的将资源投放出去，不要一次性将所有资源全部砸出去，以渐进的方式，慢慢放量。如果一次性将几千万甚至上亿的量放出去，可能会导致整个活动的后台支撑系统超负载，从而影响整体活动效果。

关注用户行为

评估时考量用户的行为，识别用户的页面访问路径，如常规的活动只有一个页面，可以直接按用户数评估访问量。 如果活动一个用户一次体验流程可能会访问4到5个页面，而每个页面对后端的cgi至少产生3个请求（2个pv上报，1个用户参与状态查询），则如果有500万用户进入页面，则可能会对后端产生至少2000多万的cgi请求。如果还有页面定制的用户状态区分等，则会有更多的请求到应用服务器。

服务定制

针对大规模推广活动进行定制。此定制相对于常规逻辑来说，去掉与当前活动不相关的旁支逻辑。毕竟相对于整个系统来说，需要考虑的逻辑点会比较全，而如果只是一个活动的话，有些功能是不需要用到的，可以针对这些点做功能优化。可以考虑从入口处直接隔离，或增加定制开关。

业务隔离

承载活动运营的系统现已成为平台性的产品，有较多的业务依赖于此系统，特别是有一些非活动性的，如体系类、固化入口类的业务。 此时，当有大流量活动发布推广时需要考虑到活动本身不会对平台上其它产品产生影响，毕竟大流量活动其访问量级较大，在大资源推广时会占用服务较多的的资源，从而可能会影响其它产品的服务质量。

为保证系统上其它业务的高可用性，我们需要做业务隔离。此处业务隔离的原则：

1. 代码保持一份，主干开发，保证主干的可用。
2. 短期和长期的业务隔离，如通过域名分割，大流量短期活动业务启用新域名，直接扩容，流量到新机器。

如果一切顺利还好，但是往往事不与人愿，总会出一些你预想不到的情况，比如之前说好的节奏没有把控好，比如做的容量预估不够，比如……，这些比如都是我们在事前需要考虑的风险点，当这些风险出现时，我们需要做异常应对了。

假设现在流量一下子太大，已经到了服务器的负载极限，有许多用户直接被服务器拒绝服务，此时我们能够做些什么呢？ 面对这种情况我们经常做的事情是扩容。

紧急扩容

扩容说白了就是加机器，其主要是考验系统的伸缩性，在不改变其它内容，仅通过增加或减少服务器的数量来扩大或缩小应用的服务处理能力。

由于业务的调用是链式的，一环扣一环，如当我们扩容后，能够应对这些流量冲击后，这个冲击可能就会触达到后端的server，或其它给我们提供服务的第三方服务，可能会一下子把第三方整得服务不可用，因此在紧急扩容前需要梳理我们依赖于哪些服务，大流量的请求中与这些服务相关的有哪些，大概有多少量级的请求会转发到这些服务上，他们的支撑能力有多少，整体容量预估是否够用，并且需要提前沟通。

假如因为某些特殊的原因，而无法扩容。此时为保证大部分用户的服务可用，我们可能需要选择服务降级。

服务降级

当应用访问遇到高峰时，超出了应用所能处理的最大能力时，为了保证整个应用的安全可用，需要进行降级，通过拒绝部分请求及关闭部分不重要的服务将系统负载降到一个安全的水平。

降级服务可以从功能和用户两个维度实现，功能降级需要将系统拆分成独立的若干个功能点，当遇到问题需要降级服务时，保证主功能的可用，一些旁支功能可以先关闭；用户降级需要在服务端实现某种策略的服务不可用，如直接抛弃用户请求。比较简单的实现就是各种系统开关，针对可以降级的功能点和服务使用开关， 当出现需要降级的情况的时候, 就可以在后台使用开关来降级。

服务降级前需要和产品侧沟通确认。

以上忝为某活动总结。

沉默一年，所做活动过百，所见所想，所思所虑。
活动常规化，小组年活动量1000+
人力不足，需求变更多，资源到位时间不定，

基础建设

• 活动运营，想要快速，就需要有一个强大的运营平台的支持。
  建设：运营平台作为基础建设，需要作为重点投入，在建设过程中，强化运营支撑系统 大系统小做，不停的迭代，专门的产品跟进，与使用者沟通，将系统的开发和活动的开发交替给不同的开发，以调节和深入。另，在人力方面需要确保运营系统的投入。
• 可扩展性：从运营支持平台的业务框架层面，在适应现有业务发展的基础上增加代码的通用性，在一定程度上保证系统的可扩展性。
• 监控告警：运营系统的告警不能成为常态，一是可能会形成告警疲劳，从而放过真正的问题，二是告警会影响日常的工作开展，此时如果确认常态的告警是问题，则解决问题，如果是告警系统本身的问题，则优化告警系统。

代码架构

• 前端静态页面，资源文件，活动隔离，按日期归档，CDN加速。
• 前端公用库版本升级，不同版本间清晰隔离，不做兼容，固化业务逻辑抽象为公用组件，实现业务的可配置化开发。
• 数据和页面分离，行为和表现分离，前端和后端分离，后端固化业务，中转接口。
• 轻重分离，将固化的业务以更高性能的服务实现，将变化较多的业务需求以脚本类CGI实现。

团队

• 固化业务外包，需要考虑人员的稳定性问题，这是一个矛盾点，并且外包政策需要切合公司的大的政策方向，存在风险点。
• 新业务主力人员承担，待固化后可以给新同学或相对较新的同学实现。
• 人员流动问题：做活动是比较重复的工作，在一般的团队，活动是给新人熟悉流程，熟悉业务的，而当做活动是常规工作，不做活动才是调节时，人才的选用育留是比较严峻的问题，留住一到两个核心人员，招聘合适的稳定的人，发展新的业务促进人员的成长。然而，人的问题往往是最根本的问题，也是最难解决的问题。人员的流动会成为一个一种常态，业务特性决定的，能减缓。
• 新人问题：新人进来，总会踩到各种各样的坑，不管是产品还是开发，如何规避？新人手册？新人FAQ？导师审核？通过流程？不管是哪种方式，最后成长并适应下来的都是需要经过时间的洗礼。
• 人员的分工：业务的模块化，从而引发人对这些模块的分工，人与模块对应上。比如接入新游戏，专人负责接入过程，负责接入后的文档撰写

需求管理

• 同时以产品的维度和开发的维度组织；
• 强跟进，变更的需求及时汇总；
• 关注需求中提到的资源，如重构，资源单，号码包等，这往往是风险所在；

流程

• 发布流程（活动发布过程检测，人工确认最终结果） 免测发布，版本发布，应用场景，开发自测，产品体验，外团体验
• 后台CGI大变更灰度发布，前端大变更以大版本发布
• 如何固化流程，如何确保上线的活动的正常可用，现在还在依赖于人工的检查和验证

以上是一年积累，有所感，有所想，无太多逻辑，且行且珍惜，只愿岁月静好。

产品驱动技术，改变的是kpi，
技术驱动产品，改变的是世界
这只是一个开发的遐想而已。
现实让我们知道疼！

2014年的第一天，带着包包大人，和家人一起爬山，登高而没有望远。
睡醒，起床，开始这篇该有的年度总结。

跨过一年，表示我离不二的年纪不远了，呵，回首一年，生活因包包大人的到来而发生了彻底的改变，技术没有明显的进步，进了想去的公司。
一年，有得有失，在选择中成长；
一年，有累有喜，在成长中成熟；
一年，有多有少，在变化中变化。

一、2013年的多与少

多了什么？
多了一个小天使
多了一份责任
多了一个完完整整的家，有你们的地方就是家
多了并不是多余，只是增加。

少了什么？
少了二人世界，世界将围绕小天使转
少了看书的时间
少了周末的爬山和运动
少了并不是真少了，只是转移，有更多需要你来兼顾。

多了什么？
多了能够见识的东西，更多的同事，更多的学习资料、更多的组件，更多的之前都没有见过的东西。
多了需要面对的用户，海量的用户，一个小小的手抖可能就是一大堆的投诉
多了需要考量的因素，所处的环境更复杂

少了什么？
少了责任，不再需要考虑他人的成长，关注更具体的事情。
少了思考，思考个人的成长？思考自己的价值，思考过去所做的事情，思考将来要做的？这些少了。慢慢就少了，无声无息的。
不在那个位置，你就不会去思考那个位置的问题，所谓 在其位谋其政，在其位的驱动力没有了，是否还能自动的去思考？
少了沉淀 一方面博客没有及时更新了，一方面看书的时间也减少了，每天围绕着需求在变。

一些个人感觉：
重回一线，开始了重新写代码的日子。
站的位置不同，看到的东西也不同，开发是最了解实现的人，也应该是最能发现bug的人，只是我们懒了，
如何去做？自测，严格的自测，除了正常流，遍历代码中所有的异常流，只是能有几人可以做到，因为我们都相信我们的代码是没有问题的。

更深刻的体会了业务决定实现，也决定了你对一个技术使用熟练程度。不经历一线的考验的技术不可能到一个很熟练的程度。

最重要的是什么？我们知道事分轻重缓急，重要紧急的事先做，只是往往我们认不清自己在做的是不是最重要的。
一个时间点上，你最重要的是什么？
一件事中，你最重要的是什么？
一些人里，你最重要的是谁？

2013年是一个变化年，生活状态的变化，因为变化，对比上一篇总结的计划：
1、过PMP【完成】
2、看5+管理 10+技术 10+其它书籍 【完成】只是效果不是太好，特别是临近这两三个月。
3、熟悉YII框架的源代码，对其各个模块有清晰的认识（貌似这里没量化了）【基本完成】最近在工作中也用得比较多
4、加强对Linux的认识（量化一些，虐APUE两遍，并结合PHP内核）【未完成】
5、完成媳妇的两个梦想【完成】
6、加强在工作上的掌控力，项目的按时完成率在80%以上。【需求变化】
7、Blog – 平均每月两篇+，【没有完成】博客没有及时更新，这就不找借口了，主要原因是个人没有积累，也没有去关注了。

二、2014年计划

1、博客 两周一篇 是为了沉淀，也是为了让自己思考，给自己留下思考的时间；
2、读书 与上面相关，虽然这是一种投入产出比不高的活动，但其精髓在于慢，数量为40；
3、技术 需要对linux有更深入的了解，APUE，linux内核，操作系统，系统架构；
4、运动 每两周至少大活动量的运动一次。
5、包包大人健康的长大
6、老婆大人的新年愿望

三、感恩

感谢老婆大人，是你辛苦将我们的宝贝包包大人带到这个世界，辛苦了！！
感谢两边的父母亲，你们养育了我们，为我们操碎了心，小宝宝出来了，你们还得操心，谢谢！
感谢在WS的朋友和同事，虽然离开了，但是你们曾经对我的帮助铭刻在心。
感谢兄弟的一路相随！
感谢er、reeze、张老板，terry，blank，感谢这一年在我生命中出现的人们，感恩。

四、结束语

2013还可回首望望，只是已经过去，现在还在我们手里，把握现在的你手里的，你身边的，相信未来会更美好。
2013~2014，很好的年份，1314，希望没有找到另一半早点成家，成了家的早点有小宝宝，一生一世。

五、附录A 2013读书列表