技术中台从2020年3月2日开始，到今天2021年9月26日已经一年半左右的时间，整个过程有很多的调整，流程的梳理，难题解决等。分享一下

一：技术中台规划

首先建立技术中台肯定是需要有一个规划的，没有规划的事情是不可能做好的。前一到二周的主要时间就是在分析技术中台可以做的事情。

后来参考了莉莉丝的聊天系统，发现聊天系统是一个比较独立而且又比较通用并且还做不好容易出问题的系统，而也考虑到以后可能需要各种不同的引擎来接入。所以我们打算做原生ios和android开发的聊天系统，参考的对象是莉莉丝。

二：内容梳理

要做这个系统首先要参考他们的聊天系统的结构，比如设计以及他们的通用方式，包括拆包，实机上手操作感受，把他梳理成了一个可以细化开发的文档。

三：人员招聘

接下来要看的是，既然我们要长期做中台的事情，以及有了一个目标。我们就需要人员来做，然后接下来就是规划需要的人员，比如ios开发，android开发，unity开发，服务器开发，策划兼pm，测试。

这一套人员也是后面不断的遇到问题解决问题而建立出比较稳定输出内容的团队。

3.1

其中像程序相关的人员前期肯定是只有一个的，甚至前期我们只有ios开发和服务器开发来验证这个系统究竟能不能做好，有没什么坑。然后确定没问题了我们也招来了android一起开发。

3.2

前期验证系统的时候基本就这三个具体的开发在，但系统开发完成准备对接游戏时，我们发现如果没有pm兼策划，我们的系统问题以及项目工期都很难去梳理，因为前期是我在梳理，而由于分部要做的内容不是只有这个，所以就需要一个pm兼策划来对系统的需求挖掘以及项目工期的把控。

3.3

接着我们系统对接项目后，如果我们还是各只有一个开发人员，项目赶一下是能做完，但是不够牢固，因为我们要思考是否有可能有员工离职的那天以及我们的梯队建设。那么自然我们需要各招一个开发，让ios和android以及服务器都有一个梯队以及人员流失风险降低。

3.4

然后我们发现如果没有unity开发人员来整合系统，那么对其他unity的项目接入是需要一些成本的，为了降低成本以及为了更好的整合sdk，我们选择了一位unity开发兼做这一个整合的工作。这里顺带说一下，ios和android的系统开发还是有一定的差异的，所以接口上如果不沟通可能ios和android的交互方式会天差地别，所以前期一定一定一定要和ios及android确定对外的接口。这种统一对项目也好，对sdk的维护也好都是极有好处的。

3.5

我们上线了一个版本到游戏后，其实有发现我们的质量有时还是不太有保障，策划在这块并不能起到测试的作用。然后我们招入了一个测试形成了一个开发的闭环。当然测试除了做功能测试外，还需要做自动构建工具方便（ios，android，unity）出包。以及性能测试等。

3.6

然后我们为了减少项目组的问题，也梳理出了一套比较能控制质量的流程：

以及我们还需要梳理开发测试流程，也就是我们在测试阶段的解bug以及测试bug的节奏：

当然还有很多细节，比如多语言，适配，系统的纵向版本和横向版本的区别等等。

四：开发闭环

然后闭环就产生了。

五：闭环调整

5.1、

这里其实要提醒一个服务器开发这块，理想的对接当然是一个方向的对接，也就是一个出入口，比如游戏就调用客户端sdk的接口来确定所有事情。但是这个只是理想状态，因为游戏中有很多数据是不希望暴露给外面的，而且如果是通过客户端直接做，每次可能都要初始化非常多的数据（比如角色信息等）

所以我们服务器也做成了一个sdk，供给游戏服务器对接，这样可以通过服务器同步数据给到我们中台的服务器，那么我们中台的客户端只需要跟我们中台服务器对接就可以了，也减少了很多接口。这里主要要做的是同步问题，也就是信息需要同步给中台。

5.2、

可能关注到游戏和中台还有一条线写着“需求落地”，这里的意思是如果我们只靠自己的想法来做，其实不一定好落地，因为游戏的具体想法跟我们的想法结合才是一个真实的需求，这种结合才是落地比较容易的方案。所以这里需要有一块的流程。

六：登陆支付相关sdk

后来我们需要把公司以前的海外及国内的登陆支付相关sdk也接过来做，一开始我们拿过来发现ios和android的对接接口完全不一样，unity在ios和android上要做两套不一样的流程来支持，整体非常繁琐，不利于维护。

我们选择了重构，重构有两个方向，一个是让登陆支付相关的所有sdk都可以单独打包和整体打包两种选择，二是核对所有接口，改成ios和android都统一的接口，三是unity做一层封装，做成unitypackage，其他项目只需要对接unity相关接口即可（不是unity引擎的暂时需要自己对接，其实工作量也不大）。

接下里也是为了能迭代版本以及不会对老项目的sdk的影响，我们也梳理了版本管理方式。

七：文档整理以及中台网站：

7.1、

我们有了sdk，但是不能让各个项目都通过询问接口或者询问有什么功能来支撑，不然项目多了，我们就根本忙不过来了，所以我们需要梳理出接入文档以及介绍，让需要的人直接来查看文档即可。

7.2、

光有文档其实还不足够，因为这样我们很难让项目知道我们中台有什么能力以及有什么更新了，所以我们做了一个中台网站，用来整合我们的能力展示以及api文档。还有就是技术分享相关。

八：复盘：

我们复盘包括个人复盘，团队复盘以及项目复盘。

8.1、

个人复盘更多还是出现问题下立即跟相关人员讨论问题，让他们知道问题的危害，及时改正。

8.2、

团队复盘就是我们会在每个迭代结束后就要开一次团队复盘会，把我们出现的问题都列出来一条一条解决，其实上面说了很多问题都是通过复盘形成一个更稳固的流程来做到的。

8.3、

项目复盘，这个更多是跟项目组一起讨论的，如果是有更好的做法或者遇到问题我们都及时开会讨论这个问题的解决思路。

九：新系统：

我们在做系统的维护以及开发的时候策划就需要去挖新系统了，这些新系统是需要比较独立而且经常出现以及比较容易出问题的。这些系统才是真的做中台sdk的意义，如果简单的或者不常用的或者不独立的，项目组其实会选择自己做。

以及平时我们开发的时候要主动积累组件或者功能，比如寻路的，物理的，渲染的，这样形成一些组件化的产品，也能更快更好的赋能项目。

十：一些细节

之前遇到了一些问题以及解决方案，梳理一下。

1.开发客户端和服务器，防止与项目耦合，接口抽象化，写对接文档流程和sdk的api。

2.确定测试服务器和正式服务器，并确定是集群还是单服，cdn相关的申请，确定价格。

3.确定线上bug的修复方式和流程。热更方案。

上线前准备：

1.与项目组确定接入方式，服务器sdk和客户端sdk确定，并且确定api。

2.确定bug修复方式和流程，确定热更方式和流程。

3.服务器申请，服务器配置确定（几台服务器，什么配置，还需要加速线路，加速是公司统一出钱）

4.翻译文本确定（google翻译需要跟公司确定成本，如果超过字数就限制不让翻译）

5.cdn申请并确定价格（尽量沿用项目组的方式），费用按流量计算，不够了再加，以最低的标准先做。而且要记得做oss相关的资源清除的逻辑，以免不断撑大

6.如果是已经上线的产品要数据迁移

7.浏览公司项目上线要求

8.版本管理方式，比如定义0.0.1版本

9.图片得上传要审核或监控，不能有黄图，要有举报功能，要有入口控制开关

10.外国网络比较复杂，网络可能会慢，所以客户端需要轮询三个地址，拿到速度最快的地址。

11.内存占用问题，不能影响到游戏本身的内存崩溃。

12.服务器和客户端的接入说明以及更方便的接入方式

13.硬盘占用大小

14.接口不统一，应该再unitypackage这层控制统一接口

15.我们的决策和做法应该要梳理流程，内部讨论完决策方案再找外部再讨论来确定方案。

16.应该我们这边先要尝试对接，看看有没什么问题

17.要告诉原生开发meta相关要传，unity的每个部分是什么东西，相当于一个指导

18.清除缓存

19.bug应该内部先过一遍再给测试，并且我们要拿到测试用例。然后每次开发前都要和项目组确定做法，不然会有修改。

20.上线前需要保证代码稳定，有大修改需要集体过一下

21.整体开发和测试流程需要确定下来

22.服务器弄开发环境，测试环境，预发布环境，发布环境

23.要有网站让其他项目知道我们有什么

24.oss要定义好容量

25.最后要确定所有都是正式环境下的内容

26.需要严格自测后再给包给对方

27.需求要多方对齐，比如开发和策划与第三方全方位对齐

28.测试流程要修改：先验收sdk功能模块--->sdk功能模块完成验收--->与其他系统交叉测试-->完成验收。测试用例要给到开发确定。

29.要做好热更的计划

30.还要考虑体验的问题，输出的环节要加上体验环节

中台两个方向：

1.组件化各种能力，然后放网站上供公司参考

2.挖掘更多公司类似游戏的玩法，参考各种公司的类似游戏，然后与项目组沟通确定落地方案。

十一：中台的意义

中台存在的意义是为了让公司的项目能够更专注开发核心功能，加快开发进度以及赋能技术。如果我们做不到赋能项目反而是影响项目进度，那么中台的存在意义是不强的。