如果开发者不能可靠且快速地将微服务发布到生产环境中，就是对采用微服务所提升的开发速度的极大浪费。不稳定的部署所造成的痛苦（如引入严重的错误）会完全抵消速度提高所收获的收益。
传统的组织机构通常会通过引入比较官方的变更控制和审批流程来谋求稳定性。这些流程的目的是管理和限制变更。这并不是盲目的冲动行事：如果这些变更引入的大部分bug动辄会给公司造成成千上万乃至数百万的工程投入或者收入上的损失，那么开发者就应该严格控制这些变更。
在微服务架构中，这种方式就不可行了，因为整个系统处于一个持续演进的状态中——正是这种自由带来了实实在在的创新。但是为了确保这种自由不会导致系统出现错误或者不可用，开发者就需要能够做到充分信任开发流程和部署工作。同样，为了使这种自由处于第一优先级，开发者还需要尽可能地减少发布一个新服务或者修改一个已有服务所需要投入的工作，可以通过标准化和自动化来实现稳定性的目标。
（1）将开发过程标准化。开发者应该评审代码的改动、编写对应的测试代码以及维护源代码的版本控制。但愿没有人对此要求表示意外或感到奇怪。
（2）将部署过程标准化和自动化。开发者应该彻底地验证所要提交到生产环境的代码变更，且要保证部署过程不需要工程师的介入，也就是说，要做成部署流水线。
总结，看完这篇文章，感受我们的微服务项目是个假的，发布没有那么快速。服务变更要新制作版本，对外发布要部署和升级，从发布流程看和传统的没差别。整个大版本的制作显的很臃肿，很耗时。曾经有个项目产品中一个微服务变更验证一个故障，通过流水线制作一个冒烟版本搞了一夜，第二天发现版本制作错了。部署过程自动化是好事情，但一定如何更好的自动化，值得实践时慎重考虑。
摘取自 摩根·布鲁斯和保罗·A.佩雷拉的《微服务实战》
网友评论