前端实现就是把整个 dom 转换为图片吧，有一个库叫做 dom-to-image，然后上传到服务器。
如果想要后端实现的话，想一下，一个网页的构成为 HTML+CSS，这意味着你要在服务器上面渲染一个页面，包括同步客户端上的操作（跟客户端保持一致），很难想象为什么要这样做。后端一般只是单纯的记录日志，比如用户点了啥，这种活动追踪只记录相关的日志信息比较好实现。

我目前用的 frp，需要配置手动写配置文件，暂时没有遇到什么问题。nps 没有测试过，不过看介绍优点是可以动态管理配置信息不需要重启服务，两个都是 go 写的，部署也比较方便。

不过你这个几千个节点建议还是自己测试一下才能知道最后的结果是啥，转发服务器的带宽配置也需要考虑。

分两部分看：
密码一般不可逆，我们也没有必要逆向出密码的明文，因此属于哈希类的，只需要通过相同的哈希算法得出一致的结果就行，不关心它的明文到底是什么。

但是手机号等这类信息是需要可逆的，也就是加密之后还得解密，落地存储到数据库的时候到底要不要对此类信息进行加密，我记得三级等保是需要的，但是加密的一个后果就是无法支持区间条件查询，比如一个需求是查询所有以 188 开头手机号的所有记录，加密以后就无法进行范围匹配查询了，当然了，也可以有其他的辅助性的索引支撑，但是复杂性也会随之提高。

我又要唠叨一下了，没有绝对的安全，只能尽量保证在泄露数据之后，使泄露出去的那一部分无法单独得出有意义的结果，比如只是数据库被脱库了，但是没有应用代码的逻辑，即使拿到那一部分数据也是没有意义的。当然了，如果你的应用代码和数据库全被扒了，那么再好的加密措施也会变得没有意义，就看对方是否愿意花时间在这上面研究了。

在同步编程模型下直接通过本地线程变量获取绑定的信息，相当于在这个线程上下文中设定了全局变量。

使用同步编程模型，如果在 service 里面获取当前的信息，就跟使用 service 的环境耦合了（本地线程变量），service 不是无状态的。

当然如果一直使用这种同步编程模型是没什么问题的，但如果想要在异步环境下不改变代码也可以使用 service 的话，就必须要在执行阶段先进行类似环境绑定的操作。

比如在执行前，将之前的全局变量绑定到当前的线程，执行完以后再清除避免下一个执行任务获取到错误的信息。

@zhilincom 硬编码拼接除非字符串这些是固定可预期的值，否则会出现像 SQL 注入的那样，破坏了 JSON 的结构。另外，反过来想，与其调用 toString 返回 JSON 字符串，为什么不直接把对象传给 JSON 序列化器呢？

例如：JSON.stringify(obj)

看书要想记着点东西就需要自己阅读过后有一个总结，有自己的思考。
虽然不至于像我们以前读书的时候那样，学完东西还要考试，所以关键还是在于你看书的目的是啥？

而且读不同的书也有不同的读法，像楼主你提到的这种书专业性都比较强，如果不是带着苦思于如何解决问题的目的去看的话，一般了解其中的概念就差不多啦，细的东西等真正用到的时候再查不迟。

看，总比不看强，打开书本就成功了一半。

@hiphopluda 有方法打开，不过需要一些特别的技术，这些技术我相信圈内人士都应该明白。

很久以前看过一本书，叫做《暗时间》，上面说的是：
我们想要自律其实就是改变习惯，但是改变习惯不能靠意志力或者自制力，而是靠知识，让自己真正的接受某一个现实。
习惯之所以难以改变，是因为它是自我巩固的，越用越强，越强越用。

个人认为算法的目的在于，提高计算机的处理效率，在时间复杂度和空间复杂度之间做权衡。

那么首先得搞明白计算机的体系架构，比如搞数据库的，就要考虑到在传统机械硬盘的固有缺陷下如何更好的提升吞吐量。

很多时候我们并不需要去关心如此底层的东西，计算机发展到现在基本上所遇到的问题都有的相应的解决方案，各类编程语言也有相应的库供我们直接使用，我认为学会 Google 比什么都强。

一般涉及到消息发送都基本上是异步流程了，建议在一个本地事务中将需要发送的消息写入到一个“消息发送表”内，另一个线程定时扫描这张表，然后将消息发送出去，发送完成就可以删掉或标记为已处理，发送失败记录失败次数和异常等原因。

使用帧同步的这种游戏一般来讲实时性和运算复杂性要求都比较高，服务端不大可能参与运算。对于外挂，每一家公司都有不同的策略，有的是通过举报，即不公平性导致其他玩家察觉出外挂的存在，作弊玩家顾忌账号的注册成本，或者通过技术性的检测（即在服务端模拟一个轻量级的客户端接收事件序列，模拟当前的状态是否有异常，不过开发成本也会比较高）。

假设当状态都由服务端来进行计算，客户端的每一个细节都需要考虑到，计算量就会特别大，而且将这些计算完毕的状态再同步下发给客户端的网络带宽也很高（例如某一个物品的位置、状态），而且对于物理引擎也要跟客户端同步，比如计算碰撞、物理惯性各种细节，因为逻辑帧相对来说都比渲染帧要低，客户端也不能够完全按照服务端下发的状态进行立即同步，不然画面显示就会有卡顿，客户端必然要在本地进行平滑过渡处理，处理不好可能会导致画面漂移等一系列问题，就需要一个取舍。

所以在服务器进行状态运算产生的问题就是网络带宽和运算性能。

现在有一种叫做云游戏的东西，客户端只是当做一个“视频播放器”，把触摸或按下键盘的操作发给服务器，服务器完成操作渲染后传输流数据给客户端，客户端安装包可以做到很小，只有几 MB 。对于高实时的游戏来说明显会感觉到延迟，就像手机通过 2.4G 无线 WIFI 投屏到电视一样，手机画面同步到电视上总会慢一拍。

也有说网络延迟会越来越高，这个问题其实有时候我们玩游戏也能够感觉出来，一种做法是快进播放，网络的延迟只是暂时的，当它跟上来了，就需要把之前的逻辑帧补上去，所有有时候会觉得画面突然的快进，其他的玩家不会等你，在其他玩家看来你只是停留在那里，谁叫你网络不好呢对吧？

假设服务端只负责事件转发，就需要确保客户端的运算结果是一致的，包括不同设备 CPU 的浮点计算结果一致（有自己的底层计算库），游戏引擎也要做适配，不然就会产生不同步的现象，要保证这一点就需要大量的测试，尽可能覆盖多一点的设备。但是开发成本显然更低，只需要侧重于客户端，并且减少了与服务端的联调，开发效率就会提高。

声明式事务实现原理就是利用 AOP 代理拦截目标方法，在目标方法调用前后实施事务外围工作。

感兴趣的可以看一下 org.springframework.transaction.interceptor.TransactionInterceptor

@3dwelcome 这应该是国内大多数中小型公司的常态，我们都知道有些事情是对的，但是却往往被情感左右。说到底一个人都不完美，更何况一个群体了。

所以尽管工作氛围不尽如人意，但是决定我们自身如何的还是我们自己。工作沟通上保持积极，认真做好自己的工作，专注和坚持从来都不容易，真的是需要长久的磨练的。有点鸡汤的味道了，祝你能够踏上自己所想的那条路。

CRUD 也是有讲究的，你看，实际上就两种操作，一种是修改，一种是查询。
简单的 CRUD 从前端到后端甚至数据库字段都完全一致，就是面向数据库编程，Service 都不需要。

复杂一点的，把这两种操作当成两套代码来写：

修改操作多以动词命名，会精炼出业务的实际需要的操作列表，把他们全部放在 Service 里面，每一个方法就是一个事务，或者使用门面模式封装独立的命令执行（命令模式）。

查询操作完全取决于你的消费方需要什么样的数据，把查询的逻辑处理全部放到 Repository 里面，返回 View 或者 DTO 啥的，只专注于如何批量查询并组合成需要的数据，可以是 SQL，可以是 HTTP 请求。很多人喜欢把查询也放到 Service 中，但实际上两者的关注点是不一样的。

读写分离以后好处是显而易见的，查询和修改都可以单独进行优化，最重要的是更加清晰可读。
当然以上只是一种方法，从技术上来讲，写业务代码最大的难度和关键点在于需求是否足够清晰，领域知识是否完备。反之造轮子则不需要这些额外的知识，但终究来讲轮子也是服务于某一个技术点的，最终也是要服务于业务的。

帧同步需要客户端计算结果严格一致，不然就会走偏，服务端在一局的游戏中只扮演数据转发的角色。

如果只是想要知道如何使用，则不必关心背后的算法，只需要学习一些使用案例，在不同的场景下使用不同的算法。
当然如果是专业搞数据信息安全这一块那就厉害了，起码数学功底要够硬。

不要自己去创造加密算法。
不要自己去设计加密算法。
不要自己去实现加密算法。

除非你知道自己在做什么。