1、如何将单体项目拆分成微服务
如何拆分微服务？其实对不同的业务项目场景，对应有不同的拆分方案。需要项目人员详细的分析项目需求、团队现状、业务边界、业务逻辑等方方面面，拆分的粒度既不能过细，也不能过粗，需要把控好尺度。
如下为较为通用的拆分思路：
- 从业务模型切入，根据业务边界进行拆分
- 确保一个微服务团队对应一个开发小组或团队
- 确保拆分之后所带来的收益大于拆分之前，否则不进行拆分
- 考虑团队人员配置。在人员少的情况下，服务拆分的粒度不必过细
根据业务场景 ，总结出以下几点
- 划分服务必须满团队开发需求，以业务为导向，明确业务界限，再进行划分
- 对于项目来说，业务界限比较清晰的有这个几块：用户服务、商品服务、车厂服务、订单服务、支付服务、优惠券服务、推荐服务、消息服务等
- 最大化的复用微服务，避免重复造轮子
- 对于订单服务，支付服务、优惠券服务而言，它既可以支撑车厂出库需求，又可以支撑车品商城需求，二者代码有很多重复的地方，通过复用服务，减少了重复性的代码
- 最小化地变更原有服务
- 对于车品商城中的推荐功能而言，它相对较为独立，处于服务的下游，暂时只能被上游商品服务调用，只需要将相关的推荐代码取出来即可，并且也可为之后新业务提供推荐服务。
- 确定基础公共服务与业务服务，并从原有项目中抽象公共服务。
- 在项目中，除了业务相关的服务外，还有一些基础服务模块，如日志监控，权限检验，搜索服务等，这些也需要从原有的庞大项目中抽取出来，作为独立的微服务
- 尽可能避免循环依赖，若出现循环依赖的情况，需要设计中间层做冗余处理。
- 尽可能避免过度拆分微服务，必须结合实际业务场景做划分
- 对于车场服务而言，如果进一步拆分车厂地图服务、车场详情服务、车场预约服务的话，会导致团队一进步拆分，而车场相关的功能是一个整体，需要成员紧密合作、一同完成需求开发、不适合进行更细粒度的拆分。此外，过度拆分微服务，会导致出现分布式问题，复杂度上升，带来不必要的技术成本。