连核与核之间的 cpu cache 同步都嫌代价大，你还搞 异地的？

2 不存在

有规范，可以不区分

@Pogbag 你应该切分管理面和 业务面，esxi 管理口 eth3 插网线访问 有啥不好的么？

过度设计的本质，你是拿着成品的组件去堆服务，而不是从整体架构上定制实现。

楼主的 esxi 虚拟机部分 拓扑过于复杂很不建议

不晓得为什么你的 AP 接了三个线回软路由……

人行邪道不能见如来

@aguesuka 感动，在 java 甚至打日志都能出大 bug ；

完成度很高

难买你高兴

神奇的需求 自带 卡顿是 app 的 bug 不是系统的，从来没遇到 1v1

换 air

@demo 奠定社区风格基调，类似 zhihu

牛，问下 网站备案了么？ 内容合规审查怎么做的？

直接网盘或者各种相册（时光相册等）

操作系统不会要你的 classpath

classpath 只是一种约定俗成，某些应用会使用这个环境变量

印象中 jdk5 还是 6 开始就不需要单独在系统中设置 classpath 环境变量了，

来自开发者的回复：

There is no discrimination here, The logic you see here is used to auto separate users that use AWS and Tencent Provider, and for users from China Tencent is the default provider.

We decide to make Tencent as the default provider in China as we cooperate with Tencent closely to provide the best experience for most users from China, and user may easily switch back to AWS if they wish by set SERVERLESS_PLATFORM_VENDOR to aws or SLS_GEO_LOCATION to anywhere else than cn.

We need to know if a user is from China, then we will show CLI context in Chinese to make it easier for users from China use the CLI and understand help info we want to tell users.

Technically, we have have different architecture on AWS and Tencent, as the infrastructure is different, so we have different CLI (Framework CLI and Component CLI) to help user using serverless, to make user has the best experience, we nested the components CLI in the Framework CLI , they all will be triggered by commands serverless or sls, with geo location info we can easily find the correct CLI for all Serverless users.

We worked a lot to improve the experience of users from China, not only the Chinese content, but also the user scenarios that China users preferred (eg: easy deploy WEB framework app to serverless, like Express, Flask, ThinkPHP).

Hope this give you a clear idea why we check geo location and vendor info in our code, please let me know if you have future questions.