@brader 这种写法 任何语言都支持，go 可以用 map ，java 也可以，c#也可以。 只是维护起来 要把人搞死，所以没人用。

相反，你在 php 里用实体 也是可以的，只是 php 基本上面向快速建站，所以很多为了后期维护而存在的规范，在 php 里都基本上不被重视。

很好奇，php 如果要返回 json ，不需要实体吗？ 将参数传给 service 不需要先封装到实体里面吗？

如果你在 php 里用的是 map ，那当我没说。

并发问题就是加锁，没别的

其实 redis 也有持久化能力的，之所以不只用 redis ，是因为 redis 的定位就是 内存数据库，他的设计初衷就是作为一个缓存而存在，并不是作为数据库的。

而你这个项目，从使用的角度来看，跟 redis 没啥区别，我建议你 后面可以在 查询方面 下点功夫，将查询能力丰富起来，这样就可以去打 redis 了

感觉你给自己挖了一个大坑，一上来就给这个项目定位了 redis+关系型数据库的 优点结合体，只用这一个就解决问题。

但是关系型数据库的作用，你一开始就想错了，他并不是 redis 的补充，反而 redis 是关系型数据的补充，它弥补的是关系型数据库查询慢，并发低 的问题。

关系型数据最大的优点就是，他一开始就是为了持久的储存数据而 开发的，并且功能丰富，操作灵活（得益于 sql ），起码就目前而言，关系型数据库是 储存数据的不二之选。


所以，我再次建议：

你就干脆把他当做 redis 的竞品，而不是 redis + 关系型数据的优势结合，想办法做的比 redis 更好用， 尤其是丰富查询能力。

因为关系型数据库的优势，不可能被替代的。如果有，那肯定不是 key-value 。

@Vegetable
@basefas

好的，非常感谢

需要等结果的场景，不适合用异步。 异步只适用于不需要等结果的场景，主要是为了快速响应的。

而且你这种情况，对顺序也有严格的要求吧，你可能需要等 A 接口返回了，用 A 接口的返回结果去执行下一步 调 B 接口，用 B 的返回结果调 C 接口对吧？ 如果是这样的话，那多线程的意义就更是彻底被玩没了， 反正都要等了为什么还要用线程？

如果不需要等，对顺序没有任何要求，只要调了就行，那或许还可以试试。但前提是 平常的压力之下，这些三方接口的处理速度必须要 > 生产速度，务必保证线程池里不会挤压任何任务。 让线程池 只用于应对 突发流量，保护三方接口不会被压垮（传说中的削峰）。

线程池其实就是一个内存级别的消息队列

你现在最好的情况是 做横向扩展，在双 12 当天加机器，同时做一下网关层的限流

河西上班，最好在公司附近。。。。。。。

你是在河西哪个地段？？ 整个河西，除了油坊桥那一带的安置房，其他的 起码 5 万一平啊，你这 260 万的预算 还是算了吧。

你可以往江浦去看看，10 号线附近

你说这种生产力，java 有啊，很多年前就有了。 那会儿叫 servlet 。

go 更适合跟 C 作比较，跟 java 比 web 还是差点意思

这几天遇到很多槽点：

1. 反射 必须事先指定类型，无法做到像 java 那样 仅凭一个字符串就能把方法给调用了
2. json 无法转化成 map ，因为 interface{} 无法像 java 的 Object 那样 拆箱成任意类型
3. 没有动态代理，没有泛型

这些问题 衍生出了一个更大的问题，就是开发一些 通用的 工具包，框架 会非常难。 必须退而求其次

这是个很严重的问题，会直接导致三方生态的薄弱

@keepeye 额，好吧，谢谢

@sun522198558

非常感谢你的解答，

但是我看了一下，发现这种方式 只是把 [var demo= &Demo {}] 这句复杂化了一下，我是直接定义的，你是定义后放入 map ，然后从 map 取，没有从根本上解决问题。

不过我还是非常感谢你，谢谢。

@TossPig

首先：RPC 这方面，你只能说是说对了一大半， 还有一小部分 你没了解到的 建议去了解一下，RCP 并不完全 100%指 [远程调用过程封装]， 还有另一种实现规范，就是 请求的 URL 是定死的就是 http://xxxx.xx ，但是参数需要符合某些规范，里面要指定 本次请求的意图，最常见的就是把要调用的方法 当参数传进去， 在区块连上 这种实现方式有很多。

其次：谁告诉你 resultful 是标准规范？ 还有 你看看你自己，把 resultful 当成 真理，非遵守不可，还说不是 教条？？

你就举一个例子吧，直接说，什么场景下 必须用 请求方式去区分 意图， 否则会很麻烦，或者造成代码很烂。 你直接说一个这样的场景出来，你说出来了，我就承认我错了。

本来不想跟你争的，你一来就说我反智，然后又喊我弟弟， 你的语气如此看不起我，我还真得跟你争到底了，除非你拉黑我。

@TossPig 规范不止 restful 一种啊，还有 RPC ， 甚至自定义都行，而且 post 和 put 的请求报文没什么不同吧，服务器解析的方式也是一样的，无论是从效率，安全 还是什么角度来看， 都没什么区别。 个人认为这仅仅是 为了区分行为 而出现的请求方式。

但是行为不是已经通过接口区分了吗，请求 A 接口是 A 行为，请求 B 接口是 B 行为，这多清晰，实在不行的话像 RPC 通过参数指定 行为，也很清晰啊。

而且规范都是人定的，并不是上帝定的，他不是必须遵守的教条， 只要你的设计是有章法的，有讲究的，那就可以了。

远离 restful ，拥抱 RPC 吧，get ，post 一把梭。

鼠标移下去，点一下不够快吗？

谁的代码谁改，这是最基本原则，如果写这段代码的人离职了，那就由接手的人改。 切勿妄动别人的代码。

UI 设计 还是差了一点，跟其他安卓厂商差不多，都是粗制滥造。这也是安卓的通病了。

系统的流畅性 确实挺不错的，之前刚给我爸买的 nova 8 属于中低端了，运行很流畅，这是实际体验。

然后交互逻辑，我就不说了，免得被说精美。

选一个语言，深挖下去 学精它即可。 然后这门语言周边的生态 以及跟这门语言经常合作的语言可以学学。

比如，一个学 java 的人，可以在深挖 java 的同时，抽空了解下 js，css，html，app 开发等。 但是没必要一边学 java 一边学 python，一边学 c++。 没什么太大的意义。

找准自己的定位，想清楚自己到底想从事什么方向，然后学这个方向需要的知识即可。

会多门不如精一门，这是至理名言，当然了，如果你是天才，可以把所有东西全都学精，那就当我没说好了。

都是赶着发布的，使用者也不关心底层，反正又不是他们维护。 他们只想快点用起来。

这是世界通病，作为一个新时代的农民工 没办法的。

2021 年啦....

买个 ipad，下一个微信读书，百度阅读，当当阅读 等 app，或者你直接用电脑访问网站，完美解决你的问题，而且电子书还便宜，内容一模一样。
微信读书 只要开了无线阅读卡，就可以全场免费读。