这篇文章是我们转向微服务章节的最后一篇文章，要迁移的功能是单体应用的报表服务。但是呢，我们并不打算将报表服务完全迁移过来，这是因为我们的孢子记账项目在运行了一段时间后，发现报表服务的功能并不完善，性能也有待提升，并且用户反馈当前的报表服务功能太单一，无法满足用户的需求。因此，我们决定先将报表服务的部分Controller和Service部分迁移过来，定时统计功能不进行迁移。
一、迁移报表服务的部分Controller和Service
与之前的迁移类似，我们将报表服务的部分Controller和Service迁移到微服务中。我们将报表服务的Controller和Service代码复制到微服务项目中，并进行必要的修改。
在微服务项目中，我们创建了一个新的Controller类ReportController，并将报表服务的相关方法迁移到这个Controller中。同时，我们也创建了一个新的Service接口IReportServer，以及实现类ReportServerImpl，将报表服务的相关逻辑迁移到这个Service中，并使用依赖注入的方式将其注入到Controller中。
定时统计功能是报表服务中的一个重要功能，但我们决定不将其迁移到微服务中，主要有以下几个原因。首先，就像我在文章开头提到的，孢子记账项目在运行了一段时间后，发现报表服务的功能并不完善，性能也有待提升。并且用户反馈当前的报表服务功能太单一，无法满足用户的需求。因此定时统计功能不进行迁移。其次，统计功能在微服务中需要重新收集需求，重新设计和实现。我们需要在这次微服务版本中对报表服务进行全面的重构和优化，包括定时统计功能，并且新增更多的报表功能，以满足用户的需求。
看到这里一定有小伙伴会问，既然不迁移定时统计功能，为什么还要迁移报表服务的部分Controller和Service呢？这是因为我们要保证目前在运行的前端项目能够正常使用报表服务的查询以往的数据。虽然我们不迁移定时统计功能，但我们仍然需要提供查询报表数据的能力，以便用户能够查看和分析以往的数据，这也是我们迁移报表服务的主要目的。
二、为什么只迁移Controller和Service
在项目开发中，除了在开发项目一期（例如孢子记账的单体应用）时我们不需要考虑前端访问服务端的问题外，其他时候我们都需要考虑前端访问服务端的问题。因为我们服务端每次发布新版本时，都有可能影响到前端，这是因为我们修改的代码可能修改了甚至删掉了前端访问的接口，导致前端无法正常访问服务端。因此我们在发布新版本时，需要考虑接口兼容性问题，确保前端能够正常访问服务端。关于接口兼容性问题，在后续文章中我会详细讲解，这里我先简单介绍一下。
接口兼容性问题主要分为两种情况：一种是新增接口，另一种是修改或删除接口。新增接口不会影响到前端访问服务端，因为前端可以继续使用原有的接口，而新增的接口可以供前端使用。修改或删除接口则需要特别注意，如果修改了接口的参数或返回值，可能会导致前端无法正常访问服务端，因此我们需要在修改接口时，确保与前端的兼容性。
三、总结
在本篇文章中，我们完成了孢子记账项目的报表服务部分的迁移工作。我们将报表服务的部分Controller和Service迁移到微服务中，并进行了必要的修改。同时，我们也讨论了定时统计功能不进行迁移的原因，以及接口兼容性问题的重要性。
通过这次迁移，我们为孢子记账项目的微服务化打下了基础。虽然我们没有迁移定时统计功能，但我们仍然提供了查询报表数据的能力，以便用户能够查看和分析以往的数据。未来，我们将对报表服务进行全面的重构和优化，以满足用户的需求。
希望这篇文章能够帮助大家更好地理解微服务化的过程，以及在迁移过程中需要注意的问题。如果你对微服务化有任何疑问或建议，欢迎在评论区留言，我们一起讨论和学习。