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

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

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

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.*

核心都是复用。为什么说关系不大？

运维方面，解决方案也有很多。docker 也只是一种方式。其实 java 社区是最不应该用微服务的。要用也是 python 社区用才对。

【 在 guestking (无) 的大作中提到: 】
: 其实微服务和git关系不大
: 我的观点是，微服务，或者说是docker，最大的作用是改变了交付方式
: 现在越来越少听到诸如“在我这里是好的啊”这类的话了
: ...................
--
修改:hgoldfish FROM 110.81.42.*
FROM 110.81.42.*

怎么不是复用啊。。微服务当然能让交付更方便，但那是 docker 的功劳，不是微服务的本质特征。

一个完整的项目拆成多个微服务，就算 docker 再方便，仍然是稍微不方便布署的吧。k8s  的 yaml 都写好几份呢。唯一能解释的就是微服务同时也具备 jar 包的功能，用于复用代码——这个项目用的，下个项目可以继续用。

说到复用，jar 也可以做到。无非是微服务的复用故意多加了 http 的限制，从随意的复用变成了不随意的复用。

说是不随意，其实还是随意得很。确实都是 http restful，但 json 里面的内容乱七八糟。于是很多人就改成了 grpc，然而这不是跟直接函数调用差不多了。又开始乱七八糟起来了。

【 在 sixue1999 (宋似雪) 的大作中提到: 】
: 因为不是复用
: 我觉得微服务主要的作用在于用一种物理限制（比如http协议）
: 来规范模块之间的接口
: ...................
--
FROM 110.81.42.*

jar 里面只有 .class 文件和 manifest.

而 git 子仓库，里面有各种运维脚本，gradle 脚本，里面包含 k8s pod 描述也是可以的，很灵活。

【 在 guestking (无) 的大作中提到: 】
: 这个没怎么用过
: 好奇问一下，和我直接dependency其他jar，有什么优势吗
--
FROM 110.81.42.*