十几年不搞 Java ,重新看起了微服务

1. 不同业务之间无缝互相调用
2. 针对不同调用者鉴权
3. 熔断和限流
4. 全链路日志和追踪

只要跨部门或者跨项目，一定会面临第一个需求，你可以上微服务，也可以简单写死 http 请求。但是服务数量一多，写死是不现实的，规模越大，微服务该有的东西越刚需。

在项目 boot 起来之后，微服务那套东西，有没有明显降低业务开发效率？

过去老一代程序员，写个数据库可能都会嫌麻烦，写文件它不简单吗？最早的高校 BBS，不都是 telnet 协议，帖子都自己写文件里吗？那个年代还有嫌弃 IDE 麻烦的，甚至 git 和 svn 也接受不了。而在你们看来，写 db 是跟呼吸一样自然的事情。

现在接受不了 soa，也可以理解，毕竟你只是老了。而 00 后甚至 10 后眼里，soa 和容器都是很自然的事情。

有没有那么一瞬间，网络上的新词你要搜索一下才知道是什么意思？一个大部分 00 后都知道的人名，你要搜一下才知道是谁。

将来，你也会学不会新的高科技产品，就像现在老年人玩不转智能手机那样。

工业级语言。
提供了铁锹和挖掘机，能力是给你了，种个地非得开个挖掘机去也没人拦得住。
个人也是非常不喜欢现在 Java 过度的面向框架编程。

微服务是一种架构思想，跟语言没有关系，spring cloud 是 java 这种语言实现微服务架构最便捷的一种方式，全家桶一套全包，你哪怕不用这些乱七八糟的框架，直接用 http 调用的方式提供服务，也可以搭建成一套符合微服务架构思想的系统出来（本来 spring cloud 也是基于 http 协议，只不过人家提供了微服务周边的一系列工具，比如注册&发现、熔断&限流等）。

如果像你所说的，小 bbs 论坛，功能简单，公司里的人又少，还非得搞微服务拆分，这真的是给自己找事儿干，反之如果一个网站非常庞大复杂，比如一整个淘宝、一整个爱奇艺、一整个抖音、一整个 B 站，它们内部分了很多很多部门，每个部门管自己的事情，有数据平台、中间件、AI 、账号系统、弹幕系统、影视系统、评论系统等等，而且每个部门甚至使用不同的编程语言，这个时候你该怎么协调呢？还是大一统，将所有的项目放到一起，复用的代码搞成 jar 包通用？你会发现如果这样搞，这个项目维护起来会非常痛苦，对测试、开发的效率影响都是巨大的，更何况放一起还有多个人开发同一块内容导致 git 提交冲突的问题。微服务从来不应该是为了炫技而强行使用的东西，而是面对复杂庞大的系统时不得已之下才去用的东西，不然图啥，打个比方：你一个简单的系统，所有的东西搞成一套，事务会非常靠谱，你非要搞成微服务，这样即便俩服务连的是同一套数据源也会有分布式事务问题，何苦呢？

其实小到开发一套框架或者设计一套普通的业务项目，大到一整个架构体系，所围绕的核心无非是：高内聚、低耦合，只不过面对的对象不一样，你拆分产品需求，做业务划分，这是针对产品提出的需求后由工程师们自发抽象，做出的针对业务的高内聚、低耦合（也就是常说的业务拆分和复用），而你用分层和抽象的方式做代码封装，这是作为工程师在实现业务时对代码的高内聚、低耦合，而项目与项目之间按照具体功能方向的划分，又拆出一个个的项目，交给不同的人负责开发和测试工作，这是对整体架构的高内聚、低耦合。它们最终目的一致，只有面向的对象不一致。

跟 Java，微服务这些都没关系。是你接手的项目或者接触的人辣鸡

下回别接这种活儿了，把这个赚钱的机会留给别人

@mitu9527 摆明了就是攒经验跳槽

微服务从麻烦到真香，中间只差几个工具而已。你需要 CI/CD 、自动化的容器化部署、全链路日志追踪、能够进行统一身份认证和鉴权的网关。最好还要有用户管理、权限管理、消息管理、账户管理、统一支付接口等等。当这些都具备的时候，微服务就能够让你专注于业务了，一两天功夫一个业务就简简单单发布上线，真香。

其实作为一位正经历微服务改造的人来说， 如果项目不大，程序员数量较少就不要使用微服务框架了。真的是耗时耗力，而且非常影响开发效率。
我建议若是中小型项目并且技术团队成员比较少的情况下, 比起使用微服务而言 还是需要更合理划分不同模块，明确不同人对于不同模块的职责，这样不仅开发效率快而且性能绝对比微服务高(毕竟没有网络调用消耗)。
对于大型、超大型并且那种涉及不同部分技术团队的时候才需要使用到微服务，所以大家还是不要把 微服务当作救命解药了，还是根据自己项目的情况合理提出建议吧。
真的，若非必要 不要上微服务 /(ㄒoㄒ)/~~

不是 springcloud 的锅 是架构手里只有一把锤子看什么都是钉子而已

都十年的老兵了，思想上也没成长多少嘛。大概是一年的经验重复了十年？

微服务不是银弹

@pultako 嗯，明白。拿出各种“词藻”来忽悠，花别人的钱，给自己攒经验，最后项目死了，自己也“风光”的跳槽了。

害 先压测一波看看现在啥效果

开发人员不行不能怪 java 不行，大部分项目都不需要上微服务，单体多模块就够了。前面搞个 nginx 就好罗。

所有吹过微服务的都忘了有一个强大的运维团队在做支撑。只是把研发的事交给运维了…微服务真香定律？把运维团队干掉去，研发自己折腾一遍试试？

@sampeng 微服务还真不需要专职的运维。我们团队也就十来个人，里面还包括了 4 个测试，并没有运维，但我们玩微服务还是很溜。如果没搞微服务，还真的应付不来 4 个产品的疯狂输出。

@sampeng 没听说过微服务靠运维团队支撑的，最多设立个基础组件部门，里面也都是做微服务中间件的研发

@mreasonyang 只有十来个人的团队咋分出来基础组件部门…都是这些高大上的微服务组件都得运维来玩…

@xuanbg goodluck…

正常是先单体应用方便快速迭代，中期项目复杂度、流量真的上来了或者团队人员有了更细的拆分后才会重构到微服务的，把这个流程反过来搞是不合理的。另外微服务和语言没直接关联，Java 的微服务组件生态完善不是缺点而是优点，不要觉得是 Java 系的东西就是 low 的。