03.07 为什么有些公司的server不愿意微服务化?

shoujiweitu2961


微服务是这几年比较火的概念了,很多 IT 公司也都在做微服务转型,那么微服务化适合所有的公司么?微服务架构可以解决一切问题么?我觉得并不是这样的,企业是否需要做微服务转型还是要从实际情况出发。


01. 微服务化倒逼组织架构

说到微服务,很多人会认为这是个技术架构,但我认为微服务不只是技术架构这么简单,它甚至会涉及到组织架构。

通常 IT 公司的岗位都会分成产品、开发、测试、运维,有些公司甚至会分成不同的部门,一个需求的开发到上线,会从前到后经过四个部门的流转,而进行微服务的转型,目的是为了加速业务的响应,快速开发,快速上线,缩短迭代周期,快速试错并纠正。

如果企业想做服务化转型,那么组织架构也需要做相应的调整,否则还像以往一样,部门和部门之间、岗位和岗位之间需要很大的沟通成本,那么微服务是“快不起来”的;比较理想的是把不同的岗位揉在一起,一个团队中包含产品、开发、测试、运维四种角色,团队成员彼此协作负责一个或几个微服务的迭代和运维。


02. 设计更为复杂

判断是不是适合微服务化,也要看自己的业务场景,如果服务做拆分,只是为了拆分而拆分,是没有意义的,通常要考虑:

拆分之后的服务,能否被复用?如果一个功能在 A 系统,只被 A 系统自己使用,那么没有拆出来的价值,如果 B/C/D 系统都需要使用这个功能,那么可以拆分出来复用;微服务的优势之一,增加复用,减少重复开发,缩短开发时间,进而降低成本;

访问量大还是小?如果访问量不大且平稳,未来很长时间访问量也不会有很大的增长,那就没必要微服务化,如果有高并发、流量不可预计,那么可以做微服务化。

微服务在设计上也存在着一定的难度,拆成几个微服务?新需求来了,是新建一个微服务,还是在老服务上改造?这些设计层面的考虑,也是非常复杂的。


03. 技术上的难度

虽然我们的服务容易复用了,一个新需求的开发可能做一个页面,调几个接口就完成了,但是微服务的开发和维护,也给 IT 带来了很大的挑战。

  • 服务被拆成了多个微服务,每个微服务又会部署很多套,这时候才使用人肉运维就不合适了;

  • 以前 A 系统的一个接口,变成 A->B->C->D 这样的调用链路了,如果一个环节出现问题,可能导致整个链路上的系统都不可用,而且问题的定位也会变得更难;

  • 单个系统做数据的增改删很简单,通过事务就很容易控制,但微服务化之后,就变成了多个系统的分布式事务,这个难度很大,大多数系统只能做到数据的最终一致;

  • 因为一个功能可能会涉及多个系统,那么测试也变得复杂了。

  • 总之,很多公司不原因做微服务转型,第一就是微服务化的难度比较大,企业没有能力做;第二就是,企业可能真正地思考和评估过,现有架构足以满足业务,没必要做微服务。


我将持续分享Java开发、架构设计、程序员职业发展等方面的见解,希望能得到你的关注。


会点代码的大叔


微服务和单体服务都有各自的优势场景,微服务并不是普适一切场合的银弹。

对既有系统的微服务改造往往需要面临巨大的成本和风险,所需要的承担的责任和勇气超过很多资源不充裕的团队的最大承受能力。

微服务的学习曲线较高,相关工具链的成熟度相对差一些,现阶段可能需要有一定实力的团队才可以驾驭。

微服务的运维也需要额外的成本,对规模太小的团队和复杂度有限的单体服务进行微服务改造,大多数时候相当于脱了裤子放屁。

哪怕当前系统的技术再滥,作为已经熟练掌握它的人来说,离开温饱有余舒适区、去拥抱破旧立新的新技术,都需要猎奇之外更正当充分的理由、优秀的技术品味和有担当的心态。精致利己主义盛行的时代,能够很好的平衡所有这些要素、愿意有条件的主动离开舒适区的领导者和决策者并不多。


晴月浩新雪


有可能会涉及到整体架构的修改,不是不愿意,而是变动很大可能会成为一个旷日持久的工程,或者因为现在业务正在运行在服务器上,没有足够的时间来切换到微服务架构,如果切换本身导致的损失超过了切换微服务的收益的话,肯定不会去做这样的修改的,但不代表没有这样的方案。

而且微服务并非适用于所有的产业,确实对于一部分互联网依赖产业微服务是很好的解决方案,因为可以实现模块解耦,保证了模块之间的依赖性和影响降到最低,但是很多放在云上的可能是企业自己的服务,并不需要解耦,或者至少目前不需要,那么服务商自然不会做这样的事情,除非用户有所依赖,形成一个相当大的趋势,否则服务商的策略变化会影响所有的用户,导致用户流失就不是一件好事了。


榻榻米的榻榻


你们家灶台是和酒店里大厨们用的一样么,各种灶具、锅具、案台……都全么,有必要么?


手机用户54444147856


微服务化是需要很大成本的,如果一个公司开始是使用ssm框架开发,你突然要他微服务话,就相当于让他把之前框架弃用,开始一个不熟悉的新框架。之前的框架都是有很多技术沉淀的,花了公司的很多心血,成本是巨大的,并且微服务不一定是最好的,很多公司的业务并不是很复杂,现如今的服务足以支撑他的业务,完全没有必要微服务化,在加上微服务话是需要时间的,并不能马上就转换,就算是转化了,软件运维也是让人头疼的东西。这就是很多公司不愿意微服务话的原因之一。

希望我的回答对你有帮助,谢谢


逆光的背影


首先应该了解下什么叫微服务,

1. 一组小服务。

2. 独立进程 。

3. 轻量级通信 。

4. 基于业务能力。

5. 独立部署 。

6. 无集中式管理,不用统一技术栈。

什么时候才需要微服务呢?

1. 业务变复杂了。

2. 团队变大了。

3. 开发效率低下了。


分享到:


相關文章: