中小技术公司的软扩展(微服务扩展是否有必要?)

这篇文章主要探讨一个问题?

前段时间爆火的微服务,容器,高并发等各类大厂扩散出来的'高级技术',如今又被不少人诟病,特别是一些中型公司,盲目技术迭代后,寒冬一来,发现企业代码逻辑太复杂,人员无法精简,甚至于最后连扩展都成了问题.最终导致成本无法控制,技术成为拖累,于是一部分程序员开始呼吁,还是单体技术架构好,中小企业,别去搞 那些幺蛾子.

关于这一个问题我想到两个解释角度:

1, 微服务的发展就是因为当时阿里等大公司业务发展快与技术硬件承受能力(中小公司不也在纠结这个问题吗?想用尽可能少的硬件支撑尽可能多的业务.硬件扩展要钱嘛)

2,微服务的应用带来的技术难度真的就难于单体服务代码堆积如山之后的维护难度?(这个问题要问程序员,正好我就是,我的答案是不一定.)

而这两个看问题的角度其实有个共同点,那就是度.转型微服务的程度.

也就是说,转型微服务的程度,不要全盘接收目前微服务架构的所有技术方案,而是综合考虑,如果是单体架构不断发展,始终要进行的迭代升级,而把一次次可能的迭代成本,通盘考虑,如果只是引入微服务,缓存,消息队列,加上微服务必然带来的分布式事务,分布式定时器.

综合下来看,技术复杂度肯定是略有上升,但这个技术复杂度完全是可控的,经过系统培训,习惯养成,这个上升程度其实并不大.主要的差异在于编写代码的习惯切换过程.

那么下文,我将围绕一个具体案例,来梳理上述提到的几个技术点.具体将每个中间件之前,先来一张图,了解个大概(具体类型我选的其中一个,大家可以找平替,如mysql换成SQLSERVER)

SpringCloud:

MySQL: 

Eureka:

Zuul:

Feign:

Quartz:

Redis: 

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

Nginx:

Docker:

Linux:

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

MongoDB:

RabbitMQ:

Kafka:

这篇文章是个开头给出一个问题,那么这个结尾,就可以得出一个总结:

                                                                                 (  一个框架,一个系统,N个中间件,N系统协同  )