微服务改造设计参考

【摘要】 本文总结微服务改造相关的可行性分析、工作量评估、设计思路等问题，供选型参考。典型的场景包括将Servlet应用改造为CSE、Dubbo改造为CSE、Spring Cloud改造为CSE等。同时给开发者提供了一些开发建议，使得自己的业务系统能够更好的切换开发框架。

本文总结微服务改造相关的工作量评估、设计思路等问题，供选型参考。典型的场景包括将Servlet应用改造为CSE、Dubbo改造为CSE、Spring Cloud改造为CSE等。本文主要描述一些通用性问题，不涉及具体的场景，但是在举例的时候，会使用具体的场景作为例子。

关于不同框架改造的注意事项和案例文章：

1.       Dubbo改造为CSE：

案例一：https://github.com/huawei-microservice-demo/SpringCloudIntegration/tree/master/dubbo-migration

案例二：https://github.com/seanyinx/dubbo-to-servicecomb

2.       Spring Cloud改造为CSE：

案例一：https://huaweicse.github.io/cse-java-chassis-doc/spring-cloud-using-cse/spring-cloud-using-cse.html

3.       CloudSOP改造为CSE：

案例一：http://3ms.huawei.com/km/groups/2912737/blogs/details/2509223

案例二：http://3ms.huawei.com/km/groups/3257141/blogs/details/5096421

工作量和可行性评估

业务需要将一个开发框架换成另外一个开发框架的时候，通常的期望是保留业务处理逻辑，而丢弃框架的运行时。最理想的情况，是业务逻辑代码原封不动，不做任何修改，平滑的将运行时切换过来，比如将业务代码的war包，从Tomcat容器切换到Jetty容器。

以war应用为例，可以看看war应用和容器之间的依赖关系：

采用一个框架，必然存在和框架功能有交互的地方，在这里的主要内容就是服务发布部分。由于Tomcat容器和Jetty容器服务发布都支持相关的协议和规范，因此业务代码可以完全平滑的进行迁移。

对于其他业务代码部分，比如处理流程、数据访问等，需要考虑目标系统是否支持运行这些组件，如果支持，那么这些代码不涉及修改，可以平滑迁移。

如果业务代码使用了对应容器提供的工具API，那么像Tomcat容器迁移到Jetty容器的场景，也可能需要代码改动，业务切换变得不平滑。

当出现目标框架不支持运行依赖的组件，或者服务发布方式没有对等的方式、工具API没有对等的API支持的时候，这种切换就会变得不可行。当然实际在选型分析的时候，非常难把握一些细节的不支持情况，不过倒不用悲观，实现一个业务逻辑的方式是有多种可能性的，换一种实现思路去调整实现逻辑，也能够解决单纯从技术上看，无法对等改造的问题。

工作量评估

从上面以war应用在不同运行容器之间的改造可以看出，一个框架改造为另外一个框架的工作量可以从两个维度进行评估：

1.       改造前的业务代码依赖于原来框架的程度。

2.       目标框架本身对于业务代码采用的技术的支持程度。

再看一下上面例子中，CSE框架的情况。

可以看到，和war应用对比，服务发布的方式变化了。提供的API变化了。 将war应用切换为CSE的工作量主要包含两部分：

1.       将服务发布方式修改为CSE的服务发布方式，即将Servlet定义修改为Spring MVC或者JAX RS或者RPC的方式。

2.       调用工具API的地方，需要分析CSE SDK是否有对等的替换方案，使用CSE SDK提供的API进行修改。

下面表格结合上面的分析，简单的评估了一下各个框架切换CSE的难度对比。这个难易程度只是近似的评估，主要考察可能的改动点多少。工作量的评估的一个很重要要素是原来业务系统本身在处理平台依赖上的成熟度（依赖的多少和程度），这个工作量不再这里评估，尽管这个可能是导致工作量最重要的因素。

对开发者的建议

在上面的难易度评估矩阵中，有一个协议gRPC需要特别提到一下。在所有的框架中，将代码切换到gRPC，都是最难的，但是将gRPC切换为其他框架，都是最容易的。一般的，如果一个框架满足如下特性：

1.       更加贴近业务代码的书写形式，比如采用RPC的方式对外发布服务；

2.       更多的跨语言方面约束；

3.       更少的平台API

那么其他框架改造为这个框架会更加难，但是这个框架改造为其他框架更加容易。因为1，在切换为其他框架的时候，只需要将接口以其他框架的形式包装一次，不涉及任何代码修改；因为2，可以适配更多的接口约束和更多的序列化方式，支持的框架更多；因为3，不涉及平台API的整改和对等切换。

很多业务都会考虑对于平台绑定的问题，特别是那种需要长期发展的业务。因为平台技术日新月异，变化的场景驱动业务采用更加先进的架构技术改善业务的运行状况，比如JAVA技术的从Osgi到J2EE到WEB到微服务框架。那么业务如何去适应这个变化了？上面3个特性实际上给了一个指引。另外就是还需要加上：

4.       尽可能符合标准协议的约束。

这条规则和构造WEB应用选用那些功能一样的。在书写HTML的时候，尽可能的遵循HTML4、HTML5规范，能够让网站在更多的浏览器上精彩的呈现。

更好演进的另外一个方面，就是开发限制。这块无疑会增加开发者的成本，需要学习更多的规范和培养更好的编码技能。有些业务场景，还必须使用平台特性去解决。这些复杂性都不会让我们的代码完美，总是在一个权衡和妥协中发展。

下面提供了一个代码设计方面的模式，这种模式解决了发布形式的切换问题，而且业务是可以快速遵循的。业务代码按照这样的模式进行组织，并且在接口定义上尽可能考虑跨语言数据结构（主要指数据类型），那么这种业务代码在配套平台升级的时候，将会是最快速的。

逻辑结构：

 

代码示例：

总结

结合上面的观点，所有框架不会在各种方面都是完美的，CSE SDK在灵活性方面的折中做得非常的出色。通过提供业务代码的书写习惯支持大大减少了切换为CSE的工作量，同时后续如果将CSE迁移到其他框架，相对来讲也是非常容易的。

可以通过ServiceComb的开放性设计，了解CSE SDK的设计思路：

来源：华为云社区  作者：liubao68