Kotlin + Spring Boot

前面有人说 PHP 一个接口光写十分钟吧

自己平时做的 CRUD 接口，一个系列增删改查一般总共十分钟不到吧。
Flyway 定义数据库表结构
定义参数结构，通过注解做参数校验（一堆 PHP 不做这个事，有但是不多）
定义个
写 Controler ，写 Service ，MyBatis Plus 一把梭。
对了，带上 Spring Doc 注解，完事后，直接生成文档页面，还可以文档页面直接测试接口。

中间会有些手误啥的错误，强大的类型，包括 MP 都是泛型关联数据库字段，大部分错误编译期就能看的非常清楚。
参考老代码也是一目了然，类型是最权威的注释，也是最权威的代码脉络总纲。

带上测试，15-30 分钟差不多全部搞完吧。

PHP 搞数据库，绝大部分字符串拼接一把梭，搞出问题来了在哪里 Debug 个半天，看着让人想笑，一堆说自己快的人搞出有注入风险的代码。

有些搞法所谓的快，是不是真的比人快先不说，出来的东西，我是懒得维护的，后期找起来就是天书。

对了，后面部分接口想做改造，加个缓存，加个读写分离啥的，你们猜要多久，要改动多少？

Kotlin 语法既强大，又简洁，还简单。建议去试试。

一般按分成合作的渠道方，会要求产品方接入指定的支付通道，也就是所有的流水是先进入到渠道方户，然后按期按比例结算给产品方。这样的话，充值数据双方都是很清晰的。
至于切支付这种骚操作，各家反正都有防。App Store Google Play 这种就是审核+下架+封账号教做人。至于国内的小米华为这种啥的，和前面 2 种有本质区别，这种渠道都是严格的指定量，上这种渠道很不划算，即使有自然量也是产品方的品牌效应。我的理解就是，上这种渠道一般都是因为渠道会保证提供一定的量。如果被发现后期切支付，渠道方只需终止合作不再提供量就行了。
重点产品合作方一般都会定期复查一下的。
个人认为，有流量合作的，不要切支付，坏口碑，以后难找合作。
Google Play App Store 这种，切支付必然夹带马甲包，操作成本也很高，省下来的 28% 左右的利润能否支撑这个操作成本需要自己衡量。
以上有一个例外，就是国内付费游戏，又无版号，这种如果非要违法上，只能切了。

跳板机上没 nc 的话，可以直接先在跳板机上开个隧道
ssh -Nfg -L 3306:127.0.0.1:3306 目标机
然后在本机上执行
ssh -Nfg -L 3306:127.0.0.1:3306 跳板机
这样访问本机的 3306 会先通过隧道到跳板机的 3306 然后再通过隧道至目标机的 3306

C++ 的服务端吗？说个非 C++ 的方式，填业务逻辑的地方是框架预留的地方，都做了异常的检测。服务挂掉的时候框架会提供指定的异常回调处理。一般情况下在这里记录日志加回写数据。半年的研发周期本身就应该让宕机的概率变的很低。挂掉还有机会回写将数据丢失的可能性进一步降低（当然，要保证回调里面不再或几乎不会出现异常）。
但是，这样还是不能解决数据一致性问题，比如修改数据一半挂掉。这种情况下回写的数据是不完整的。这种只能通过业务逻辑中的日志来记录。非极端情况下是能将玩家数据恢复到之前一致的。
以前特别纠结这种问题，总想为什么没有既能完全保证数据一致性，性能又好，心智包袱又小的方案，让写业务逻辑的时候无脑一点。现在想想真的太难，老老实实做好日志记录，关键数据一致性问题能通过日志追踪复原到比较理想的状态也差不多了。

就是 mysql 这种，ACID 不开串行异常级别，一致性也不能支撑完全的无脑的开发。
比如扣减余额，转账这种。默认可重复读级别并不能解决并发的问题。只要允许 2 个事务一起操作该数据，一样余额能成负。最终还是需要额外处理。

接过大量 SDK，也开发过一些。建议所谓测试模式正式模式，都做到生成环境中去。

正规一点的 SDK 常见的做法是：为客户分配参数，然后客户的应用默认是 Test mode.

客户正常接入（接入过程中会有很多垃圾数据脏数据），等到正式接入完成，你们再后台验收，查看关键接口调用与数据是否正常，验收正常，将 Test mode 修改为正式模式。


容易出错的地方，不要吝啬，多打日志，客户多了，什么样的程序员你都会见到的。

开发者账号有区域之分吗？结算不都是走美元吗？个人的话，提供双币信用卡就行了啊。

直接申请开发者账号。开发者区域和应用发布区域没啥关系啊。
无论怎么申请的开发者，都可以发布全球区吧，只要符合当地规定就行。比如如果发布时要选大陆，付费游戏就需要提供版号。

@gantleman
还有，你说 [普通程序员用演员模型加数据库写的缓存服务不可能比 redis 更快]
当然，特指场景服务，多少人同屏本身服务端压力就是场景服务
场景服务一般做法是，状态直接在内存中，这个内存是 Actor 的 state，Actor 可以是一个完整的小场景，亦可以是一个大场景的一个区域，根据实际情况划分。
该区域类的玩家操作直接在该 Actor 中处理，状态就在这个 Actor 内存中，而且就是原生的数据结构。各种技能的计算就像在客户端写顺序代码一样，数据会有策略落地，但是逻辑都是在内存中完成，只有加载场景才有读的动作。

并不是你想的那种 CURD，一个请求过来从数据库或者其他缓存中拿一堆丢失了结构的数据，一顿操作然后再回写数据。

@gantleman 前面已经举例了，场景中玩家释放范围技能，技能还分各种类型，与玩家当前的 Buffer 息息相关。想想你状态都放 Redis 逻辑怎么写？ PVP 的时候，血量，Buffer，技能类型的触发逻辑还是要非常严谨的。2 人一起释放技能攻击第三方，第一个技能攻击到受击者触发一个被动 Buffer 并进入 CD，第二个技能攻击到受击者，但是被动已经 CD，不会触发。按你上面的状态都丢 Redis，先不说你那个取范围技能的所有受击方靠不靠谱，场景角色上挂的 Buffer 血量等等相关的数据不要太多，2 个技能，你要保证被动只触发一次都麻烦的很。这还只是众多技能中非常常见的一些需求。

前面说的都是场景相关的功能，场景，Scene 。什么九宫格，十字链表，相位啥的，都是应用到场景服务上的。
养成玩法就不说了，谁跟你说场景服务是每个玩家每种功能创建服务？创建 Actor 永远都是把相关的放一起，不怎么相关的分离开来的原则。 [连 Actor 的拆分都是要考虑粒度的]

太真实了。。。

说的是 POJO 麻烦，还是 Dto 与 Vo 转换的麻烦？
POJO 嵌套可以用 lombok 嘛。
至于 Dto Vo 转换这种，MapStruct 了解一下。
https://github.com/mapstruct/mapstruct-examples
这里面的：mapstruct-mapping-with-cycles 、mapstruct-nested-bean-mappings 2 个例子应该是你感兴趣的。

在知乎上又看到了这篇文章。
多说几句，超大地图，AOI 这种，跟放不放 Redis 没啥关系。所谓的相位技术也这是场景分割的一种方式。数据不放 Redis 的原因是，场景中的计算本身就需要实时，放到 Redis 中还得要异步的读写，明明用了 Actor 模型将关联逻辑分割到一起降低了并发与同步的心智包袱，又引入一个外部缓存让计算变成异步的，带来的数据一致性的问题完全抵消了 Actor 模型的优势。大量的位置数据，AI，技能延时，技能范围伤害等实时的逻辑都依赖状态，这些状态放外部存储中逻辑写起来有多麻烦尚且不说，拆的这么细，性能风险很高。连 Actor 的拆分都是要考虑粒度的，状态提出去把场景服都搞成无状态实在不觉得收益在哪里（养成等玩法无状态倒是没啥问题）。
Actor 模型在游戏界中往往用 state full 的形式，场景不是简单的状态，而是 状态+计算。
像微软的
Orleans （ https://github.com/dotnet/orleans ）
与 EA 开源的
Orbit （ https://github.com/orbit/orbit ）
这种新型的 Virtual Actor 模型的框架，游戏场景的使用都是 state full 的形式。
redis 的优势，
集群，游戏已经场景逻辑上已经通过 Actor 分割了，用不上。Actor 分割出来的逻辑数据单元关联性要强的多了。
各种数据结构，性能有没有优势不说，放外部已经高了不少延时，最主要的是复杂点的数据，没法按场景服务计算式需要的结构，直接扔 Redis，最后必然带来一个转换的开销。
各种过期淘汰策略，这在场景服务中做完全没问题啊，业务逻辑中 timer 相关的东西多了去了，Redis 反而不够用。

示例中场景，交互性太弱了，角色与角色之间的交互太少，跟真实游戏的业务场景相差太大了啊

当然，说了这么多，都只是解决大场景，同场景的一些方式方法。
万人同屏这个不敢想，个人觉得，目前的硬件，最后无论用什么方式（除了 step lock ）做到了万人同屏的效果，
我估计实时性肯定无法让玩家能感受到正常的游戏体验。

游戏中的这种场景，一般都是不用 redis 的。如果考虑支持在线数高，还是偏向于数据直接放在场景服务的内存中。

@b00tyhunt3r 说远了，从头到位都是在说服务端

@ygtq erlang 项目我也参与过，事实上 C++ 的很多服务端也都是封装一个 Actor 的概念出来，用 java akka 的也是这么个概念，skynet 用的人也多，也是 actor 的概念。

我一直想说的就是游戏与 Web 都有他们各自复杂的地方，但是 Web 在解决他们面临的问题的时候更上层，那么多库框架中间件都是在尝试更系统的解决他们遇到的问题，游戏界这块真的不咋地。实际情况就是我看到的绝大部分代码真的很烂很烂。顶级项目吧，也没看到有什么开源的好的。

@b00tyhunt3r 我想说的就是类似这样的问题，很多游戏服务端看起来好像解决了这个问题，实际上连最终一致性都没法保证
就以这个例子：玩家背包物品至场景地图再至另外玩家背包，大部分游戏实现是玩家背包物品在玩家 Actor 中（为了方便大量的养成玩法直接改变消耗背包物品），场景地图中的这块区域又是一个单独的 Actor 。Actor 与 Actor 的某一次通信，没有保证（也很难保证）绝对送达且只送达一次。
就我看过的所有实现都是，actor 发送个消息，改变自己的数据，做的更进一步的是会等待一个回复。整个过程实际上是一个事务过程，游戏服务端一般数据都是存储在内存中直接操作，绝大部分实现没有保证布操作是事务的。这个实现过程几乎就是一个不出问题就不出问题的实现。打架默认都是走事后补偿路线。
我在游戏行业十多年了，客户端服务端都写过不少垃圾代码，服务端的项目更是如此。

上面的场景在游戏业务中太常见了，但是并没有哪个组织哪个企业尝试去从上层给出一个框架或者库的解决方案。反观 Web 领域，他们的场景也游戏不太一样，但是会在另外的地方有难点。Web 最后是怎么做的？会有开源的解决方案出现，比如依赖数据库的强一致性性能瓶颈后会有人做消息队列，消息保证有且仅有一次消费，消息能持久化保证不丢失，大量的这些中间件，各种 Web 框架给开发者提供源源不断的动力。而且代码质量非常高，往往技术选型上升到范式，友好度，维护性这些上去了。

反观游戏界，以 java 为例，用个 netty 就算比较现代了，akka 的算是很前沿了，这些东西都不是为游戏界输出的，当然也不是游戏界产生的。老实说游戏界没产出啥开源方案。大家都是网络框架选型完了，数据库选型完了，剩下的就又开始在那个小圈子转来转去了，多少年都是在解决那些同样的问题。

看过很多很多所谓的流水很高的 C++ 游戏服务端代码，大部分都是一坨烂泥。游戏界真的很奇怪，你说难点吧，确实很多，一些方面比 Web 领域的要复杂很多，这些难点吧，都还被一定程度的解决了或者说绕过去了。
听起来像很牛是吧，实际一看代码后，你会怀疑人生。
比如说数据一致性，分布式，包括像现在流行的微服务中的一些设施很多游戏服务端都有自己实现类似的概念，但是，和系统成理论的，成体系的，讲范式讲使用体验的现代搞法完全不一样。
很多这样的 C++ 的代码只是在一个小小的项目中不停的被重复拷贝粘贴修改，其中一堆的隐含前置条件，只能在本项目中保证绝大部分情况下不出问题而已。
看看游戏界的开源情况就知道了，可能因为本身相对还是太小众吧。
就技术而言，特别是 java 这块，总体平均水平看的话还是 Web 方向有技术含量些，你看看 github 上那些开源的 java 游戏服务端的项目都是些啥。

akka-stream，前面 gateway 将 tcp，http，websocket 消息统一转换成内部消息。
剩下的就是一致的消息进入到流中统一处理。后期换可以方便的扩展成集群模式。

以题主链接中的片段为例：

```typescript
function factorial (n: number): number {
if (n == 0) return 1;

return n * factorial (n-1);
}
```

在 js 中，不看完这个函数，你知道调用的时候可以传什么参数进去吗？ string 支持不支持？返回值是什么类型？
js 中这个函数最后类型还是会在注释中描述出来。

复杂点的例子就是支持 uniontype 的时候，js 就更吃力，注释里面往往大段还说不清楚，必须跟到代码逻辑中才能确定。

更吃力的是，js 代码你在看的时候想跟进去看，你的编辑器跳转的根本没法保证正确，有时候跳对了地方，有时候又不是。最后你也不敢完全相信编辑器的跳转。只能自己不停的在脑子中过一些没必要的逻辑。

ts 正是因为比较严格的类型系统，编辑器能准确的跳转的函数定义的地方，真的跟起复杂项目的逻辑得心应手。

看代码，不是看字符串多少，是理解逻辑脉络。ts 这方面绝对是甩 js 几条街。

其他什么重构就不说了。