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

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







1、这些都是推动微服务诞生的重要因素
2、领域驱动设计指导我们如何分析并模型化复杂的业务
3、敏捷方法论帮助我们消除浪费，快速反馈；
4、持续交付促使我们构建更快、更可靠、更频繁的软件部署和交付能力；
5、虚拟化和基础设施自动化( Infrastructure As Code)则帮助我们简化环境的创建、安装；
6、DevOps文化的流行以及特性团队的出现，使得小团队更加全功能化





独立测试与部署
单块架构系统运行在一个进程中，因此系统中任何程序的改变，都需要对整个系统重新测试并部署。 而对于微服务架构而言，不同服务之间的打包、测试或者部署等，与其它服务都是完全独立的。对某个服务所做的改动，只需要关注该服务本身。从这个角度来说，使用微服务后，代码修改、测试、打包以及部署的成本和风险都比单块架构系统降低很多。
按需伸缩
单块架构系统由于单进程的局限性，水平扩展时只能基于整个系统进行扩展，无法针对某一个功能模块按需扩展。 而服务架构则可以完美地解决伸缩性的扩展问题。系统可以根据需要，实施细粒度的自由扩展。
错误隔离性
微服务架构同时也能提升故障的隔离性。例如，如果某个服务的内存泄露，只会影响自己，其他服务能够继续正常地工作。与之形成对比的是，单块架构中如果有一个不合格的组件发生异常，有可能会拖垮整个系统。
团队全功能化
康威定律（Conway’s law）指出：一个组织的设计成果，其结构往往对应于这个组织中的沟通结构（organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations）。传统的开发模式在分工时往往以技术为单位，比如UI团队、服务端团队和数据库团队，这样的分工可能会导致任何功能上的改变都需要跨团队沟通和协调。而微服务则倡导围绕服务来分工，团队需要具备服务设计、开发、测试到部署所需的所有技能。