单体式应用向微服务架构迁移实践经验

jopen 4年前

1这些都是推动微服务诞生的重要因素

2领域驱动设计指导我们如何分析并模型化复杂的业务

3敏捷方法论帮助我们消除浪费,快速反馈;

4持续交付促使我们构建更快、更可靠、更频繁的软件部署和交付能力;

5虚拟化和基础设施自动化( Infrastructure As Code)则帮助我们简化环境的创建、安装;

6DevOps文化的流行以及特性团队的出现,使得小团队更加全功能化

独立测试与部署

单块架构系统运行在一个进程中,因此系统中任何程序的改变,都需要对整个系统重新测试并部署。 而对于微服务架构而言,不同服务之间的打包、测试或者部署等,与其它服务都是完全独立的。对某个服务所做的改动,只需要关注该服务本身。从这个角度来说,使用微服务后,代码修改、测试、打包以及部署的成本和风险都比单块架构系统降低很多。

按需伸缩

单块架构系统由于单进程的局限性,水平扩展时只能基于整个系统进行扩展,无法针对某一个功能模块按需扩展。 而服务架构则可以完美地解决伸缩性的扩展问题。系统可以根据需要,实施细粒度的自由扩展。

错误隔离性

微服务架构同时也能提升故障的隔离性。例如,如果某个服务的内存泄露,只会影响自己,其他服务能够继续正常地工作。与之形成对比的是,单块架构中如果有一个不合格的组件发生异常,有可能会拖垮整个系统。

团队全功能化

康威定律(Conway’s law)指出:一个组织的设计成果,其结构往往对应于这个组织中的沟通结构(organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations)。传统的开发模式在分工时往往以技术为单位,比如UI团队、服务端团队和数据库团队,这样的分工可能会导致任何功能上的改变都需要跨团队沟通和协调。而微服务则倡导围绕服务来分工,团队需要具备服务设计、开发、测试到部署所需的所有技能。

来自: http://my.oschina.net/Seaside20151225/blog/595214