规模没那么大，合并之后内存用量减了10G不止。而且我们这里没有专用的开发环境...

【 在 oldwatch 的大作中提到: 】
: 这个规模的集成测试本来就不应该在开发机上单机跑啊……
:
: 当年我们拆模块（我怵微服务这个词）一大动机就是单体war启动一次几百秒
: ...................
--
FROM 125.168.196.*

我早就说过鼓吹微服务就是云厂商的阴毛。故意让软件变得又慢又大，好让云服务商的服务器多卖点钱。

【 在 littleSram (littleSram) 的大作中提到: 】
: 让客户上云啊
--
FROM 112.47.122.*

其实我一直觉得微服务的重点应该是你说的那堆”其他“


前面其实就是传统的模块化/分布式


【 在 Mikov (Mikov Chain) 的大作中提到: 】
: 新技术都是为了解决一些旧方案无法解决的问题, "微服务"这个词有点被滥用了.
: 问题就是两点: 1)它解决了什么问题 2)怎样算合理使用
: 对于1), 我自己的感受是
: ...................
--
修改:oldwatch FROM 116.233.186.*
FROM 116.233.186.*

也许我没看懂... 我们说的不是一件事?

【 在 hgoldfish 的大作中提到: 】
: 我觉得它的大多数好处都可以用 git 子仓库加上 gradle 脚本获得。
: git 子仓库完全可以代替 jar 包的功能，而且还能随时修改代码，通过测试后自动发布到整个公司所有的项目里面。
: 需要横向扩展的时候，就用 gradle 脚本从同一个代码基构建出不同的版本。
: ...................
--
FROM 60.253.242.*

微服务是为了解决什么问题呢？

1. 首先是复用代码和业务。类似于 jar 包，但是又比 jar 包更独立

同样的 git 子仓库，也是实现复用的一种办法。确实不包含运维规则，但是很方便参与修改代码。

2. 微服务提供运维脚本的最小单位。

git 子仓库，可以在内部包含各种脚本，而不像 jar 包那样只有纯粹的 .class. 所以可以由开发小组同时提供 docker 脚本和 gradle 脚本。比如 sql 的连接参数、nginx 的 lua 脚本，负载均衡的相关配置。都可以放在 git 仓库里面的单独目录中，供最顶层业务逻辑调用。

-------------

对于非 java 社区，微服务还提供异构技术栈(go, java, js)，但这个对 java 社区没用，我没看到 java 社区真的用好几种语言编写微服务的。高可用性(网关), 负载均衡等等，其实并不是微服务的本质特征，使用其它技术也很容易实现。

所以我的核心观点就是微服务最核心就是“复用”，无非是 jar 包的升级版，没什么了不起的。有千百种办法来做这个事情。微服务通常是最差的那种。

-------------

微服务绝对是云厂商的一种阴谋。这个技术对大规模的项目是很有用的。但对于中小型项目，它显著地拖慢了处理速度，增大了开发难度和运行开销。是一种很糟糕的技术。

微服务很适合程序员作为简历技能，类似于现在 js 程序员的“函数式编程”，很酷炫，会了以后薪资翻倍。在大厂求职的程序员一定要学一学，但如果是创业公司，要慎用这个技能。

【 在 Mikov (Mikov Chain) 的大作中提到: 】
: 也许我没看懂... 我们说的不是一件事?
--
修改:hgoldfish FROM 110.81.42.*
FROM 110.81.42.*