小知识，大挑战！本文正在参与“程序员必备小知识”创作活动。
1 微服务的独立部署
举例，并且假设该流程为极端情况，每个服务互相调用，不考虑是否合理。
三个模块，分别进行编译、单元测试和部署，自动发布到产线，完成了每个模块的独立部署
但是假设A模块版本升级，破坏了与B和C的契约，导致A服务部署到产线引起严重的bug。要解决这个办法，我们可以加上集成测试。
这里加上一个e2e(e2e: end to end 端到端测试)
通过添加E2E测试，解决了服务间集成的验证问题，但也失去了微服务架构的那个重要的特性：“服务的独立交付”。 若没通过集成测试，所有微服务都会在部署的道路上被阻塞。最后这一个红绿灯，让所有的服务又纠缠在了一起，所有的服务化拆分形同虚设，最终得到的也只是一个看起来像微服务架构的单体应用而已。
要解决这个问题，可以在每个服务单元测试之后分别进行集成测试。
此时的E2E测试并不是像之前一样获取B和C服务的最新代码库版本做集成验证，而获取当前产品环境上的B和C服务的已部署当前版本做集成验证。
该例子很简单，看似是简单的变化，但是揭示了持续集成和持续交付的本质区别。
（关于更优的测试方式还有契约测试，不是重点，感兴趣的可以自行了解。）
2 向前看是持续集成，向后看是持续交付
- 持续集成关注的是各个集成单元之前最新版本的集成问题，即是不是某个集成单元的最新版本破坏了系统整体的集成;
- 持续交付关注的不是集成单元最新版本之间的集成问题，而是关注的是当前集成单元与产品环境上的其他服务的版本是否兼容。
两者的视角不同，持续集成是向前看，持续交付是向后看
3 以新的角度看我们的产品
B产品，只做到持续集成
A产品，半持续交付。分两个微服务，每个微服务单独做ci的时候会同时拉取两个模块进行部署测试，如果没有复杂业务逻辑的干扰，两个微服务的上线互不干扰。但是两个模块的ci不能同时进行，会互相block。所以我认为是半持续交付。
近期评论