我虽然不担任什么架构师职务，只是喜欢瞎琢磨，这里就说说我自己的一点不成熟的想法。
有可能我的理解完全是错的。
要说清楚的是：微服务的核心思想是模块化、解耦合，这是程序设计思想中永远的主题，我并不反对这个，我反对的是现在过热的概念操作。就像之前有一段时间流行的中台一样，铺天盖地的各种中台，基本思想是好的，但我绝得并不是一个通用的处理方式，也并不是对大多数人有意义的东西。
我反对的微服务，不是这种思想，而是大家炒热的各种技术框架。
我看过几个 Go，Java 微服务框架的介绍（目前没有深入其源代码的技术能力），都是各种架构和运维中常见概念，什么降级、熔断、服务发现等。技术都是好技术，只是他们似乎想把各种中间件，甚至直接通过代码的方式打包成一个解决方案，仿佛套上就实现了三高（高性能，高并发，高可用）。
框架可能各有独到之处，设计者的经验和能力肯定是远胜于我，但我凭自己一点质朴的想法，觉得最后大浪淘沙过后肯定什么都不会剩。
我觉得发展的趋势应该是不断把业务无关的东西都提取出来形成公共服务，最后需要开发的产品应该是不用理会架构上的东西。如果这种趋势的实现还要很久，那也就算了，但我看现在的发展趋势（k8s, 服务网格），几乎就在眼前了，再继续炒这些微服务编程框架，似乎意义不大。每次看到有框架说自己有啥啥功能的时候，我就觉得是不是搞重复了啊。
最重要一点，我非常确定，如果没有真的掌握相关知识，不管你用哪个微服务框架都是扯淡。我看到有好些个入门级 Go 语言教程的大纲，后面居然好大一部分是讲微服务，这不忽悠么。真到了需要微服务，能用好微服务的人，还需要上培训班来学习一门新语言啊？
我们真正需要学习的应该是产品架构上的各种思想、实际工作中各种技术手段的取舍和应用，而不是去学习这些框架的用法。
Update @ 2023-08-01 《早该意识到，微服务不是标准答案》的观点：
- 成本问题：微服务必须投入大量资源来开发和维护复杂的 DevOps 设置。
- 康威定律：软件系统的结构会反映出产生它的组织的社会结构。大公司的集中化和紧密耦合的依赖关系与微服务的理念相悖（微服务不只是需要将服务拆解，还需要将团队打散）。
