微服务架构是当前IT行业最流行的架构设计方案。微服务确实解决了软件开发中的一部分问题。服务自治，职责单一，可独立交付的特点也契合了敏捷开发的思想。
设计一个全新的系统可以考虑用微服务架构，历史遗留系统也有必要逐步往微服务架构演进，来提升整个架构和产品的竞争力。
笔者参与了对一个历史系统部分模块做服务化改造的项目。接下来谈一谈改造过程中的思考和策略。
简单说一下项目背景，笔者加入的开发团队维护着两套系统，一套是web系统，一套是单机桌面工具。随着业务的发展，后面桌面工具的功能要往web系统上迁移；同时单机工具也有它的应用场景，短期不会下线。考虑到相同的功能在web系统再实现一次，后续维护两套系统成本很高，决定对桌面工具的部分功能做服务化改造。改造后的微服务既可以部署在linux服务器上供web系统调用，也可以随桌面工具的安装盘打包部署到客户的window笔记本上使用。Web系统是用java开发，桌面工具是用c#。
在设计服务化改造方案时笔者考虑了这几个方面:1:开发语言的选择。2: 服务部署形态。3:开源组件选型。4:服务改造计划。5:服务划分。6: 团队协作。这个系统不涉及数据的迁移。
一、选择开发语言
选择开发语言时主要考虑了两方便：一是历史遗留系统采用什么开发语言，二是当前开发人员的技能。新服务跟历史系统采用相同的开发语言好处是有大段的逻辑代码可以复用，不用全部重写。但如果历史系统采用的是比较落后的开发语言，或者说跟当前已有的微服务平台不兼容则需要切换。
由于web系统已经是用java开发了，所以改造这部分也准备用java来重写。
二、服务部署形态
改造后的服务要同时支持服务器集群部署和单机工具部署两种方式。这两方的要求不一样，部署的环境有差异，所以设计了两套接口，通过url来区分。接口下面的具体实现是一样的，逻辑代码是重用的。
在服务器部署时发到docker容器，通过swarm集群调度。部署在window单机桌面时服务随客户端工具一起发布，安装包带一个jre。启动程序时把jar启起来，关闭时杀进程。
在服务器部署时客户层通过域名远程调用restful接口，在单机部署时通过localhost调用rpc接口。
三、开源组件选型
已有的微服务都是用spring boot搭建的，新服务沿用。
四、服务改造计划
对历史系统做服务化改造相当于架构级的重构，复杂度和风险都非常大。通常老系统还在线支撑业务，服务化改造的过程不能中断业务。老系统还在维护，还有新需求纳进来，服务化改造的同时还要实现新需求。
在一段时间内团队会面临双线作战，压力非常大。这种情况下做好改造计划很重要。饭得一口一口吃，我们先把一些功能比较独立的模块拿出来改造，如数据清洗，工程管理等，这部分功能前后依赖关系比较小，而且是改造完后两边的系统都能立马用得上。具体改造哪一部分还得看需求，看业务。
五、服务划分
服务划分既要考虑业务特性，也要考虑部署形态。如果我们只考虑服务器部署，根据服务的职责单一要求会划分出多个微服务，但是考虑到改造后的微服务还要给单机工具使用。单机工具资源有限，服务太多，占用的内存，部署复杂度都会很大。最终决定将多个功能的实现放在了一个服务中，编译成一个jar包。
在这种情况下做好开发视图的隔离很重要，笔者的做法是在同一个JAVA工程里面建不同的package做隔离，按功能特性分为数据清洗，工程管理，数据导入加common这几块。每块下面都有自己独立的controller，service，model，mapper。代码做好隔离，相互不影响，后面交给了不同人开发。公共的东西放到common下面。
数据库建表时给表名加上前缀来区分是领域的还是公共的。如:tbl_project_xxx，tbl_common_xxx等。
这样做保证后面如果还需要拆分，可以很方便。拆分时只要带上自己的东西加common模块就可以了。
六、团队协作
我们吸收了老系统的部分开发人员投入到服务化改造中。服务化改造除了需要解决技术问题，还要需要考虑团队管理的问题。业务面临转型，老技术更新，如何激发团队也是要考虑的。在笔者经历的项目中，老系统是用c#开发，很多开发人员对java不熟，但是他们是业务专家，趟过很多雷，填过很多坑，懂客户需求，是真正的老司机。服务化改造离不开他们。
如何把老员工的力量利用起来很关键。笔者的做法是先自己搭建好java微服务框架，给他们讲解spring boot如何使用，如何用jenkins部署，如果在kabana上检索日志定位bug。他们都是老程序员，也愿意学新技术，很快就掌握了。代码的规范性在开发过程中随时纠正一下。公司有编程规范文档，发给大家学习。
在制定接口过程中要求大家制定每一个接口都要考虑在服务端如何调用，在单机工具如何调用。接口成熟后，全部切换到调新服务接口，原有的c#代码就不维护了。这样保证大家尽快吃上自己的狗粮，有问题能及时发现。同时做到只维护一份代码，减轻了维护压力。
老系统服务化改造是对开发团队，管理者，技术骨干的考验。也考验公司领导的决心，毕竟从用户层面看不到重构带来的价值。但服务化改造本身的价值是毋庸置疑的，提升了软件的扩展性，维护性。
是否做服务化改造还是要看软件系统自身的定位。如果是做一次性的项目，能用就行，没必要花大力气去改造。如果是做产品，软件系统生命周期很长，这个投入是值得的。