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

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

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

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

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

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

1、团队接手困难

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

2、臃肿的部署

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

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

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

4、阻碍技术革新

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