从单体架构迁移到微服务,8个关键的思考、实践和经验

随着微服务架构的持续火热,网络上针对微服务和单体架构的讨论也是越来越多。去年的时候,社区更多的关注点是在二者的区别以及优缺点辨析上,而今年,越来越多的人开始关注如何从单体架构迁移到微服务上。毋庸置疑,微服务的理念正在席卷整个开发者社区,像Netflix、Uber这样的公司都是非常成功的应用案例。

但需要注意的是,实施微服务,也需要付出额外的代价,Martin曾经就说过,除非面对的是一个过于复杂以至于难于管理的单体应用,否则绝对不要考虑使用微服务。大多数的软件系统应该构建为独立的单块程序。确保注重单体应用自身的模块化,而不要试图把它们分离成单独的服务。

普元软件产品部技术经理刘相在微服务架构上有很多的实践和思考,InfoQ记者就单体应用迁移到微服务的8个关键问题对他进行了专访,内容涵盖传统单体式架构的挑战、实施微服务架构的铺垫、改造原则、数据库、中间件、分布式事务、风险规避等。

InfoQ:就你目前的观察来看,企业为什么要从单体式架构迁移到微服务架构?他们遇到的最大的问题是什么?

刘相:我所服务的企业多为传统企业,代码在100万行的项目比比皆是,庞大复杂的项目使得开发、测试、维护、运维极度复杂,在弹性、扩展性、可维护性方面也困难重重。除此之外,传统单体式架构遇到的问题还有:

1、团队接手困难

8年前,我曾接手一个100万行级别的项目,那段经历算是一段噩梦:花了3个月的时间通读一遍代码;每次修改代码心惊胆战,修改一个Bug极可能带来各种隐含的缺陷。

2、臃肿的部署

单体应用每次功能或者缺陷的变更导致重新部署整个应用,这种部署方式影响大、风险高,决定了部署频率低,导致两次发布之间有大量的功能或者缺陷需要进行变更,出错概率增高。

3、局限的弹性与扩展能力

单体应用作为一个强耦合的整体,无法根据业务功能伸缩,只能作为一个整体进行扩展。这造成资源浪费,同时无法针对不同业务模块的特性进行有针对性的伸缩,比如计算密集型服务、IO密集型服务。

4、阻碍技术革新

团队对新技术的渴望是不言而喻的,团队士气会因为持续的关注在巨石应用的技术栈而降低;单体式架构下的组织通常来说技术选型非常单一,团队技术能力相对单薄,团

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值