对于中小企业来说，使用微服务架构来应对产品迭代压力是个不错的方案。它能快速承载海量用户访问的压力，同时搭建起来也十分方便。但如果想要实现微服务切换，过程中依然会产生一些问题，到底应该如何解决这些问题呢？武汉佰钧成在微服务架构的搭建及改造方面已积累了许多经验，今天就来对此分享一下心得体会。

　　武汉佰钧成心得分享——旧系统升级为微服务架构

　　将旧系统升级为微服务架构的前提是不影响现有业务，因此需要根据当前的业务状况出发，以此为基础来制定方案。以下将举例说明：

　　现状一：旧系统功能还算稳定，技术相对较老旧

　　实施策略：优先重构基础数据放缓存，为提供给微服务做准备；改造权限数据和实现sso与网关对接，同时处理好web端跨域调用；逐步绞杀对应的业务模块，迁移相应的数据表，业务聚合性较强的整合在一起；最后把基础数据，权限数据全部微服务化。

　　现状二：旧系统一直在不停的需求迭代

　　实施策略：最合理的策略是先停止往单体式应用里面添加新的特性，所有新特性都构建成微服务，从而遏制单体式应用继续生长。同时要建立旧系统和微服务之间的防腐层，避免旧系统在升级过程中功能维护对微服务产生腐化。借助这个过程让团队逐渐熟悉掌握微服务技术栈，从小规模练兵再到全面铺开。

　　武汉佰钧成心得分享——微服务架构的改造

　　旧系统改造的过程中经常遇到需要将数据进行切换，例如由原来的oracle转换成mysql，或者由sqlserver转换成mysql等，这种改造首先要进行分析，如果有存储过程，函数等，优先实施完成后再进行切换。优先模式是逐步切换和迁移，不能进行一刀切。

　　拆分微服务前就要充分考虑服务调用问题，尽量避免多个服务调用，避免分布式事务，尽量不做调用链很长的模式，如果一定要存在多服务调用，建议用事件机制解耦，或者通过mq，redis等中间件处理，不要存在长调用链或者强一致性业务多服务调用的情况出现。

　　在改造过程中还会遇到一些报表数据的处理问题。简单报表服务间做数据冗余，再结合redis的基础数据来实施，复杂报表需要跨多个服务的建议将数据聚合并清理成具体的报表模型，由es来提供服务是比较稳妥的方式。

　　微服务架构固然实用，但它也不是没有缺点的。就目前而言，微服务架构的搭建难度不大，但对使用场景有要求，也有一定的落地难度。因此武汉佰钧成建议，提前根据具体业务情况做好规划，结合已有的系统来使用它，并做好微服务架构与单体架构长期共存的准备。善用微服务架构，它便能发挥出应有的功效。