单体应用是这样的，程序员只要一把梭就行了，而微服务应用要考虑的事情就很多了

上篇文章说了austin会用Spring Cloud Alibaba升级为分布式架构，代码我还在编写修改中，估计很快就可以开放出来。

今天随便聊点分布式架构这事吧。

我是2017~2018年学习Java的，分布式微服务这种概念在当时其实就挺火了，只是时间紧迫，当初学完了ssh/ssm，就觉得差不多可以去找工作了。

那时候大三找实习，很多公司还是ssm/ssh架构，有公司都说自己用的是SpringBoot，我一想，感觉还不错，至少比我这掌握的知识要好啊。

后来面了我进去实习的公司，他说用的是SpringCloud架构，我这一听就心动，我刚出来，学到技术就可以了，3500一个月就进去干了。

另外，老板给我承诺干满3个月，给我升到4000。

等我进去了以后，大多数时间都是熟悉当下被分配的业务，实际上也没什么空管什么SpringCloud。

不过，我还是在业余时间，抽空在实习的时候学习了下，毕竟在我看来算是新技术了。

在我学习的过程中，我再去审视实习的项目，看到它所谓的SpringCloud架构，我感觉被坑了。

注册中心的影子都看不见，服务之间的调用也没有，怎么能算是SpringCloud架构呢。

我看项目代码就用了些SpringCloud的一些组件，这些组件至于是不是真的有用，到现在其实我也没懂。

我在那呆了没多久，我就跑路去准备秋招了。可惜了，没领到4000的工资。

系统分分合合

后来，秋招进了电商公司，公司自研了RPC的框架，我估摸是基于Dubbo上做了开发吧？

我待了两年多也没细看实现原理，主要是大把东西可以学，可能也是因为RPC框架对调用者太透明了，平时也出不了什么问题，亦或是出了问题也跟我没啥关系吧。

到后来，降本增效，要缩减服务器，启动广进计划。

本来每个服务在线上都要分配两台机器（为了做高可用），现在要缩减服务器了，最简单的办法就是把系统合起来。

比如，本来有个消息推送后台web服务，微信管理后台web服务，本来是分开不同的服务的，一共要占用4台机器。

降本可以这样做，把消息推送后台web服务和微信管理后台web服务的代码合起来部署，这样线上一共只要2台机器，高可用没变，这就省了两台机器的钱，简直是美滋滋。

“什么？这两个系统本来就应该分开的，不搭边的，怎么能合起来啊？”

“真不是，那是你的项目名没取对，比如你叫奥斯丁管理后台，那不就得了。只要项目名不跟具体业务挂钩，在里面放什么都合理”

“有理”

大部分合并是同类型的业务进行合并，比如本来都是提供对外服务的，少部分确实是有些从RPC调用改为本地调用。

经过几个月奋斗，服务器哗啦啦的减，这个过程中小的事故是在所难免的，但运行了一段时间后，也没什么大问题。

微服务是真有必要吗？

有的时候我也在想，微服务是不是必要的东西。

1、它不解决高并发高性能高可用的问题，单体应用照样也能实现负载均衡，弹性扩缩容，还少了很多网络的交互呢。

2、说是解耦吧，我单体应用也能划分模块解耦。

但得承认，确实分模块是没有微服务那么彻底，毕竟都进程隔离了。

进程隔离了，项目启动更快了，如果出问题，也只出在对应的进程里了。

Git仓库也被拆开了，多人协作时的冲突也没那么多了，能独立出团队开发了。

不过有一说一，Git冲突过多这事好解决，过多说明人力冗余了，降本增效一波（狗头）。

好处是有的，但没想象中那么美好。代码烂不烂，跟是不是微服务也没多大关系。

有的单体应用，模块划分得好，代码照样好看。有的微服务应用，共用代码到处复制，就为了省事不发包，每次改都要全局搜，每一份都有点细微的差别。

服务拆开了以后，问题倒是有一大堆，解决这些分布式问题的就是分布式治理的框架。

光部署这些分布式治理组件，服务器数量就能蹭蹭涨上去了。

这肯定能利好云厂商。

对Java程序员是利空，得学这些技术栈了。

这些技术栈是不是真的能用到，是不是真能解决线上遇到的问题，这些都不好说。

但在简历上，貌似你就是要懂的。

大部分公司的大部分应用都用不上微服务这种架构，真没必要强上微服务。

SpringCloud也许是过渡方案

Spring Cloud是微服务架构的一个解决方案，他的具体实现之一是：Spring Cloud Alibaba

Service Mesh（服务网格）也是微服务架构的一个解决方案，他的具体实现之一是：istio

SpringCloud是侵入式的，istio是非侵入式的。Spring Cloud支持的，Service Mesh基本都支持。

我们要用SpringCloud要在代码中引入spring-cloud-starter-alibaba-nacos-discovery服务注册发现，spring-cloud-starter-loadbalancer服务负载均衡这种SDK包，要额外部署服务注册中心（如nacos）这种服务。

而Service Mesh不用，它的目标就是要将微服务治理体系下沉为一套与业务无关的基础设施。

我们只需要写简简单单的SpringBoot，不需要引入各种的服务发现，负载均衡的SDK，就能实现SpringCloud所类似的功能，服务治理的相关都由基建完成。

非侵入式，让程序员专注业务，是未来。

但SpringCloud还是得学

不管有没有必要上微服务，现在已经有很多公司已经用上了SpringCloud架构了。

比如我19年实习的小公司，算上我，一共就4个后端，都引入了SpringCloud的依赖...

SpringCloud也许是过渡方案，但存量的项目一般是不会重构改造的。

这道理很易懂，jdk都发布到23版本了，我们还在用8，是不是。

简历不写上微服务的技术栈，都不好意思投递了...