支持，平常还真用得上

支持支持

支持，有空试下

@kloudmuka 简直就是拉低整个就业群体的信用度

@wyx119911 1. 思路不错，感谢； 2. 可以考虑。并发指的是同步并发还是异步并发？这种内部业务逻辑要求即时处理数据的场景不能使用异步吧。

@lsk569937453 项目要求，不得不上，当时选取微服务架构的原因就不是技术因素

@ZZ74 #19 “内部调用何必呢。” 是的内部调用没有必要鉴权，现在问题是暴露出的所有接口都是面向外部调用设计的，例如说 api 方法签名里包含请求参数 appid 、userid 、sign 、time 等，就没考虑内部调用的场景，导致现在内部调用都是先拼接参数字段再发起请求，和维持一个外部用户 agent 没有区别。所以现在是想绕过这些已经定义的 Restful api 去进行内部请求，但是没有思路。

@lanlanye 2 首先肯定是设计问题，然后又由于 1 加剧了状况，需要写大量的冗余代码拼装请求去进行服务调用，响应时间还很长

@4kingRAS #13 霸王硬上弓，上面有意通过这个项目积累团队开发微服务的经验

@teble 应该这么做，但是开发前期团队其实脑子里都不存在微服务网关这个概念，所以采用的是每个服务单独调用鉴权 SDK 包来实现鉴权，实话说就是单体应用暴露 API 接口的写法，认为每一个暴露的 API 均为外部调用。后面虽然加上了微服务网关，但是之前写的 Restful 接口签名已经很难改了，要改的话等于重构，那就是下一个开发周期的事情了

@wu00 项目的要求，有可能是为了后期移交或者整合第三方系统。肯定不是技术团队的要求，团队成员大多不具备微服务开发的经验，能选的话肯定不会写成微服务的。

@Tumblr #42 谢谢回复。我在 windows 下的 shell 操作一般只有开发用途，进行一些简单文件操作或者查看一下系统变量什么的，偶尔编译一下代码或者访问一下网络资源，应该说，我是没有在 windows 上进行运维的需求的，所以基本上是对 windows 上的 shell 工具集和工具链没有什么了解，连查个命令文档都费劲，嫌 powershell 命令太长只是对此反映出来一个表象罢了。

但是毕竟日常开发和日常使用还是在 windows 上居多，没有一个 shell 不是太顺手。安装一个独立的 bash shell ？使用 windows 子系统？不太拿的定主意，毕竟这两个东西还是可能存在一定的兼容问题。

@Tumblr 'curl'是 4 个字母，'Invoke-WebRequest'是 17 个字母，两个命令的字面名称长度差别太大了。其次，Verb-Noun 这种格式的初衷应该是想通过命令字面名称反映语义吧？我个人暂时感受不到好处，说到底在 shell 上敲命令又不是自然语言编程，写那么清楚、完整的字面命令给谁看？
我是觉得 Powershell 没必要在字面值命名下自己搞这套东西，有那工夫多写几个 help 才实在。
每次看 powershell 脚本真是一种折磨，有的命令几十个那么字母长，到头来也就一个语义，很简单的语句命令给它搞成一坨。我用不明白。

powershell 的命令我用的不习惯，又是大小写又是横杠线的，码出来麻烦还难记

信息时代，密码之类的东西还是写纸上安全一些

1. 读取/etc/resolv.conf 获取 win 宿主机在 wsl 虚拟局域网中的地址
2. wsl 的网络请求指向该地址以及代理开放的端口
3. win 宿主机防火墙允许代理软件通过局域网
4. 代理客户端允许局域网访问，allow LAN

我这里假设你是 win10 下的 wsl2 。wsl 的 github 的 issues 上面挺多这种问题的，不过 wsl 与 win 的网络访问问题在最近的一次大更新中已经解决了, 看 v 站贴 t/975098 。

大学老师教应用开发的水平称得上是一言难尽，我总觉得和老师们不是生活在一个时代。

单说 web 应用吧：
刚读书的时候就觉得这帮子老师生活在 2014 年（ Java8 ），自学了一点东西以后觉得还是高估他们了，觉得他们生活在 2009 年(JavaEE)。临近毕业后知后觉，认为老师们的水平也就是 1997 年水准( http/1.1)。

我现在工作了，觉得这个问题可以盖棺定论了：实际上他们生活在 1996 年( http/1.0)。
还是吃了普通学校的亏。

很好，wsl2 之前在网络访问上的一系列历史问题都将被扫入历史的垃圾堆

5L 说的没错，只要有好游戏，就是最好的购入时间