众所周知，游戏行业在当今的互联网行业中算是一棵常青树。在疫情之前的2019年，中国游戏市场营收规模约2884.8亿元，同比增长17.1%。2020年因为疫情，游戏行业更是突飞猛进。玩游戏本就是中国网民最普遍的娱乐方式之一，疫情期间更甚。据不完全统计，截止2019年，中国移动游戏用户规模约6.6亿人，占中国总网民规模8.47亿的77.92%，足以说明，游戏作为一种低门槛、低成本的娱乐手段，已成为大部分人生活中习以为常的一部分。

对于玩家而言，市面上的游戏数量多如牛毛，那么玩家如何能发现和认知到一款游戏，并且持续的玩下去恐怕是所有游戏厂商需要思考的问题。加之2018年游戏版号停发事件，游戏厂商更加珍惜每一个已获得版号的游戏产品，所以这也使得“深度打磨产品质量”和“提高运营精细程度”这两个游戏产业发展方向成为广大游戏厂商的发展思路，无论是新游戏还是老游戏都在努力落实这两点：

• 新游戏：以更充足的推广资源和更完整的游戏内容面向玩家。
• 老游戏：通过用户行为分析，投入更多的精力和成本，制作更优质的版本内容。

这里我们重点来看新游戏。一家游戏企业辛辛苦苦研发三年，等着新游戏发售时一飞冲天。那么问题来了，新游戏如何被广大玩家看到？先来看看游戏行业公司的分类：

• 游戏研发商：研发游戏的公司，生产和制作游戏内容。比如王者荣耀的所有英雄设计、游戏战斗场景、战斗逻辑等等，这些全部由游戏研发公司提供。

• 游戏发行商：游戏发行商的主要工作分三大块：市场工作、运营工作、客服工作。游戏发行商把控游戏命脉，市场工作核心是导入玩家，运营工作核心是将用户价值最大化、赚取更多利益。

  

• 游戏平台/渠道商：游戏平台和渠道商的核心目的就是曝光游戏，让尽量多的人能发现你的游戏。

随着互联网人口红利逐渐减弱，基于流量的增长已经放缓，互联网行业迫切需要找到一片足以承载自身持续增长的新蓝海。产业互联网正是这一宏大背景下的新趋势。我们看到互联网浪潮正在席卷传统行业，云计算、大数据、人工智能开始大规模融入到金融、制造、物流、零售、文娱、教育、医疗等行业的生产环节中，这种融合称为产业互联网。而在产业互联网中，有一块不可小觑的领域是SaaS领域，它是ToB赛道的中间力量。比如CRM、HRM、费控系统、财务系统、协同办公等等。

SaaS系统面临的挑战

在消费互联网时代，大家是搜我想要的东西，各个厂商在云计算、大数据、人工智能等技术基座之上建立流量最大化的服务与生态，基于海量内容分发与流量共享为逻辑构建系统。而到了产业互联网时代，供给关系发生了变化，大家是定制我想要的东西，需要从供给与需求两侧出发进行双向建设，这个时候系统的灵活性和扩展性面临着前所未有的挑战，尤其是ToB的SaaS领域。

尤其当下的经济环境，SaaS厂商要明白，不能再通过烧钱的方式，只关注在自己的用户数量上，而更多的要思考如何帮助客户降低成本、增加效率，所以需要将更多的精力放在自己产品的定制化能力上。

如何应对挑战

SaaS领域中的佼佼者Salesforce，将CRM的概念扩展到Marketing、Sales、Service，而这三块领域中只有Sales有专门的SaaS产品，其他两个领域都是各个ISV在不同行业的行业解决方案，靠的是什么？毋庸置疑，是Salesforce强大的aPaaS平台。ISV、内部实施、客户均可以在各自维度通过aPaaS平台构建自己行业、自己领域的SaaS系统，建立完整的生态。所以在我看来，现在的Salesforce已经由一家SaaS公司升华为一家aPaaS平台公司了。这种演进的过程也印证了消费互联网和产业互联网的转换逻辑以及后者的核心诉求。

然而不是所有SaaS公司都有财力和时间去孵化和打磨自己的aPaaS平台，但市场的变化、用户的诉求是实实在在存在的，若要生存，就要求变。这个变的核心就是能够让自己目前的SaaS系统变的灵活起来。相对建设困难的aPaaS平台，我们其实可以选择轻量且有效的Serverless方案来提升现有系统的灵活性和可扩展性，从而实现用户不同的定制需求。

Serverless工作流

在上一篇文章《资源成本双优化！看Serverless颠覆编程教育的创新实践》中，已经对Serverless的概念做过阐述了，并且也介绍了Serverless函数计算（FC）的概念和实践。这篇文章中介绍一下构建系统灵活性的核心要素服务编排，Serverless工作流。

Serverless 工作流（FnF）是一个用来协调多个分布式任务执行的全托管云服务。在 Serverless工作流中，可以用顺序、分支、并行等方式来编排分布式任务，Serverless工作流会按照设定好的步骤可靠地协调任务执行，跟踪每个任务的状态转换，并在必要时执行您定义的重试逻辑，以确保工作流顺利完成。Serverless工作流通过提供日志记录和审计来监视工作流的执行，可以轻松地诊断和调试应用。

说起Serverless这个词，我想大家应该都不陌生，那么Serverless这个词到底是什么意思？Serverless到底能解决什么问题？可能很多朋友还没有深刻的体会和体感。这篇文章我就和大家一起聊聊Serverless。

什么是Serverless

我们先将Serverless这个词拆开来看。Server，大家都知道是服务器的意思，说明Serverless解决的问题范围在服务端。Less，大家肯定也知道它的意思是较少的。那么Serverless连起来，再稍加修饰，那就是较少的关心服务器的意思。

Serverfull时代

我们都知道，在研发侧都会有研发人员和运维人员两个角色，要开发一个新系统的时候，研发人员根据产品经理的PRD开始写代码开发功能，当功能开发、测试完之后，要发布到服务器。这个时候开始由运维人员规划服务器规格、服务器数量、每个服务部署的节点数量、服务器的扩缩容策略和机制、发布服务过程、服务优雅上下线机制等等。这种模式是研发和运维隔离，服务端运维都由专门的运维人员处理，而且很多时候是靠纯人力处理，也就是Serverfull时代。

DevOps时代

互联网公司里最辛苦的是谁？我相信大多数都是运维同学。白天做各种网络规划、环境规划、数据库规划等等，晚上熬夜发布新版本，做上线保障，而且很多事情是重复性的工作。然后慢慢就有了赋能研发这样的声音，运维同学帮助研发同学做一套运维控制台，可以让研发同学在运维控制台上自行发布服务、查看日志、查询数据。这样一来，运维同学主要维护这套运维控制台系统，并且不断完善功能，轻松了不少。这就是研发兼运维的DevOps时代。

Serverless时代

渐渐的，研发同学和运维同学的关注点都在运维控制台了，运维控制台的功能越来越强大，比如根据运维侧的需求增加了自动弹性扩缩、性能监控的功能，根据研发侧的需求增加了自动化发布的流水线功能。因为有了这套系统，代码质量检测、单元测试、打包编译、部署、集成测试、灰度发布、弹性扩缩、性能监控、应用防护这一系列服务端的工作基本上不需要人工参与处理了。这就是NoOps，Serverless时代。

最后这一章节总结Kafka中需要特别关注的重要配置以及影响Kafka性能的因素。

重要配置

• auto.create.topics.enable：该配置项默认值是true，但在生产环境最好设置为false。这样可以控制创建Topic的人以及创建时间。
• background.threads：该配置项默认值是10，既整个Kafka在执行各种任务时会启动的线程数。如果你的CPU很强劲，那么可以将线程数设大一点。
• delete.topic.enable：该配置项默认值是false，可以根据实际需求改变，在生产环境还是建议保持默认值，这样至少不会出现Topic被误删的情况。
• log.flush.interval.messages：该配置项最好保持默认值，把这个任务交给操作系统的文件系统去处理。
• log.retention.hours：日志文件保留的时间默认是168小时，既7天。这个配置可以根据具体业务需求而定。
• message.max.bytes：每条Message或一批次Message的大小默认是1MB。这个配置也要根据具体需求而定，比如带宽的情况。
• min.insync.replicas：该配置项的默认值是1，既在acks=all时，最少得有一个Replica进行确认回执。建议在生产环境配置为2，保证数据的完整性。
• num.io.threads：处理I/O操作的线程数，默认是8个线程。如果觉得在这个环节达到了瓶颈，那么可以适当调整该参数。
• num.network.threads：处理网络请求和响应的线程数，默认是3个线程。如果觉得在这个环节达到了瓶颈，那么可以适当调整该参数。
• num.recovery.threads.per.data.dir：每个数据目录启用几个线程来处理，这里的线程数和数据目录数是乘积关系，并且只在Broker启动或关闭时使用。默认值是1，根据实际情况配置数据目录数，从而判断该配置项应该如何设置。
• num.replica.fetchers：该配置项影响Replicas同步数据的速度，默认值是1，如果发现Replicas同步延迟较大，可以提升该配置项。
• offsets.retention.minutes：Offset保留的时间，默认值是1440，既24小时。在生产环境建议将该配置项设大一点，比如设置为1个月，保证消费数据的完整性。
• unclean.leader.election.enable：该配置项的作用是，指定是否可以将非ISR的Replicas选举为Leader，默认值为false。在生产环境建议保持默认值，防止数据丢失。
• zookeeper.session.timeout.ms：Zookeeper会话超时时间，默认值为6000。按实际情况而定，通常情况下保持60秒即可。
• default.replication.factor：默认Replication Factor为1，建议设置为2或者3，以保证数据完整性和整个集群的健壮性。
• num.partitions：Topic默认的Partition数，默认是1，建议设置为3或者6，以保证数据完整性和整个集群的健壮性。

这一节主要介绍Zookeeper和Kafka的UI管理工具。

ZKUI

ZKUI是一款简洁易用的Zookeeper信息管理工具。首先从Github上克隆工程到本地，这是一个Maven工程，然后mvn clean install，在target目录下打出两个jar包zkui-2.0-SNAPSHOT.jar和zkui-2.0-SNAPSHOT-jar-with-dependencies.jar，将其上传至你的阿里云ECS。因为我们Zookeeper是集群模式，所以首先需要修改config.cfg中的Zookeeper地址：

#Comma seperated list of all the zookeeper servers
zkServer=zookeeper.server.1:2181,zookeeper.server.2:2181,zookeeper.server.3:2181

然后运行如下命令：

nohup java -jar zkui-2.0-SNAPSHOT-jar-with-dependencies.jar &