微服务架构-模块迁移

对于遗留的单体应用，要进行微服务架构的改造往往比一个全新应用基于微服务架构实现更加困难。对于单体应用的微服务架构改造，最常见的方式仍然是将低耦合的模块逐步迁出。下面以一个采购系统中招投标模块迁出为例进一步思考单体应用的微服务架构改造步骤。

在整个模型中我们将模型进行简化，当迁出一个功能模块进行微服务化的时候，首先要考虑的就是对该模块进行集成架构分析，考虑该模块和外围的集成情况，其次才是考虑该模块内部的私有数据。对于招投标模块我们将模型简化来看，主要涉及到上游，下游和底层共享数据几个方面的集成，初步分析如下：

1. 上游需要集成项目管理系统中项目信息，招投标基于已经立项的项目信息。
2. 下游需要集成当前遗留的采购系统，其中招投标结果信息和认证合格的供应商信息需要同步到采购模块。
3. 底层业务需要调用供应商，企业组织，人员等基础数据信息。
4. 底层技术需要调用流程引擎能力，实现招投标模块内部的流程建模和执行监控。

有了以上内容后可以看到，对于上述接口都需要进行服务化，不管是招投标模块本身提供的服务还是其需要调用和消费的服务。在该过程中就存在一个现实问题，其它已有业务系统是否会配合进行服务化的改造？如果其它系统很难配合，那么在微服务模块的迁移过程中就存在要单独实现一个服务代理模块，由该模块来实现接口的服务化工作，该服务代理模块本身还可以实现统一服务目录库的工作。在企业整个微服务架构逐步成型后可以看到该服务代理模块能力会最终融入到微服务网关和总线上。

其次，在服务实现上需要考虑的一个关键问题就是我们通过服务调用消费的数据尽量不落地，即实时的通过服务同步查询外围共享数据，包括项目信息，供应商，人员等基础信息。而在招投标内部的表中也仅仅存储外键ID，减少对重复数据的冗余。而对于我们需要分发的数据则尽量是通过消息中间件机制实现异步分发，减少耦合。由于数据不落地会导致我们在招投标模块前端实现过程中存在多次数据查询后组合，这是不可避免的问题。当然你也可以在招投标模块中增加一个领域服务层来实现类似组合服务的功能。

这些都考虑清楚后需要考虑私有数据库的设计，注意在微服务模块剥离过程中，招投标模块本身需要对应一个独立的私有数据库，可以是SID数据库实例级别，也可以是Schema级别。当采用Schema级别的时候务必注意不能使用跨Schema的关联数据库表查询语句，否则在数据库层面仍然是紧耦合。在数据库剥离后可以看到，对于招投标模块本身内部业务功能到私有数据库可以采用内部API方式进行调用，但是对于外部的数据和业务协同只能通过发布的服务进行调用和集成。

底层虽然进行了微服务和模块化改造，但是用户最终关心的仍然是完整的业务系统和功能，因此在微服务模块剥离后需要考虑的就是整体外层门户框架的单点集成能力。对于单点集成方案已经有很多标准的实现方式，在此不再进行详细描述。

在任何一个微服务模块的改造过程中，仍然涉及到底层平台层能力如何解决的问题？拿上面的场景来说，原有的采购管理系统里面可能已有有完整的流程引擎能力，那么剥离的招投标模块是否采用该流程引擎？还是说在微服务模块的改造过程中将核心的平台层能力也逐步剥离出来，如将流程引擎能力也剥离出来形成独立的共享流程平台。这些都是我们需要考虑的问题。个人建议的方式仍然是伴随着微服务模块的迁出同时，将可共享的核心平台层能力也同步剥离，形成底层共享技术服务能力平台。

一个微服务模块没有和Docker集成并不代表不是一个完整的微服务架构，一个微服务架构的核心判断标准仍然是组件化和服务化，数据库的单独剥离。上述的这些问题考虑清楚后，接着才考虑该微服务模块内部的技术架构和服务实现方式等问题。在单个微服务模块的实现中仍然推荐采用类似OSGI总线来实现内部的集成，在该模式下组件本身的动态部署和扩展能力将刚强。也更加容易在后期将内部的API发布为外部可以消费的服务。对于前期对开源ESB的研究可以看到，类似Karaf这种基于OSGI的框架可以是一个备选方案。

微服务模块在迁出地过程中应该尽量减少对已有业务系统的影响，减少对用户使用层面的影响。即任何业务系统架构改造和内部的复杂性都应该屏蔽在内部。这是在整个架构迁移过程中的关键原则之一。

在上述整体思路清晰后，剩余的即是关键技术问题的解决，包括了分布式事务，接口安全和性能，动态部署，弹性扩展，模块健康监控，DevOps能力等，这些在整个实施过程中都必须逐个考虑和解决。要清楚一个遗留的系统在进行微服务架构改造中，前期是增加了复杂度，特别是前期的解耦和后期的集成。微服务架构改造真正受益的是在后期的运维管控和平台弹性扩展上。