|
|
好像很久很久没有发布过微信公众号文章了。
最近一段时间沉迷于抖音，从娱乐的角度来说，抖音对微信公众号当然是碾压级别的。
但是抖音确实没有办法写出很长的文章，要正式地说点干货，还是要微信公众号。
==================================
趁着最近时间不是很紧张，想稍微对过去两年多的工作，做一点小小的总结。
首先我们还是谈谈技术方面吧。
我们游戏曾经差一点达到百万DAU的水准，这个成为我吹牛逼的一个新的谈资，对我自己的信心来说，也是一个很大的强心剂。
==================================
一
承载量和吞吐量
先谈谈我认为扩容（承载量）和提高吞吐量的关键原则：
1 分布式
这个已经是常规套路，不多说。主要体现在两点：
1）横向扩容，特别是横向扩容的可配置化。
对于紧缺资源（比如cpu、带宽甚至包括db）的横向扩容。
目前我们做到的是网关connector、逻辑logicserver，基本可以无限横向扩容。本质上db也可以做到这一点，但是需要通过更加严格的划分机制。
可配置化则是希望扩容的方式或者说流程变得简单，简单就意味着效率和不容易出错。
2）微服务。
我不知道微服务的说法是不是合理。也许只是利用了一些微服务的理念。
在我粗浅的认识中，微服务的核心思想其实就是解耦。只不过我们一般说的解耦，是代码层面，而微服务把解耦思想上升到了系统框架的级别。
具体来说，在人力可以承担的情况下，尽可能把功能完全的独立出来。完全独立的意思是，进程或者进程群级别的独立。
比如战斗服（群）的独立，匹配服的独立，聊天服的独立，社交服的独立。这些是我们做了的。另外还有一些服务我们没做，依旧集成在logic之中，但事实上是可以进一步解耦独立，或者微服务化的。比如：登录、登录验证，等等。
当然，是否必要也可以看具体情况具体决定。
微服务的做法是相当好的，他有点像把一些工作独立封装成了库——而且比库更进一步，成为了一个小的战斗单元。这样不但保证了独立，灵活，容易调整，还可以很轻易地分布式。
2 队列，缓存和负载均衡。
云风曾经提到过，提高负载能力和吞吐能力的原则其实非常简单。就是队列，缓存和负载均衡。
队列、缓存和负载均衡，本质上其实就是时间尺度的平滑。
我们之前提到了分布式，提到了横向扩容和微服务。那么具体到某一个具体的系统内部，我们如何进行优化呢？
很好的方式就是队列，缓存和负载均衡。
比较传统的队列，比如排队登录系统，不多说了。
数据库方面可以稍微说一说。
我们做负载优化，首先就是分析系统的瓶颈在哪里。而数据库（或者说数据落地），往往是其中重要的一环。我们落地的系统。使用了内存-redis-mysql（冷热库）的多级缓存落地机制。任何数据，都是先落到了redis之中，就算完成存储，立刻返回，通知上层系统。而这些redis中的数据何时以何种方式，何种速度，从redis缓缓落入mysql，则可以看负载的情况，缓缓执行。
原因当然是因为redis作为内存非关系型数据库，速度是mysql的1000倍以上。
那么，再进一步，落地到mysql如何进一步优化呢？方法也很类似，原则也很简单。我们使用多种不同优先级的队列。
在落地时，我们可以通过参数的优化，来调整，来决策每个循环选择哪些种类的任务，以及每种任务以多少数量（比例），进行落地。
当然了，这里要对具体的落地业务进行权重的评估。
系统有很多，具体细节，这里不做赘述，只谈大体上的原则和思路。
原则和思路，还是比较简单的。
==================================
二
提高稳定性和安全性。
除了扩容和提高吞吐量，还有一些别的值得说道说道的东西。
比如：如何提高稳定性和安全性。
1 首先是架构要足够的健康。
微服务的理念要从上贯彻到下。
从整体框架系统，到具体某个进程内部的不同系统，再到类的设计。
要充分的做到对修改封闭，对扩展开放。
代码风格要足够的干净，逻辑要足够傻瓜并且简练。耦合度要足够低，独立性要足够强。
这些都是基本细节。
2 严密的技术数据监控平台和测试
现在很流行一种说法——基于数据驱动开发。
也就是利用数据分析和数据挖掘，来反向指导研发和优化的方向。
尤其是运营向的优化。
但是仅仅对技术特别是服务器本身的稳定和安全来说，也是一样的道理。
我最近两年多的工作，除了对承载量和吞吐量的优化之外，比较需要记一下一笔的是，我们开发了一个技术向的后台。
这个后台会收集整个系统以及服务器群数十个进程的各项健康指标。
这个后台建立之后，每开发一个重要系统，都需要做两个配套的东西：
1）对应的测试模块。
2）后台统计数据。
就我所知，大部分游戏公司（甚至是几乎所有的游戏公司）其实开发还是相对比较粗放的。
首先，并没有特别多的代码级别的测试。大部分游戏公司的测试，指的是测试人员的人肉测试，而并不是用代码写测试用例进行测试。
其次，大部分游戏公司其实对各个系统各个模块并没有实时的后台统计。很多公司的bug处理还依旧停留在人肉分析日志的时代。
当然了，我常年在中小型公司工作，所以对大公司最近几年的技术发展情况不是很了解。也许是我自己孤陋寡闻，但是就我自己知道的情况，就算是大公司或者当前特别红的一些新兴公司也并没有做的特别好。
这里可能有一个原因是游戏本身多少还是一个文化娱乐产业，所以技术的积累和迭代，就算有，也并没有形成一个长期经营的线。更不要说，国内的所有公司其实都很少有中台的概念。
有些公司，比如游族，听说了supercell的中台策略之后，似乎也进行过推动。不过要能够让其他项目组或者说工作室享用到中台的好处，就难说了。
所以绝大部分游戏公司的各个项目组，大概都是各自搞各自的。很多问题也是出了问题，项目组自己再来一遍，自己解决。
（我提到这个是因为，有时候技术的积累和共享，才能加速进步）
扯远了。回到技术向的数据后台。最早我们做这个东西，其实是源自于当时在查一个很奇怪的内存泄漏的问题——当用户量级大到一定程度的时候，就会出现缓缓的内存泄漏。
最后发现是因为副本的释放问题。但是从log来看，释放的接口已经调用了。那么内存究竟为何泄漏呢？
一头雾水。
我们唯一能做的，就是收集尽量多的在线信息——类似于给病人把脉，在线把脉。
我相信很多大公司，一定有这样的技术向在线监控平台。但是游戏公司这么做的恐怕并不多。
这个系统最终呈现出来的界面是一个网页，有点类似于运营后台——就是运营人员查询用户事件的那个后台。
运营后台检索数据库日志。而技术监控后台则是收集当前进程的在线数据。
有了这个在线实时数据监控甚至是曲线图之后，我们对服务器的状态，就能做到知己知彼了。
从此之后，有任何问题，都可以迅速定位，甚至可以说在问题发生之前，就可以提前通过后台得到预警。
凡事预则立。
一切尽在掌握的感觉。
另外我还曾经试图开发一个在线track工具，就是说可以通过这个工具，对在线的一些数据，以及对错误（或者说bug）进行一些自动的分析，做到一些自动化的处理。这个有点类似于断点调试的一些堆栈信息之类的，只是简单地希望他在线化，自动化。
但是这个事情后来并没有进一步推进。
==================================
三
知无不言言无不尽。
技术向的内容，到此基本可以结束了。不过关于管理，我也想多扯两句。
其实主程无非就是对上负责，对下分解任务和驱动。
关于利益分配，这是公司层面的事情，不是我能说的。
我想说一点的是，主程有可能可以做到的事情是，如果有可造之材，那么尽心尽意的培养，是能够凝聚人心的重点。
知无不言言无不尽。
长久看来，真心诚意地对一个人好，对方是一定能感知到的。只要他本人是个可造之材，那么他一定会非常好地配合你的工作。
事实上，这个世界上大部分人都是可造之材，而且大部分人也都会知恩图报。
最差最差，大家也会成为好朋友，何乐而不为呢？
=========
|
|
发表于 2020-10-29 18:08:11